text:
Transaction still listed as 'pending' after 12 hours
I'm using Electrum 2.5.4 on Tails 2.2.1
Sent the following transaction over 12 hours ago with 0.0005 BTC/kB transaction fee.
There's a warning message saying the transaction has a none standard input - which after googling doesn't seem to have a concensus on what to do about this
What gives? Any help much appreciated
https://blockchain.info/tx/22e6190880cb2433fb99f27e7daf1a763c5e86d64fadb40b708be8295283a052

The higher the number of unconfirmed transactions (in the mempool) the longer will take to confirm your transaction unless you give a higher fee.
I recommend watching current mempool where you can see the number of unconfirmed transactions and it gives you an idea how "clogged up" is the Bitcoin network.
Unconfirmed transaction will either confirm or expire (not sure but I think it takes 3 days to expire).

Would you be able to ELI5 the current mempool link you sent over in relation to my transaction? I was under the impression my fee was healthy (unchanged, default Electrum fee)

In the link you can currently see:

Sorry for the previous uncomplete comment.
In the link you can see:
20,982 tx 81,596.61 XBT
Total fees: 5.4042 XBT
Total size: 16.30 MB
Fee/size: 33.16 sat/B

Which means there are 20,982 uncofirmed transactions (normal is below 5000). I would recommend giving a higher fee than normal if there's > 10,000 unconfirmed transactions. On the page, blue column represents number of transactions and yellow column represents value in bitcoins. On the left are mined blocks (confirmed transactions) and on the right is the mempool (unconfirmed transactions).

Thank you for your expertise. The transaction has just been processed. I was specifically concerned about the 'none standard input' flag - but doesn't appear to have been the cause of the hold up as you have pointed out. Best regards


text:
Low cost option to run Lightning node in Cloud
I like to run a Lightning node and need some inputs.
Providing Internet, Electricity  24*7 to my home system/Raspberry (Umbrel setup) is super challenging in my place.
Like to know if running pruned bitcoin-core, LND in a cloud server (~$10/mo.) is a good idea?
What are the catches with this approach, apart from the obvious one of "Trusting the cloud vendor".
https://voltage.cloud/ provides a $13/mo. package (LND with Neutrino), which matches my exact requirement. But my intent is to setup and run things by myself. For the sake of learning.
Thanks.

Here is an implementation on the Google Cloud https://medium.com/coinmonks/setup-bitcoin-lightning-server-on-google-cloud-guide-95811c439b32

@sean: Thanks, I've converted your answer to a comment on the question as a seed for someone that wants to provide a full answer.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Difference in lightning network node/channel stats between my LND, what's shown in amboss and 1ml.com
When I run ./lncli getnetworkinfo I get the following:
{
    "graph_diameter": 13,
    "avg_out_degree": 5.67523205795789,
    "max_out_degree": 117,
    "num_nodes": 17668,
    "num_channels": 50135,
    "total_network_capacity": "135922147300", // 1359 BTC
    "avg_channel_size": 2711122.914131844,
    "min_channel_size": "1050",
    "max_channel_size": "500000000",
    "median_channel_size_sat": "1000000",
    "num_zombie_chans": "19"
}

Amboss shows the stats as follows:

While 1ml shows as follows:

Node count:

My LND: 17,668
Amboss: 16,671
1ML: 17,780

Channel count:

My LND: 50,135
Amboss: 84,215
1ML: 86,747

Network capacity:

My LND: 1,359 BTC
Amboss: 4,591 BTC
1ML: 4,548 BTC

For channel capacity and network capacity, there is a huge different between what my LND is showing and what amboss/1ml is showing. Should I do something (like connect with more diverse set of peers or force crawling again) to get my LND stats up to date?

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Is this other Boost warning harmless and should be ignored when building Bitcoin Core?
In a similar vein to this question I got a new Boost warning when building a PR branch on MacOS.
In file included from /usr/local/include/boost/test/test_tools.hpp:46:
/usr/local/include/boost/test/tools/old/impl.hpp:107:17: warning: comparison of integers of different signs: 'const unsigned int' and 'const int' [-Wsign-compare]
    return left == right;

Is this entirely harmless again? Maybe I should just be configuring with --enable-suppress-external-warnings and ignoring all Boost warnings? A signed integer shouldn't be compared to an unsigned integer though surely?

Is this entirely harmless again?

Quite possibly; you'd need to review the Boost internal code to find out. But in any case, if there is an issue, it's in Boost that this needs to be fixed.

Maybe I should just be configuring with --enable-suppress-external-warnings and ignoring all Boost warnings?

Unless you feel like debugging Boost itself, yes.

A signed integer shouldn't be compared to an unsigned integer though surely?

There is nothing inherently wrong with it. It's an indication that the code could be written in a more obviously correct way likely, but it's perfectly reasonable to encounter this in bug-free code. For example when in the context this is executed, it's known that the signed integer is never negative.

Bitcoin Core just uses Boost for the unit tests right? It doesn't use Boost libraries for anything else? So even if there was a bug in Boost you'd be (relatively) relaxed about it as its just a unit test dependency rather than a dependency for the actual codebase being tested? Will turn on suppress external warnings from now on.

It uses Boost libraries for several things, but the Boost Test library (which is the one under consideration here) is only used by the Bitcoin Core test code, indeed.


text:
Does a OP_CHECKSIGADD and OP_EQUAL script for a threshold signature fail if you provide too many valid signatures in the unlocking script?
For this CHECKSIGADD script for a 2-of-3 multisig:
<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD OP_2 OP_EQUAL

What happens if you provide more than the 2 required signatures, in this case 3 valid signatures for the 3 associated public keys? 3 is not equal to the required 2 so the OP_EQUAL would cause the unlocking script to fail? Would you need to use a greater than or equal opcode instead of OP_EQUAL if you are going to provide more valid signatures than required?

Yes, if you provide too many signatures, it will fail on the OP_EQUAL. Luckily, you can easily fix it by just dropping one of the signatures and replacing it with the empty byte vector instead.
You could permit additional signatures by replacing OP_2 OP_EQUAL with OP_1 OP_GREATER_THAN, or with OP_2 OP_GREATERTHANOREQUAL, however additional signatures would increase your input’s weight, so it seems preferable to just drop superfluous signatures.


text:
What does the Bitcoin Core linearize script do? What use cases would make use of it?
What does the Bitcoin Core linearize script do? The Bitcoin Core docs state it will:

Construct a linear, no-fork, best version of the Bitcoin blockchain.

By "linear, no-fork" blockchain does that mean throwing away orphan/stale blocks (blocks that were successfully mined but didn't make it into the blockchain due to competing mined blocks)?
What use cases would make use of this linearize script?

By "linear, no-fork" blockchain does that mean throwing away orphan/stale blocks (blocks that were successfully mined but didn't make it into the blockchain due to competing mined blocks)?

Yes.

What use cases would make use of this linearize script?

The script was used to construct the bootstrap.dat file that was previously used to quickly sync new nodes. This method of node initialization has been deprecated and remove as headers-first syncing is faster.

Thanks for this Andrew. Is there any reason for maintaining it then and not just deleting it from the Core repo? Do we know if anyone is using it for anything else? I wonder if we should at least add a comment on the README that this isn't used for anything (as far as we know).

While the autoloading of the bootstrap.dat file has been removed, it is still possible to use such linearized files to initialize a node in this manner. So the script is still useful in constructing those files.


text:
Why is the Bitcoin Core wallet database moving from Berkeley DB to SQLite?
Why is the Bitcoin Core wallet moving from Berkeley DB to SQLite for its database backend?

The introduction of descriptor wallets presents an opportunity to introduce a new database backend as descriptor wallets are backwards incompatible. The following is taken from Andrew Chow's blog post on what's coming to the Bitcoin Core wallet in 0.21. (There was also discussion on this GitHub Issue.)
Why move from Berkeley DB?

Not designed to be used as an application data file. The Legacy Wallet has several hacks to get round this as a result and Berkeley DB wallet files can easily be corrupted.
Berkeley DB produces extra files which need to be moved with the database file. This means that Berkeley DB is less portable and requires a directory for each wallet.
Changes were introduced to Berkeley DB database environment files breaking backwards compatibility.

Why choose SQLite?

Can be used as an application data file.

New SQLite versions maintains backwards compatibility with versions as far back as 2013.

Does not require database environment. A completed write guarantees that the data was written to the database file.

Can now move to single wallet files instead of wallet directories.

Here is the proposed timeline for legacy wallet and Berkeley DB removal from Bitcoin Core.

There is also the fact that SQLite is easily the most robust, reliable, and heavily tested DB engine. It is probably also some of the most robust, reliable, and heavily tested code, period, except maybe the aerospace industry. Maybe even better (cough Boeing cough). Their testing regime and approach to robustness and reliability is truly insane. For each line of code, there are 640 lines of tests.


text:
In MuSig-DN why not use a truly random number for the nonce instead of a pseudorandom function?
In MuSig-DN why not use a truly random number for the nonce instead of a pseudorandom function (PRF)? If the nonce space is big enough it would never be reused.
This question was asked by emzy on Twitter.

This question was answered by Tim Ruffing on Twitter.

The answer is simply that it's not easy to get truly random numbers
right in practice. For example, you need to collect entropy in your
system, and it's hard to write a "test" that checks if your numbers
are really random.
Broken random number generators have led to numerous real-world
failures e.g.
https://www.schneier.com/blog/archives/2008/05/random_number_b.html
and
https://arstechnica.com/information-technology/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/
So it's better to simply avoid real random number generators in
practice, and this is well-established best practice for "normal"
single-singer signatures (Schnorr sigs, ECDSA). MuSig-DN makes this
possible for multisignatures, too.
But your point is correct in theory. If you have a working source of
truly random numbers, this will just do the job.

Pieter Wuille and Jonas Nick added on Twitter:

A working source of random numbers and a place to keep them securely
and tamper-proof between the rounds of the signing process.
Or just a place, to keep a counter securely and tamper-proof between
the signing sessions. Ideally combined with an RNG.

But that is also true for the generation of the private key and we tolerate that there?

Perfectly right, yes.  I think the answer here is two-fold:

We can at least try to avoid real numbers as much as possible. Even for key
generation, we can derive all keys from a single seed, and then we
really rely on randomness only once in the life of a wallet for that
seed

It seems that the randomness is particularly brittle when it comes
to nonces used in signatures. For example, if you fix a single bit in
the nonce, then a few signatures may already be enough to derive the
secret key.

And maybe my second point is not even a valid one. I don't know enough about the concrete attacks to tell if signatures become suddenly insecure when we fix a single bit in the secret key (instead of the nonce)?

Diego Aranha added on Twitter:

Your second point is valid when applied to nonces, but a lot more than a few signatures are needed for 1-bit bias (something like 2^60 for an attack of feasible complexity for secp256k1). Fixing bits of the private key should just reduce the key space

And Akira Takahashi added on Twitter:

Indeed, attacking 1-bit nonce bias of Bitcoin ECDSA is currently out of reach, but 2-bit bias is already exploitable given about one million signatures and 3-bit only requires several thousands (or even less if lattice attack works). Not sure how bad a biased private key can be.
A middle-ground solution would be to include some nonce as PRF input. This way, you retain security even if the nonce is not truly random (proof: https://ia.cr/2016/290) and it should thwart the devastating rewinding attack on Schnorr multisig without ZKP.
But just to be clear, this solution still breaks down once the honest signer reuses the nonce. Dealing with such a stateful scheme is annoying and this is why purely non-stateful solutions like MuSig-DN are preferred in practice.


text:
When would I use USDT tracing over debugging? How do they compare and complement each other?
I am starting to learn about USDT tracing that 0xB10C hosted a PR review club on in May 2021 and is covered in this blog post.
I am still a little unclear when I would reach for this tool (assuming I learnt how to use it effectively!) and how it complements or compares to debugging generally.
Is it something to use when you hit the limits of what a debugger can do?

0xB10C answered this on Mastodon. Alternative answers are welcome.

We implement our own tracepoints in our userspace application
(Bitcoin Core) and write custom scripts to get insights into the parts
we find important.
Tracing via USDT and debugging are two very different things. You can
use tracing via USDT as part of the search for a bug but you can't
replace debugging with tracing.
Sometimes debugging, as in stepping through code and looking at state
with e.g. GDB, is something you do manually.
The tracing done with USDT allows you to use internal state
programatically. You can automatically react to some state.

This could be thought of as richer, deeper debugging. Rather than the stop, start nature of breakpoints you can allow the code to run continuously and still manipulate it. Or you could locate a bug using debugging and then explore the impact of the bug with USDT tracing.

Debugging is only one of the USDT applications. Tracepoints can also
be used to evaluate/review changes like I do with the Erlay vs master
nodes dashboard. Or for general monitoring, anomaly detection,
benchmarking and testing.


text:
How does Chaum style e-cash work? (all the Wiki links are broken)
I'm trying to learn how Chaum-style ecash worked specifically how:

"the issuer does a blind signature on a serial number"

I tried looking up on Wikipedia but the page is pretty light on the details, and all the pages don't work (even the Wayback machine pages are broken)

Here's the basic idea of blind signing in Chaumian e-cash:
Let's suppose that a central issuer (Chaumian e-cash is centralised) has an account in my name with a value of 10 dollars.  In order to "withdraw" this money as 1-dollar "bills" I begin by generating ten random serial numbers, each long enough that I can be reasonably sure no one else will generate the same numbers.
I am going to have the central issuer sign a message saying these are now worth one dollar each, only I don't want the issuer to know which bill is which (otherwise they could just match up outgoing and incoming serial numbers to know who I spent it with, since Chaumian e-cash can only be spent once before it has to be re-issued).
So in addition to the serial numbers I also choose secret 'blinding factors' and combine them with my serial numbers.  I give these blinded serial numbers to the central issuer, and they sign each one with their 1-dollar key (they have different keys for different denominations) and reduce the amount in my account with them accordingly.  They know how many 1-dollar bills they signed, but they don't know what serial numbers were on each bill they signed.
Now, the trick with "blind signing" comes in.  Because of how blind signing works, I can now remove the blinding factor, but I still have a valid signed message which can be verified using the issuer's public key.  This gives me a signed one dollar bill with its own serial number that the bank doesn't know (but they do know how many one dollar bills they have signed, because each one can only be un-blinded to a single serial number).
Now, to spend the bills to someone else, I simply show them the un-blinded, signed serial number.  They must now immediately "cash in" this token by going to the central issuer and showing them the signed serial number.  The central issuer verifies the signature using their "1 dollar" key, records the serial number, and credits the new person's account.  From their perspective, this dollar is indistinguishable from any other they have issued in the past.
However, if someone else shows up and tries to cash in the same dollar again, they will not honour it because they have already recorded the serial number as spent.  You also cannot spend a $1 serial number as a $50 serial number because $50 serial numbers use a different key.
More details about e-cash, including an "offline mode" that relies on trusted hardware, can be found here.  They use a different method of ensuring a $1 bill is not spent as a $50 bill--I don't remember which variant is whose but there are several of them which basically accomplish the same thing in slightly different ways.

What's the difference between the issuer's public key and their 1 dollar key?
My understanding: Bank use their 1 dollar private key to encrypt/sign the blinded serial number. I unblind it which gives me a different serial number that is signed/encrypted by the bank. One can use the bank's public key to get the unblinded serial number which confirms it was encrypted using bank's private key which is the same public key banks use to validate and send $. So banks have the blinded number as deposit and unblinded number as withdrawal in their records but don't know they're linked.

And any number decrypt able by the bank's 1$ public key (thats not used yet), is valid $ according to the bank?

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How should I install Core Lightning if my VPS won't let me use pip install?
I tried to install Core Lightning on a Ubuntu Digital Ocean droplet using these installation instructions and it won't let me pip install anything giving me an error externally-managed-environment. Should I just use poetry instead or is there a fix?

openoms suggested this fix on Telegram to keep using pip:

sudo rm /usr/lib/python3.*/EXTERNALLY-MANAGED

Christian Decker added some context around Core Lightning's use of Python in its build process:

Python is not a runtime dependency, which is why it is not
being listed as a direct dependency, but we use it for a variety of
build steps. The error you received is because the pip environment is
owned by root since you installed it via the package manager. If you
want to install the build dependencies we strongly suggest using a
virtualenv. Steps on how to set that up depend on the OS, and your
Python setup, hence why it is left undocumented (it's not CLN
specific, and any documentation on how to create virtualenvs would
bitrot, and we can't be authoritative anyway, since it is an external
project). We just need to find a good point to cut off the long tail,
and for venv that was the place that felt right.
Python dependency management grew quite organically, which explains the mess of different ideas and models being mixed. Usually you have the system environment, which you can extend through a user environment that gets overlaid. This does not work however if a user package clashes with a system package. We seem to rely on rather recent package versions, that may clash, causing this error. A virtualenv (initialized with --no-site-packages) creates a blank page without weird combinations of system and user packages.

The reason for the issue are changes introduced recently in Python and not the policy of your VPS. There are two solutions for this:
1. Install Python dependencies with a package manager like apt, e.g. apt install -y python3-mako python3-poetry.
2. Use --break-system-packages flag for pip, e.g. pip install --user poetry --break-system-packages.
The first option requires you to act as root, the second does not.

Check environment variables: Some Docker containers or cloud environments might restrict pip commands. Ensure variables like PIP_NO_INDEX or PIP_DISABLE_PYPI are not set to restrict package installations.
Check user permissions: You may need root or sudo privileges to use pip install. Try using sudo pip install if appropriate.
Isolate the issue: Create a new virtual environment and try installing Core Lightning there. This helps identify if the issue is specific to your current environment.
Consider alternative package managers: If pip continues to cause issues, try installing dependencies using apt or other package managers compatible with your Ubuntu version.


text:
c-lightning: connectd: Failed to create 2 socket: Address already in use
I am trying to build c-lightning from source and connect to testnet.

bitcoind is up and running in testnet already.
Running lightningd seems to be working good except for the following log:

connectd: Failed to create 2 socket: Address already in use

Full log at the bottom of the post.
Now when I try running 'cli/lightning-cli', I am getting the following error:

lightning-cli: Connecting to 'lightning-rpc': Connection refused

Any hint on what I am doing wrong?
bitcoin.conf
mintxfee=0.00002
testnet=1
prune=0
txconfirmtarget=6
txindex=1

.lightning/testnet/config
[empty]
~/projects/btc/lightning master ?1 ❯ lightningd/lightningd --network=testnet --log-level=debug
2022-01-09T15:15:13.424Z DEBUG   plugin-manager: started(1128) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/autoclean
2022-01-09T15:15:13.427Z DEBUG   plugin-manager: started(1129) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/bcli
2022-01-09T15:15:13.428Z DEBUG   plugin-manager: started(1130) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/fetchinvoice
2022-01-09T15:15:13.429Z DEBUG   plugin-manager: started(1131) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/funder
2022-01-09T15:15:13.430Z DEBUG   plugin-manager: started(1132) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/topology
2022-01-09T15:15:13.431Z DEBUG   plugin-manager: started(1133) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/keysend
2022-01-09T15:15:13.434Z DEBUG   plugin-manager: started(1134) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/offers
2022-01-09T15:15:13.436Z DEBUG   plugin-manager: started(1135) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/pay
2022-01-09T15:15:13.440Z DEBUG   plugin-manager: started(1136) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/txprepare
2022-01-09T15:15:13.450Z DEBUG   plugin-manager: started(1137) /Users/saiy2k/projects/btc/lightning/lightningd/../plugins/spenderp
2022-01-09T15:15:13.476Z DEBUG   lightningd: testing /Users/saiy2k/projects/btc/lightning/lightningd/lightning_channeld
2022-01-09T15:15:13.489Z DEBUG   lightningd: testing /Users/saiy2k/projects/btc/lightning/lightningd/lightning_closingd
2022-01-09T15:15:13.501Z DEBUG   lightningd: testing /Users/saiy2k/projects/btc/lightning/lightningd/lightning_connectd
2022-01-09T15:15:13.514Z DEBUG   lightningd: testing /Users/saiy2k/projects/btc/lightning/lightningd/lightning_gossipd
2022-01-09T15:15:13.527Z DEBUG   lightningd: testing /Users/saiy2k/projects/btc/lightning/lightningd/lightning_hsmd
2022-01-09T15:15:13.539Z DEBUG   lightningd: testing /Users/saiy2k/projects/btc/lightning/lightningd/lightning_onchaind
2022-01-09T15:15:13.555Z DEBUG   lightningd: testing /Users/saiy2k/projects/btc/lightning/lightningd/lightning_openingd
2022-01-09T15:15:13.569Z DEBUG   hsmd: pid 1145, msgfd 36
2022-01-09T15:15:13.613Z DEBUG   connectd: pid 1146, msgfd 40
2022-01-09T15:15:13.613Z DEBUG   hsmd: new_client: 0
2022-01-09T15:15:14.708Z DEBUG   connectd: Created IPv6 listener on port 19735
2022-01-09T15:15:14.708Z DEBUG   **connectd: Failed to create 2 socket: Address already in use**
2022-01-09T15:15:14.708Z DEBUG   connectd: REPLY WIRE_CONNECTD_INIT_REPLY with 0 fds
2022-01-09T15:15:14.711Z DEBUG   gossipd: pid 1147, msgfd 39
2022-01-09T15:15:14.712Z DEBUG   hsmd: new_client: 0
2022-01-09T15:15:14.739Z DEBUG   gossipd: gossip_store_compact_offline: 0 deleted, 0 copied
2022-01-09T15:15:14.739Z DEBUG   gossipd: total store load time: 0 msec
2022-01-09T15:15:14.739Z DEBUG   gossipd: gossip_store: Read 0/0/0/0 cannounce/cupdate/nannounce/cdelete from store (0 deleted) in 1 bytes
2022-01-09T15:15:14.739Z DEBUG   gossipd: seeker: state = STARTING_UP New seeker
2022-01-09T15:15:14.739Z DEBUG   gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY with 0 fds
2022-01-09T15:15:14.766Z INFO    plugin-bcli: bitcoin-cli initialized and connected to bitcoind.
2022-01-09T15:15:14.766Z DEBUG   lightningd: All Bitcoin plugin commands registered
2022-01-09T15:15:14.774Z DEBUG   lightningd: Unable to estimate opening fees
2022-01-09T15:15:14.774Z DEBUG   lightningd: Unable to estimate mutual_close fees
2022-01-09T15:15:14.774Z DEBUG   lightningd: Unable to estimate unilateral_close fees
2022-01-09T15:15:14.774Z DEBUG   lightningd: Unable to estimate delayed_to_us fees
2022-01-09T15:15:14.774Z DEBUG   lightningd: Unable to estimate htlc_resolution fees
2022-01-09T15:15:14.774Z DEBUG   lightningd: Unable to estimate penalty fees
2022-01-09T15:15:14.774Z DEBUG   lightningd: Unable to estimate min_acceptable fees
2022-01-09T15:15:14.774Z DEBUG   lightningd: Unable to estimate max_acceptable fees
2022-01-09T15:15:14.774Z DEBUG   lightningd: Smoothed feerate estimate for opening initialized to polled estimate 253
2022-01-09T15:15:14.774Z DEBUG   lightningd: Feerate estimate for opening set to 253 (was 0)
2022-01-09T15:15:14.774Z DEBUG   lightningd: Smoothed feerate estimate for mutual_close initialized to polled estimate 253
2022-01-09T15:15:14.774Z DEBUG   lightningd: Feerate estimate for mutual_close set to 253 (was 0)
2022-01-09T15:15:14.774Z DEBUG   lightningd: Smoothed feerate estimate for unilateral_close initialized to polled estimate 253
2022-01-09T15:15:14.774Z DEBUG   lightningd: Feerate estimate for unilateral_close set to 253 (was 0)
2022-01-09T15:15:14.774Z DEBUG   lightningd: Smoothed feerate estimate for delayed_to_us initialized to polled estimate 253
2022-01-09T15:15:14.774Z DEBUG   lightningd: Feerate estimate for delayed_to_us set to 253 (was 0)
2022-01-09T15:15:14.774Z DEBUG   lightningd: Smoothed feerate estimate for htlc_resolution initialized to polled estimate 253
2022-01-09T15:15:14.774Z DEBUG   lightningd: Feerate estimate for htlc_resolution set to 253 (was 0)
2022-01-09T15:15:14.774Z DEBUG   lightningd: Smoothed feerate estimate for penalty initialized to polled estimate 253
2022-01-09T15:15:14.774Z DEBUG   lightningd: Feerate estimate for penalty set to 253 (was 0)
2022-01-09T15:15:14.774Z DEBUG   lightningd: Smoothed feerate estimate for min_acceptable initialized to polled estimate 253
2022-01-09T15:15:14.774Z DEBUG   lightningd: Feerate estimate for min_acceptable set to 253 (was 0)
2022-01-09T15:15:14.774Z DEBUG   lightningd: Smoothed feerate estimate for max_acceptable initialized to polled estimate 253
2022-01-09T15:15:14.774Z DEBUG   lightningd: Feerate estimate for max_acceptable set to 253 (was 0)
2022-01-09T15:15:14.797Z DEBUG   lightningd: Adding block 2135126: 000000008bb23bbb0c06793bf1f7d47539284284f4019fd6b2058d9cf639d21b
2022-01-09T15:15:14.799Z DEBUG   wallet: Loaded 0 channels from DB
2022-01-09T15:15:14.799Z DEBUG   plugin-autoclean: autocleaning not active
2022-01-09T15:15:14.800Z DEBUG   connectd: REPLY WIRE_CONNECTD_ACTIVATE_REPLY with 0 fds
2022-01-09T15:15:14.800Z INFO    lightningd: --------------------------------------------------
2022-01-09T15:15:14.800Z INFO    lightningd: Server started with public key 027d0b5558e6e36a396b4335c51e28d1ec1dbf72a16e98fd87195900626bafdfa9, alias LOUDMONKEY (color #027d0b) and lightningd v0.10.2-193-g73bf4b2
2022-01-09T15:15:14.801Z DEBUG   plugin-fetchinvoice: Killing plugin: disabled itself at init: offers not enabled in config
2022-01-09T15:15:14.816Z DEBUG   lightningd: Adding block 2135127: 0000000000000062ec0632a5d644af1f8afaf0a48a6fecb085df2ef3b565e16c
2022-01-09T15:15:14.833Z DEBUG   lightningd: Adding block 2135128: 000000000000003e17b3b33db5c6e4b84e37494113a8e05b3276faa0f0cd1a30
2022-01-09T15:15:14.850Z DEBUG   lightningd: Adding block 2135129: 00000000000000a56ee0d7633edb05e7dff4b0ffdb1704c894aeb02af733c6f7
2022-01-09T15:15:14.864Z DEBUG   lightningd: Adding block 2135130: 0000000000000085f0749193775b45aad712b0fa5f7e0dfa4d8afd8f5e8fde45
2022-01-09T15:15:14.888Z DEBUG   lightningd: Adding block 2135131: 0000000000000024caf34c595d117e4b6729a38b936ab010bf5547c67de6c48c
2022-01-09T15:15:14.906Z DEBUG   lightningd: Adding block 2135132: 00000000000000399294cc5da617128504730e94a12763213baa961796d15fe3
2022-01-09T15:15:14.926Z DEBUG   lightningd: Adding block 2135133: 000000000000002ee9fe70ac60f798ae0e1d66321d0e626488247f23bdda8c09
2022-01-09T15:15:14.945Z DEBUG   lightningd: Adding block 2135134: 00000000000000a19c79d61e03cb3e338aaf7921899d62d7ee5be705256a45fe
2022-01-09T15:15:14.966Z DEBUG   lightningd: Adding block 2135135: 000000000000006f09a3cff85a2a306b2763209f0be21906aca283255448f208
2022-01-09T15:15:14.986Z DEBUG   lightningd: Adding block 2135136: 00000000000000b18f16cb1a7f6f760f7383a19827773cccf997b02a3318ec46
2022-01-09T15:15:15.008Z DEBUG   lightningd: Adding block 2135137: 00000000ee0aa9141988d131ff588cb09d19d241bd63b5c8b0a1d00939fb54df
2022-01-09T15:15:15.029Z DEBUG   lightningd: Adding block 2135138: 000000009c14602deffbd3296922ba55b832098c9cf80677443adad83b77ca49
2022-01-09T15:15:15.047Z DEBUG   lightningd: Adding block 2135139: 000000000000009729cd3655bc2595677a9ece071118e3c7cb3fa98ab5268d18
2022-01-09T15:15:15.068Z DEBUG   lightningd: Adding block 2135140: 000000000000009286ae27a488a8550b2f0e05dbb9cc6abfa8b0afff346f0b34
2022-01-09T15:15:15.087Z DEBUG   lightningd: Adding block 2135141: 00000000000000523e1e32edc3a04564a2150d2601b75944e32707d604808c8f
2022-01-09T15:15:15.105Z DEBUG   lightningd: Adding block 2135142: 000000000000008df2e08bbe7c9ff7cc35c6e3c9ecb87232f298b8de4850bafc
2022-01-09T15:15:15.125Z DEBUG   lightningd: Adding block 2135143: 00000000000000b5c83bce8a8c009c7ada0c0bc5426716152f9c341c4739a5c7
2022-01-09T15:15:15.143Z DEBUG   lightningd: Adding block 2135144: 00000000000000b118033b20ea53c451b35716120b7d69b56cb0f9d9dfc6b831
2022-01-09T15:15:15.160Z DEBUG   lightningd: Adding block 2135145: 000000000000006b802f3cfc151f86cb733eaf8e6aa388fd9b3d0a68fa4bbd3f
2022-01-09T15:15:15.177Z DEBUG   lightningd: Adding block 2135146: 000000000000005ed7dc430678d687384696e74a28299331a67588905bf6f062
2022-01-09T15:15:15.194Z DEBUG   lightningd: Adding block 2135147: 000000000000009142e2da8958b8533781f807beea4df488f6e74eaa4087d671
2022-01-09T15:15:15.212Z DEBUG   lightningd: Adding block 2135148: 000000000000005a3484239a08c9fb094778b1dbfae0b9ee1dfc1d9069295b69
2022-01-09T15:15:15.230Z DEBUG   lightningd: Adding block 2135149: 00000000000000953fac4e6bfd7bbf289f4f9d6b2f8092c37947eaabc41b9051
2022-01-09T15:15:15.247Z DEBUG   lightningd: Adding block 2135150: 00000000000000214f530ce76011c286ce4fe7260c84b66123d9953aa603149c
2022-01-09T15:15:15.266Z DEBUG   lightningd: Adding block 2135151: 0000000054b144f5377980ce5ec91a93119572f7f58bfd373c0610356616deb7
2022-01-09T15:15:15.293Z DEBUG   lightningd: Adding block 2135152: 00000000000000255efddc5b3be3d3f7e140f66d0832b58d054c9e3fd667a742
2022-01-09T15:15:15.313Z DEBUG   lightningd: Adding block 2135153: 000000000000002eaf2064f55304904e87bbb0e39f4faf2b3ecd177fd5d0ecb8
2022-01-09T15:15:15.333Z DEBUG   lightningd: Adding block 2135154: 000000001f8ecb22687773b4a314faf1add87c8d0ce81d1cc4fb9d27100937a3
2022-01-09T15:15:15.356Z DEBUG   lightningd: Adding block 2135155: 0000000009280cf53408e61dc935ed553b88c45b70a5d2dc77954ef4ec65757a
2022-01-09T15:15:15.374Z DEBUG

It looks like you have lightningd already running and are trying to start it for a second time hence the error that it can't open the socket.
When you run lightningd on testnet you also have to tell lightning-cli to run on testnet. So I assume lightning-cli tries to connect to the mainnet lightning-rpc which doesn't exist or is down.
So one thing you could do is try to run lightning-cli --network=testnet getinfo the other thing is you could specify  the data-dir of lightningd as a command line argument so that it will find the correct lightning-rpc. Both can be done in your config instead of command line arguments.


text:
Segwit: Does the nodes saves 2 types of blocks (or atleast in the past)
Was wondering for a long why mempool.space was showing blocks greater than 1mb!
Started digging deeper and read these:

https://jimmysong.medium.com/understanding-segwit-block-size-fd901b87c9d4
https://jimmysong.medium.com/segwit2x-what-you-need-to-know-about-the-2mb-hard-fork-27749e1544ce

Able to understand the difference between block size and block weight.
Now few questions

To support the legacy nodes, the upgraded Segwit node will be checking the version of each peer. And if its a legacy node, a trimmed down version of the block will be sent to it. Right?
Is this stripping down of blocks happens on the fly? or both versions of the block are saved on the disk?

Thanks.

To support the legacy nodes, the upgraded Segwit node will be checking the version of each peer. And if its a legacy node, a trimmed down version of the block will be sent to it. Right?

Right.

Is this stripping down of blocks happens on the fly? or both versions of the block are saved on the disk?

At least in Bitcoin Core, on the fly.


text:
Best way to start with Bitcoin today
Question for those with considerable experience in bitcoin:
If you would start with Bitcoin today what would be your primary way for:

Short-term (in a month) way of obtaining bitcoins
Medium-term (in about 6 months) way of obtaining bitcoins
Long-term (more than 12 months) way of obtaining bitcoins

Please mention what resources and knowledge would you need for each these.

this is not an experts judgement, so here are my two cents to this more or less "unprecise" question - you didn't say, what you want to do with bitcoin (use case):
*short term: try a mobile (SPV) wallet or the bitcoin-QT, play some faucets, and start understanding the wording around bitcoin. Very little ressources required, only little knowledge required (reading some forums and bitcoin.org, of course).
*mid term: buy your bitcoins on an exchange or other provider (here in Switzerland we have the railway service - every of their terminals allows you to buy bitcoins). Get prepared to understand the security model of bitcoin - you are your own bank! You don't need special skills, just a good financial understanding.
*long term: develop in any language a trx analyzer or similiar, to understand the logic (and pitfalls) of the environment. This requires programming skills, and a developper machine...

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How to spend from a custom P2SH script using bitcore-lib
My Javascript/typescript project uses bitcore-lib. It uses Script.buildScriptHashOut to build custom P2SH outputs. How do I spend from this custom output?

I could not find anywhere on the web about it. I was hopeless until I noticed that I could, without modifying the library.
First choose a similar class in Bitcore-lib.

multisigscripthash (<== suggested) or publickeyhash for P2SH outputs
multisig or publickey for bare script outputs (don't use these, these are nonstandard)

Then copy it to a new file in your project such as this one**. Do not use typescript classes even if your project is of kind Typescript.
Then change require paths. Also require inherit from NPM. As in the boilerplates above, we need to inherit from Transaction.Input
A function such as "buildP2SHPushIn" in the example should produce the redeemscript. Remember, the last element of P2SH redeem scripts is a push of the P2SH script.
And finally use addInput instead of the higher-level function from to add inputs as shown here**

**The examples are for Bitcoin Cash, but they can be used the same way in Bitcoin. Do not copy from them, however!

Well, the boilerplates listed in "First choose a similar class in Bitcore." are for BTC so I hope my answer is more useful than it is dangerous. I wasn't aware of that incident


text:
How does Electrum get transaction input values?
https://electrumx.readthedocs.io/en/latest/protocol-methods.html#blockchain-transaction-get defines the api for getting txs. Vin values are not included, however. Is it possible to find these without querying for every txid? Is that what Electrum does or is there an easier way?

This appeared in my close votes list, and people voted for "projects that are not Bitcoin". I don't think that it was intentional from MCCCS to link to ElectrumX which was hijacked by a scam (BSV if i remember correctly). Also, this is a question about the Electrum protocol which applies to Bitcoin too. Therefore i'm voting to leaving this open, @MCCCS could you just clarify that it's about Bitcoin / modify the link ? :)

Yes, I'm talking about bitcoin, feel free to edit it so that it is more bitcoiny. Also yes, ElectrumX is developed by a BCH guy but it's also what Electrum uses.


text:
How to calculate conversion exchange fees?
According to Exchange A, I can withdraw 1 BTC as 90 fiat. Or I can send them 1 fiat in return for 0.01 BTC. How do I calculate percentage fees for one way conversion?

The formula to calculate that is:
100% x (1-√(BTC x fiat))

where BTC and fiat are the two values highlighted in gray above.
Using the values given in the quesiton, it is 5.1%.
(Assuming that the conversion fees in both ways are calculated as a percentage, with the multiplier)


text:
Which block has the lowest hash?
Which block has the lowest hash currently? Is there a website that allows to sort blocks by hash?


text:
Why did GBT fail?
GBT was a way to stop miner centralization, but no one used it, everyone continued to use Stratum. Why did it fail?

Closely related: https://bitcoin.stackexchange.com/questions/55015/does-stratum-cause-mining-to-be-more-centralized-than-getblocktemplate-would

Why do you assume it failed? It is in nearly every - if not all - miner setups. Just not for communication with the hashing hardware


text:
How do I properly shut down bitcoind on Windows? I get error: EnvShutdown exception: DB_RUNRECOVERY: Fatal error, run database recovery (-30974)
I am running bitcoind in Windows (interactively) and pressed "control c".  The following error was displayed:
EnvShutdown exception: DB_RUNRECOVERY: Fatal error, run database recovery (-30974)

Is this a bogus error, or could it lead to serious issues?
Did this delay my restart time?

This is the output after I restarted bitcoind:
Bitcoin version v0.7.1-beta (2012-10-09 13:22:09 -0400)
Using OpenSSL version OpenSSL 1.0.1c 10 May 2012
Startup time: 12/09/12 02:35:45
Default data directory C:\Users\Administrator\AppData\Roaming\Bitcoin
Used data directory C:\Users\Administrator\AppData\Roaming\Bitcoin
dbenv.open LogDir=C:\Users\Administrator\AppData\Roaming\Bitcoin\database

ErrorFile=C:\Users\Administrator\AppData\Roaming\Bitcoin\db.log
Bound to [::]:8333
Bound to 0.0.0.0:8333
Loading block index...
LoadBlockIndex(): hashBestChain=0000000000000451ad20  height=193797  date=08/14/12 03:38:39
Verifying last 2500 blocks at level 1
 block index          158518ms
Loading wallet...
nFileVersion = 70100
 wallet                  858ms
Rescanning last 3 blocks (from block 193794)...
 rescan                   47ms
Loading addresses...
Loaded 12371 addresses from peers.dat  78ms
RandAddSeed() 164540 bytes
mapBlockIndex.size() = 193799
nBestHeight = 193797
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
Done loading
send version message: version 60002, blocks=193797, us=0.0.0.0:0, them=0.0.0.0:0, peer=127.0.0.1:0
sending: version (100 bytes)
ThreadRPCServer started

A fix for this was pushed April 30, 2018. See https://github.com/bitcoin/bitcoin/blob/029d28a7aa5619973eb59fe445b9a4186c0c2a58/src/init.cpp#L914

Send the RPC Stop command:
cd "C:\Program Files (x86)\Bitcoin\daemon"
bitcoind stop

Output
ThreadRPCServer method=stop
Flush(false)
blkindex.dat refcount=0
blkindex.dat checkpoint
ThreadSocketHandler exited
blkindex.dat detach
ThreadMessageHandler exited
connection timeout
ThreadOpenConnections exited
ThreadDumpAddress exited

blkindex.dat closed
DBFlush(false) ended          219780ms
StopNode()
Flushed 12513 addresses to peers.dat  280ms
Flush(true)
DBFlush(true) ended               0ms
Bitcoin exited


text:
How do I call JSON RPC API using C#?
How do I access the JSON RPC API in C# in such a way that I can also read the errors that the interface provides?

I use the Newtonsoft.Json.Linq library as shown below to get the data.  Soon, I'll be posting Strongly typed C# client libraries at http://www.coinapi.net
The main trick to getting the JSON error code is to call GetWebResponse() again in the catch method.  Then return and parse the data.  I've debated about including the WebException itself in the return code, but that may require too many changes. If anyone has ideas I'll be glad to take them.
        var ret = InvokeMethod("getblockhash", index);

Here is the definition of InvokeMethod
    public JObject InvokeMethod(string a_sMethod, params object[] a_params)
    {
        HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(Url);
        webRequest.Credentials = Credentials;

        webRequest.ContentType = "application/json-rpc";
        webRequest.Method = "POST";

        JObject joe = new JObject();
        joe["jsonrpc"] = "1.0";
        joe["id"] = "1";
        joe["method"] = a_sMethod;

        if (a_params != null)
        {
            if (a_params.Length > 0)
            {
                JArray props = new JArray();
                foreach (var p in a_params)
                {
                    props.Add(p);
                }
                joe.Add(new JProperty("params", props));
            }
        }

        string s = JsonConvert.SerializeObject(joe);
        // serialize json for the request
        byte[] byteArray = Encoding.UTF8.GetBytes(s);
        webRequest.ContentLength = byteArray.Length;

        try
        {
            using (Stream dataStream = webRequest.GetRequestStream())
            {
                dataStream.Write(byteArray, 0, byteArray.Length);
            }
        }
        catch (WebException we)
        {
            //inner exception is socket
            //{"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 23.23.246.5:8332"}
            throw;
        }
        WebResponse webResponse = null;
        try
        {
            using (webResponse = webRequest.GetResponse())
            {
                using (Stream str = webResponse.GetResponseStream())
                {
                    using (StreamReader sr = new StreamReader(str))
                    {
                        return JsonConvert.DeserializeObject<JObject>(sr.ReadToEnd());
                    }
                }
            }
        }
        catch (WebException webex)
        {

            using (Stream str = webex.Response.GetResponseStream())
            {
                using (StreamReader sr = new StreamReader(str))
                {
                    var tempRet =  JsonConvert.DeserializeObject<JObject>(sr.ReadToEnd());
                    return tempRet;
                }
            }

        }
        catch (Exception)
        {

            throw;
        }
    }


text:
How are pools protected from a client "pretending" to mine?
I understand that the GetWork JSON API is used to get a block that needs to be hashed.
I also understand there are many pool payout methods (PPS, etc).
With regard to mining clients and the pool server, what protections are there to prevent software from pretending to mine  (calling the pool equivalent of GetWork()) and getting a larger share than is otherwise required?

Pools don't measure mining rate by how many times a client calls GetWork. They measure mining rate by how many shares are submitted. A share is just like a normal block solution, except that it is million times easier to find. If you don't mine, you don't find shares.
Related.


text:
Real bitcoin buying versus forex speculation
so I had a discussion with the colleges today and I would that my arguments would be verified here.

Basically the question is what are the differences between buying and selling real cryptocurrencies at cryptocurrencies stocks or cantors and making "positions" on stock exchanges, forex etc.

I personally don't see any reason to play stock exchanges rather than doing so on real cryptocurrency system. For the gold I see the pragmatism and comfort, since there would be hard to transfering gold and would be a bit of risky, but for cryptocurrencies in my opinion is a nonsense.

The other question is if speculation on stock exchanges have an impact of the value of real cryptocurrencies ?

As I believe the real cryptocurrency value is determined JUST on cryptocurrencies stocks where people are selling and buying real bitcoins etc using blockchains ! As this I feel closer to the law of supply and demand. I believe that speculation value is not a real one and is often distorted, as some people bet something (which can be true or not). And I believe that something is worth that much as someone would like to pay for.
At most I can agree that values on stock exchanges can have an psychological impact for the people who are following mass media and the stock exchanges and based on that information they want to trade real cryptocurrencies if they do suddenly, instead of gambling stocks. If they just gamble on stock this does not have an impact at all in my opinion.
Please someone can tell if I am wrong or right ? And give an argument for that.

And the whole story is more or less like this:
Lets say, I am a bitcoin enthusiast. So I met the guy who is speculator with few years of experience, he plays in stock exchanges and is interested in bitcoins, but actually do not know how they works. But I do not know how the stock exchanges works as well. So there is possibility that I am wrong.
So, he told that the ethereum price get lost in his stock exchange for a minute down to 1 $. This was caused by someone who have finished his "position", so as I understand someone who had lots of ethereum coins decided to sell them at once, so he satisfied all the needs on this stock exchange so there was a lot of ethereum coins available to buy, while no people willing buy coins for that quick moment. This caused lost of value of ethereum IN THE STOCK EXCHANGE. This could be true information since he show me some article from some stock exchange news web page.
And for that story I have said that for me this is not important at all. Because I believe in the value which is described by the real forces of supply and demand of REAL CRYPTOCURRENCIES. So in my opinion REAL VALUE of REAL ETHEREUM have not went down at all even for this minute. Because all the guys who have been bet / gambling / playing on stock have never had any true / real ethereum.
As I understand situation they just transfered the money to the stock. Then make a "position" so nothing more like an entry JUST in that stock exchange, on which they converted the real currency into ethereum / bitcoin / gold / other real currency. But as I believe they never had any value in real blockchain, they can't pay anything by ethereum and they never could and never would be able until they buy real crypto currency. So they can just convert back this entry in that stock exchange and get back real money (less or more depended on their gambling score).
Because of that this operation (selling lots of ehtereum in some stock exchange) does not have any impact on real ethereum value, neither on cryptocurrencies stocks like bit bay etc.
Another friend starting to saying what if the current monetary system would fall down.. But this is an argument for my theory too ! Because if the system fall down while I would have real bitcoins written into blockchain and my friend would have an entry in his stock exchange. Then he can get back his dollars, but they would be worthless. And I would still be able to transfer a value. Then I heard an argument about the world get lost electricity but this scenario I just skipped..


text:
Setting up wallet on new machine with 12 word passphrase - next button greyed out
I have Electrum 2.8.0 on a Mac with a wallet I'm logged into.
I've gone to Wallet / Seed to get the 12 word passphrase.
I then have a Windows 10 PC with Electrum 2.9.3 on. In the install Wizard I type in the 12 words, but then 'Next' button is still greyed out.
Shouldn't the Next button stop being greyed out when I've typed all 12 words (checked multiple times)? How do i restore using the passphrase seed on the new computer?

You can see this FAQ entry regarding this problem. It covers various possibilities.


text:
My claim was accepted on MtGox.com - how do I get the cash out?
My claim was accepted on MtGox.com - how do I get the cash out?
It lists a Yen figure but it's totally unclear what to do next.
Is it too late to transfer to Kraken and get bitcoin back?
How can I do this, can't find anything online - only options are to view, change password and transfer the amount to another person?!

All information is provided on https://www.mtgox.com/. As you can see, this is going very slow, the latest update was on 8th March and the next update should come after 27th September.
If you read the latest report, you can see that the secured assets are lowering in time (most likely due to payments for investigations and cost of the bankruptcy processing). You can also see that there is a huge gap between assets + bitcoins and liabilities, which means that even if payout was going to happen today, you would get just a fraction of your claim.
The case will likely take many more months (years?) before the payouts are going to happen. And then you should not expect much to get back.


text:
I run a full node. Is there a desktop client to connect to this full node?
I run a full node on my Raspberry Pi at home. I want a desktop wallet that uses this full node. Not interested in using remote-x or xpra or setting up an electrum server.

There are a few android wallets that can. For desktop i guess you could run a bitcoin-qt in pruning and blockonly mode to make it as lightweight as possible. Make a whitelisted connection to your full node (possibly over Tor if you're not at home).
Maybe the Neutrino medium weight client (no experience though).

armory or msigna could probably connect to it.


text:
RPi3 bitcoind and solo mining
I am setting up a Raspberry Pi 3 to be a full node and miner. I know I will probably never win a mining block. I am doing this for fun and learning.
I do not want to do a pool. I want to just do solo mining to learn how it works.
I set up bitcoind from the official bitcoin 0.13.2 git repo.
I found a cpuminer (minerd) and am setting that up.
The question I have is about the wallet address that will receive any bitcoins that get generated as a reward for mining a block.
I know that when a miner wins the mining of a block it creates a transaction in the block to receive the bit coins that are rewarded.
What I don't understand is how that wallet address gets created.
I have created my own wallet on another computer and would just like any rewarded coins for mining to go into that wallet.
I also know that you can create a wallet on the mining computer (RPi) itself. Is that required?
Please give some instructions on how to set up that mining reward address wherever it needs to be set up.
Like I said I probably will never be lucky enough to mind a block, but if I happen to get lucky I want to have a proper address set up to receive that reward.

Based on the source cpuminer has a --coinbase-addr parameter which accepts a bitcoin address (for example: ./cpuminer --coinbase-addr=1abcdef..., I believe you only need to set this.
The program checks if you have provided an address and if not then switches to "getwork" mode, unless you disabled it by adding the --no-gbt command line switch.


text:
How can I tell if someone is trying to hack port 8333?
I am experimenting with leaving a public replica of the Bitcoin chain on the internet.  In doing so I'm actively monitoring the debug output so I can get a sense of what is happening with the inbound connections.
How can I tell what the clients are doing and respond appropriately?
Under what criteria should I block a port to an IP address, subnet, etc?

The client shouldn't rely on any special firewalling or packet inspection.  It should be secure against all hack attempts.
If you are concerned about there being a denial of service you can disable incoming connections and only support outgoing.

You are looking for ways to improve the client's protections against flaws?
Here's a list of its current protections:

http://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks


text:
What does the debug output look like when a new block is found?
In the Bitcoin-QT client, what does the debug.log look like when a new block is found?

I got the following output when I set gen=1 on test net:
BitcoinMiner:
proof-of-work found
  hash: 00000000502cfb2fe549f1d672ff60cab179b8c91c95fe6d4d9dce490a8e00e8
target: 00000000ffff0000000000000000000000000000000000000000000000000000
CBlock(hash=00000000502cfb2fe549, ver=2, hashPrevBlock=000000008efd2a2075c9, hashMerkleRoot=cae3a8d5d1, nTime=1355478291, nBits=1d00ffff, nNonce=119890730, vtx=1)
  CTransaction(hash=cae3a8d5d1, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 03b39b00010e062f503253482f)
    CTxOut(nValue=50.00000000, scriptPubKey=031e72826fe94305e81a34e34ea316)
  vMerkleTree: cae3a8d5d1
generated 50.00
keypool keep 6
AddToWallet cae3a8d5d1  new
NotifyTransactionChanged cae3a8d5d1feb8e058ddf4a30d021a9f1f85775b474456f4d6b595ffd832b7f3 status=0
updateWallet cae3a8d5d1feb8e058ddf4a30d021a9f1f85775b474456f4d6b595ffd832b7f3 0
   inWallet=1 inModel=0 Index=0-0 showTransaction=0 derivedStatus=0
SetBestChain: new best=00000000502cfb2fe549  height=39859  work=4384611213659391  date=12/14/2012 09:44:51

ProcessBlock: ACCEPTED
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
keypool added key 110, size=101
connection timeout
keypool reserve 10
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549

I am curious about this too - did you have to specify a recipient address for the newly generated coins, or does the client pull one from the keypool and display it in your wallet?


text:
What development tests should I do when creating a Base58Checked parser?
Are there any special tests (test data) I should run against my code if I've written a Base58Checked encoder/decoder?

Hi makerofthings7, I think this question is on-topic, but you need to clarify what specifically the test data is supposed to do (validate your implementation?  performance test it?  etc.).  Otherwise there aren't any real concrete answers (what this site is designed for), only opinions (which this site is not designed for).

I'm using BigInteger in .NET so these tests are unique to this scenario but may be adapted to Java or other languages.
The tests I've found helpful is when translating to or from hexadecimal at any intermediate step make sure the data is correct when:

The first or last byte of the checksum is one or more 0's
The first or last byte of the address is one or more 0's

Often times this may cause two's compliment errors depending on the implementation of BigInteger that is being used.
I'll run my own version of vanity gen to generate addresses that have these errors and will post them here.


text:
Why does Mt Gox disallow YubiKeys purchased direct from Yubikey.com?
I have several Yubikeys and would like to use one or more with MtGox.... however it seems that I can only use keys purchased from Mt Gox on their site.

Why did Mt Gox choose to implement security this way?
Suppose I'm creating my own secure website based on Yubikey.. what are the conditions that I would choose to implement a "closed" system like this (and not allow other Yubikeys)?

I asked Mt Gox support this very question and all they told me was:

Hello, Thank you for the email. Please note that the yubikeys
  has to be pre-configured with our systems, so unfortunately it is not
  possible to add yubikeys that are purchased outside. Thanks, MtGox.com
  Team

... so I'm hoping to get a better understanding on why this choice was made.

Without speculation, only MtGox can answer that question definitively.

Properties of a yubikey:

A yubikey contains a secret symmetric key.
Knowledge of this key allows emulating that yubikey.
The server needs to know that key.

The YubiKey AES Key information can never be extracted from a YubiKey device – only programmed to it

So Mt.Gox's insistence on sending the key to you ensures several important properties:

You're not tempted to use the same key to authenticate to other websites, which would allow those websites to break into your Mt.Gox account
You don't need to send the key to the Mt.Gox server through your potentially insecure computer
Nobody but Mt.Gox knows the key stored in your yubikey

So pre-programming yubikeys and sending them to you only after the key was programmed into the device rules out several possible threats, and thus seems reasonable risk management.

@Lohoris Wouldn't that require loading a new AES Key, and thus invalidating that key for Mt.Gox use?

@CodesInChaos oh, true. I'll delete my wrong suggestion.

YubiKeys can hold two profiles, one activated with a short button press and one with a longer button press. They could program the YubiKey such that their profile is locked but you can program the other profile so you could still use the YubiKey for other accounts. Though there would always be a risk that you'd get the button press length wrong and send a live Gox authorization to some other site.

This answer is incorrect. Yubikeys direct from the factory are compatible with YubiCloud. Using them with a website does not require the website to have knowledge of the private key. None of the three risks you list are actual risks.
The only reason to actually do this is to avoid outages when YubiCloud goes down, but uptime on YubiCloud is very good as the service is very simple (validate signature, increment counter).

The only problem with this is that someone at Mt. Gox could potentially know or discover the symmetric key for the YubiKey you purchased through them.  The keys loaded onto YubiKeys purchased directly from Yubico are neither available to Yubico employees nor to you, the user, and are stored securely with Yubico via their YubiHSM devices.  Mt. Gox may be using similar hardware to secure the keys for their YubiKeys, but we don't know how securely their YubiKeys are programmed or exactly how the keys are stored by Mt. Gox.  Without this knowledge, which we have with reasonable certainty in the case of YubiKeys straight from Yubico, we can assume that the YubiKeys sold my Mt. Gox are either as secure as those sold by Yubico or less secure.
My thought is that Mt. Gox insists on programming their branded YubiKeys themselves so that they do not depend on Yubico's YubiCloud service for their customers' ability to authenticate with their servers.  Right now, YubiCloud authentication is free, and Yubico offers a paid option that guarantees YubiCloud uptime and availability, but IMHO the SLA price is high (right now $3/YubiKey/year).  This way, Mt. Gox can take it upon themselves to guarantee availability of the YubiKey authentication service and not depend on Yubico at all.
I agree that it would be nice if we could use our own (non-MtGox-branded) YubiKeys with their service.  One of the problems with regular old passwords is that you have to have so many of them to make sure that the compromise of one doesn't affect all the others.  Strong two-factor authentication devices like YubiKeys were supposed to partially solve this problem, but now we're seeing an increasing number of services that require you to purchase a specially-branded YubiKey to work with their servers.  The resulting keychainfull of YubiKeys is arguably worse (and definitely more expensive) than a USB drive full of passwords.

"The resulting keychainful of USB keys" ... I'm starting to see that and asked a similar/related question here http://security.stackexchange.com/q/26261/396

You might be able to reprogram a Mt. Gox Yubikey with ykpers or the gui version, but then it probably won't work with Mt. Gox.
UPDATE: After following the instructions here, I discovered the Mt. Gox Yubikey is protected by a "configuration protection access code."
From the manual:

Protection of the key and configuration data
Given the symmetric nature of the AES encryption algorithm, the
  security of the Yubikey relies that the AES key is logically and
  physically protected both in the key and in the server that verifies
  the OTP.
The configuration data is updated via a configuration API, accessible
  via the USB interface. To prevent unauthorized update, the
  configuration can be protected by a 48-bit access code. If used, an
  exhaustive search of all combinations would typically take some
  100,000 years to perform. Furthermore, the Yubikey configuration data
  is write-only, i.e. configuration data and the key can only be written
  but not be read. This means that unauthorized update of the
  configuration is an act of sabotage rather than a security threat.
The configuration data is stored in a non-volatile storage integral to
  the microcontroller. A potential attack is to physically probe the
  silicon or analyze the hardware behavior to potentially gain full or
  partial knowledge of the stored secrets. However, such an attack would
  require a complete break-up of the Yubikey, involving dissolving the
  microcontroller chip encapsulation. Furthermore, very advanced
  equipment is needed to probe the chip internals. Given the effort and
  costs involved for such an attack, this is not considered a threat
  given that just a single device will be broken.

So it should still be possible to "sabotage" a Mt. Gox Yubikey, no?
Hopefully the above description of how the Mt. Gox Yubikeys work helps you see why they can't use non-Mt. Gox Yubikeys: the "configuration protection access code" would no longer be Mt. Gox's secret.


text:
Which clients support nLockTime?
I want to use nLockTime, but I don't know what clients support it?

No standard client supports NLockTime directly AFAIK.
You can create raw transactions with bitcoind and then use a standard client to transmit them to the network in the method described here


text:
Corrupted transaction
In this transaction There's a decoding error and an escrow. What could cause this?

The decoding error is not really an error, per se, just an OP_RETURN. OP_RETURN is used for storing data in the blockchain and that's what this transaction is doing. It's not actually a spendable output, so the block explorer is getting confused and puts out a decoding error.


text:
Vanity generator
Imagine that there are two really strong computers that try to find an address starting with 1ABCDEFGH. Is there a possibility does that two computer find the same private key?

You have enough entropy in Bitcoin private keys to make this possibility extremely unlikely (just like with non-vanity address).
A nice chapter on vanity addresses (their generation, security etc) can be found at: http://chimera.labs.oreilly.com/books/1234000001802/ch04.html#_vanity_addresses.

Theres a possibility, its still unlikely.
heres a couple of attempts.  Not quite as many characters since it will take to long.
1AbcDeF22LQFTudvxEPzPUo4LQsNLVUUGT
1ABcDefEJv156aq32SmQo8aU4EVPHqwxV4
Case sensitive will take longer.
1ABCDEkreuP3HqnqEivk8NQzLw5afz3mXW
http://directory.io/ has a list of all bitcoin public/private keys
still looking for an atom in the galaxy.

Wait, I thought directory.io was fake? https://directory.io/faq Here it says its a joke.

@MCCCS it is a joke, but the data generated is real. It's just proving a point that being able to generate the data doesn't really help you, there are still so many addresses that it's impossible to search.


text:
Longest-time-verifying block
I heard that there was an old block with one transaction and it takes 20 seconds of CPU time to verify.
1) Which block was it? I forgot its block height.
2) Is there a block that takes more time to verify? Or is there a similar block?

bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 is usually the transaction referred to as being the megatransaction that took seconds to verify. It is the only non-coinbase transaction in block 000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe.
Nowadays this transaction is verified much faster than 20 seconds. Last time I benchmarked this, it was ~1 second. With the introduction of assumevalid in Bitcoin Core 0.14, the transaction's signatures are no longer fully validated so it takes the same time as most other blocks, ~60 milliseconds.

I'm not completely sure if this is what you are looking for, but it may be.
Here you have a type of transaction that takes 3 minutes to verify, and that was reported back in 2013. (CVE-2013-2292). Moreover, in Sergio Demian Lener's blog you can find a related topic, where he explains how he found a vulnerability that used the FindAndDelete function and OP_CODESEPARATOR to create a transaction that toke up more than 5 hours to verify.


text:
How do I migrate my Bitcoin Core wallet to an HD wallet?
I created a wallet before Bitcoin Core 0.13.0 was released so my wallet is not a HD wallet. How do I make my wallet a HD wallet?

A thumbs up because it's your first question, and have given so many answers.

He is basically just asking when he is also answering himself. :)

Since Bitcoin Core 0.17, there is an automatic way to directly upgrade a wallet from non-HD to HD. Simply start Bitcoin Core with the  the -upgradewallet option and have no other wallets (i.e. remove all -wallet= and wallet= options from the command line and bitcoin.conf respectively) being loaded. -upgradewallet does not work when multiple wallets are loaded. This will automatically generate a new seed and keypool while also retaining all of your old private keys and transactions so nothing is lost.

Prior to Bitcoin Core 0.17, there was no mechanism for migrating non-HD wallets to HD wallets. If you don't want to upgrade to 0.17+, then migrating your coins to an HD wallet is possible, at the expense of invalidating your backups and a bit of work.
First you will need to backup your current wallet. Stop Bitcoin Core and back up your wallet.dat file. Now rename your wallet.dat file to something else, like wallet-orig.dat.
Now start Bitcoin Core again. Bitcoin Core will create a new wallet.dat file. This one will be HD and that will be the file that you want to actually use later.
Once Bitcoin Core has started, encrypt your wallet and restart Bitcoin Core. Once you have restarted it, you should see no transactions and no (or one) addresses. Now get a couple of addresses and write them down somewhere. Stop Bitcoin Core again and backup your new wallet.dat file. Rename your new wallet.dat file to something else, like wallet-new.dat and rename your old wallet.dat file (wallet-orig.dat) back to wallet.dat.
Start Bitcoin Core again. You should see your old addresses and transactions. Go to the Send tab and send your Bitcoin to the addresses that you wrote down earlier.
Finally, stop Bitcoin Core, rename your new wallet.dat file (wallet-new.dat) back to wallet.dat. Back it up again and start Bitcoin Core again. You should now see transactions from your previous wallet sending Bitcoin to your new wallet. Once those transactions have confirmed, you have successfully migrated your Bitcoin from a non-HD Bitcoin Core wallet to a HD Bitcoin Core wallet.

In Bitcoin Core 0.17.0, they added a startup option -upgradewallet which does the upgrade to an HD wallet, and retains all history.

Since Bitcoin Core 0.17, there is an automatic way to directly upgrade a wallet from non-HD to HD. Simply start Bitcoin Core with the the -upgradewallet option and have no other wallets (i.e. remove all -wallet= and wallet= options from the command line and bitcoin.conf respectively) being loaded. -upgradewallet does not work when multiple wallets are loaded. This will automatically generate a new seed and keypool while also retaining all of your old private keys and transactions so nothing is lost.


text:
How does Bitcoin Gold implement replay protection?
The creators of Bitcoin Gold claim that they have implemented full replay protection. How does this replay protection work?

I don't believe any replay protection has yet been implemented, they still have an issue open for it on the BitcoinGold repository here:
https://github.com/BTCGPU/BTCGPU/issues/51
I haven't dug into the code itself but I would imagine that they would have closed the issue if they had implemented something.
The statement by Bittrex also claims that they haven't implemented any replay protection: https://support.bittrex.com/hc/en-us/articles/115002320451-Statement-on-Bitcoin-Gold-BTG-
Update as of 3rd November 17:
A PR for replay protection has been merged, https://github.com/BTCGPU/BTCGPU/pull/109
They announced it via twitter here: https://twitter.com/bitcoingold/status/925600171425259520
It uses a new SIGHASH_FORKID to implement the 2-way replay protection.

It's worth mentioning it is (hashtype | SIGHASH_FORKID (0x40) | 79 << 8 (20,024))


text:
Does sending the "max amount" with given feerate require crafting the transaction twice?
To make a transaction of "max amount" with a given feerate, is there a shorter procedure than the following?

Craft transaction with with one output
Sign it
Consider the signed length - multiply it with the feerate
Subtract the difference
Set the dest amount
Re-sign it

No, you shouldn't need to sign the transaction until it's completely crafted. Bitcoin core can handle this for you!
An easier flow when creating a transaction is

Create raw transaction. Don't add any inputs yet.
Fund raw transaction. This will select inputs for you. Add subtractFeeFromOutputs of the output you want to subtract the final fee from. The docs on subtractFeeFromOutputs is a bit confusing, but it wants you to specify which output(vout) the fee should be deducted from. If you specify multiple outputs, the fee is spread equally across the outputs. Bitcoin core will amend the amount in the output(s) you specified.
Sign your raw transcation. Voila, you're done!


text:
How can I run bitcoind on test and production networks, at the same time, on the same computer?
Bitcoin and Bitcoind will send an error if it is launched multiple times.  I'm assuming this is because they share the same database and wallet.
Is it possible to run two instances of Bitcoin QT / bitcoind with one listening on Production and the other on Test? (on the same computer)
Is this advisable or not advisable?

You can run a mainnet and testnet bitcoind next to eachother without problems. They do not share the same database (one will use the testnet3/ subdirectory).
What will conflict is the RPC port, as they will both try to bind to port 8332 for receiving RPC connections. Use -rpcport=N on one of them to use a different port.

Thanks! My goal is to help out with testnet replication.  Will running on an alternate port cause issues with other clients discovering me?

Communication with other nodes is done using the P2P port, which is 8333 for mainnet and 18333 for testnet by default. The RPC port is only used for locally sending commands to bitcoind.

I just launched testnet on the same computer as production.  I saw that the following directory is being used: Default data directory C:\Users\Administrator\AppData\Roaming\Bitcoin  Specifically will debug.log, peers.dat, or wallet.dat be altered?  Will bitcoin.conf be read?  It appears that after running testnet, my debug.log was truncated.  ( I did have a large debug log running in production)

As of Bitcoin Core 0.7.1 (19 October 2012), you can run both mainnet and testnet by simply starting Bitcoin Core with the appropriate flags:
bitcoind -daemon           # mainnet, -daemon will cause it to fork into the background
bitcoind -daemon -testnet  # testnet

As of Bitcoin Core 0.9.0 (19 March 2014), you can easily use bitcoin-cli to send commands to both nodes:
bitcoin-cli getinfo           # mainnet, uses port  8332 for RPC-JSON
bitcoin-cli -testnet getinfo  # testnet, uses port 18332 for RPC-JSON

Also as of Bitcoin Core 0.9.0, there is a regression test mode ("regtest") that can speed up development and testing of apps by nearly instantly generating an alternative block chain with super-low difficulty.
By default, regtest mode runs on the same ports as testnet (18333 for Bitcoin P2P, 18332 for RPC-JSON/HTTP REST), although it does use a different data directory from testnet.  That means the two commands below will both address a default testnet or regtest node:
bitcoin-cli -testnet getinfo  ## sends command to port 18332
bitcoin-cli -regtest getinfo  ## also sends command to port 18332

This answer has some basic sample code showing running two regtest nodes on the same machine, but you can also do something similar if you want to run a testnet node and regtest node at the same time.

Post script: Pieter Wuille's accepted answer confuses me.  It says he wrote it on 9 December 2012, but this merge by Pieter says he added code (written by @kjj2) changing the testnet port to 18332 on 28 September 2012---over two months earlier.  Also, that code was included in Bitcoin Core 0.7.1 released in October 2012, still almost two months earlier than Pieter's answer.
Shrug.  I guess maybe he just forgot about the change.

I probably did :)

Maybe you should try using different directories through the datadir argument. That way the production data and test net data would be stored in different folders.
REF: https://bitcointalk.org/index.php?topic=771930.0


text:
In the sourcecode, what does this line mean that recovers the key from the signature?
I understand that the public key (Q) can be extracted from a signature (r,s), but I'm having trouble understanding this line:
if (!key.Recover(hash, &vchSig[1], (vchSig[0] - 27) & ~4))

The third variable is called "rec" and must 0 through 3.

What is the purpose of this parameter (3rd one)?
Why is the signature starting a byte1 and not [0]?  Perhaps I'm not properly understanding "where" r and s is located in the Bitcoin signature.

By any chance is the signature format encapsulated in any standard? PKCS..? etc.

It's a custom format that encodes both a signature, and a parameter that allows the public key to be reconstructed from it.
Given a signature (an (r,s) pair), and the message it signs, there can be up to 4 different public keys for which it is valid. To know which one, the number is encoded along the signature.
The first byte is this recovery parameter plus 27. If the corresponding public key is to be a compressed one, 4 is added. The next 32 bytes encode r. The last 32 bytes encode s.
Note that this format is only used for message signatures. The scheme used for transaction signatures is older, doesn't support recovery, and uses DER encoding.


text:
Debug.log : How do I analyze an orphaned transaction?
The debug.log for my machine lists the following information while synching
ERROR: FetchInputs() : 5b5e32cc97 mempool Tx prev not found e99babf87a
stored orphan tx 5b5e32cc97 (mapsz 414)
received: tx (227 bytes)
ERROR: FetchInputs() : 93ce7eee97 mempool Tx prev not found 8d56e0b192
stored orphan tx 93ce7eee97 (mapsz 415)
received: tx (259 bytes)
ERROR: FetchInputs() : 7baab3c99a mempool Tx prev not found 2ca8483584
stored orphan tx 7baab3c99a (mapsz 416)
sending: addr (181 bytes)
Flushing wallet.dat
Flushed 12367 addresses to peers.dat  62ms
Flushed wallet.dat 5335ms

Is it correct to say that the orphaned transactions were added to the chain, but was replaced by another block?
Are orphaned transactions replicated to my client when I download the chain?
How can I tell if the orphaned tx ever made it into a block?  (would the # stay the same?)
What is a mapsz and when is it important?

An orphan transaction is a transaction that consumes a coin whose creating transaction is not known to your client. This has nothing to do with orphan blocks (which are blocks whose parent block is not known, or according to another definition, blocks that are no longer part of the best chain).
Orphan transactions are not part of a block (they cannot be verified until their parents are known, and only valid transactions are allowed in blocks), and are kept in memory in the client. When their parents become known, and they are found valid, they are moved to the memory pool (which is - as the name suggests - also kept in memory only). From there, they are considered to be included in new blocks (if you're mining).
This piece of debug.log tells you that there are 3 transactions received (separate transactions, not part of a block) that reference some inputs that aren't known. Because of this, they are stored in the orphan pool, which grows as a result of that. "mapsz" stands for "map size" (as the orphans are stored in a map) - the number is just the number of remembered orphans.


text:
What is a "search space" in PPCoin and how is it used?
The PPCoin whitepaper describes "search space" without any context of what it is.  Can anyone describe what search space is?

Search space in cryptography refers to the sum of how many different solutions there can be. For example, a bit has a search space of 2 - 1 and 0, white a byte has a search space of 2^8 or 255.
In this context, the search space refers to how many different possible hashes there can be for the proof of stake (I believe) algorithm.


text:
How to explain blockchain in terms of OSI 7-layer model? Is it based on service in the transport layer
I am newbie to block chain. AFAIK, blockchain is a distributed database that maintains a continuously-growing list of records called blocks secured from tampering and revision.
How does this technology be explained in terms of OSI 7 layer model?
Thx
JT

The blockchain is a data structure that every node in the network independently builds, based on messages that are exchanged in a network.
Blockchains don't prescribe what this network protocol looks like. The OSI model is a way to describe layers in a network, not data structures.

AFAIK, blockchain is a distributed database [...]

In a distributed database there is usually a coordinated distribution of data across nodes such that individual nodes only have a subset. The Bitcoin blockchain is not a distributed database of this sort. There is no coordination and no centrally managed subsetting.
Bitcoin's blockchain is a replicated database. Every full node has a complete copy.

[...] that maintains a continuously-growing list of records called blocks secured from tampering and revision.

True. Really it is a list of records of transactions. You can think of blocks as like pages in a transaction journal.

How does this technology be explained in terms of OSI 7 layer model?

It isn't and can't be.
The ISO OSI 7-layer model was mainly associated with the X25 data network. It is obsolete. It does not apply to the Internet which has it's own 4-layer model.
The Bitcoin network protocol is at the application layer in this 4-layer model. It mostly uses TCP at the transport layer and IP at the inter-network layer.
The Bitcoin network protocol allows each Bitcoin node to gossip with a handful of peer nodes in order to exchange data including blockchain data items such as blocks and transactions etc. In this way blockchain data percolates across the planet.

This might technically be incorrect, however philosophically it is the only way to explain "the blockchain" without going in this cryptocurrency-"asset/value transfer"-rubbish which really is not what the blockchain is about.
So, lets assume there are 8 layers. The 8. layer is the blockchain layer, its whole purpose is to answer the question
who did what when
on protocol level, ie. accessible and available for all like FTP/HTTP (TCP/IP) for data transfer.
Now it should make more sense to you why asset transfer and votings and patents and author's rights and backoffice optimization are all use cases for blockchain technology: "who did what when".
taken from: https://monax.io/explainers/ecosystem_applications/

To know who did what when, use a log file with auditors. A blockchain does not make things magically immutable - it does so through the use of consensus algorithms among a set of trusted parties (PBFT, private blockchains), or through economic incentives in public (Proof of Work, public network). The latter only works when there is a subsidy to incentivize convergence, something that isn't available for general purpose logs.

you are perfectly right for a specific context or environment, eg. a organisation, a company, etc. Then of course auditable logs are the best fit for this and a blockchain doesn't make sense at all. I was thinking of a environment of several parties, probably even in competition, which do not have processes or rules to set up a "auditable log" since there is no admin, no processes, no agreed-upon rules. Then a common "infrastructur component" which answers the question permissionless and decentrally is what you need.

If you want permissionless, you need economic incentives instead of trusted parties. Logging can't provide those, a currency can.

For sure, that's why logging is completely different use case here. Permissionless must go with economic incentives and since there are no trusted parties, the blockchain with incentives is the only possibility to enable "who did what when" in a public permissionless environment.
In a permissioned, (private/consortium) chain with trusted parties you could argue that auditable logging or a central audit database might also fit, but I would challenge this since "trust" is not identical to having an common infrastructure and processes you need to set up a central solution.

In short: having a "currency" (ie. economic incentives) in a blockchain is a fundamental part of permissionless public chains to work, but that's all it is, a basis for other things to build upon and not the key feature of a blockchain. The key feature is the answer to "who did what when" on protocol level. One "implemetation" of this key feature is currency. Another one is voting, "proofing", auditing, timestamping, "who did what when", permission- and trustless.

You can't pay a miner with timestamps.

yes, that's why you pay for timestamping, not with.

I'm not talking about the users of the system, but the incentives of the system itself. Bitcoin is only secure because the subsidy pays miners more than what a fraudster could reasonably pay them to revert transactions. Paying a miner to censor votes, or include fraudulent proofs is trivial otherwise.

Timestamping can be done off-chain, with only non-invasive commitments inside an otherwise functioning monetary chain, but won't protect you from having commitments to conflicting data (which is not an issue is all you want to know whether some piece of data existed at a certain point in time). Voting is much harder, as you're essentially letting the highest-paying voters determine what gets included (if miners are behaving rationally). If your chain has no monetary function at all, you can't pay for things, and you can't prevent reorganizations (as those would become cheap).

I don't object all this, the only thing which I think is important: the blockchain answers "who did what when". It does this by using economic incentives. Timestamping, voting, proofing, etc. is not difficult at all because miners are not interested in the payload, but in the value of the transaction or what they can earn by including it, which is measured in a cryptocurrency. So that's the infrastructure part of the blockchain and it works pretty well.

Ah, you want all of this in a blockchain that does have a currency associated. Yes, I agree that it can work, but only as long as these non-financial uses don't interfere with the operation of the currency (and not for example what happened to Namecoin: overcrowded by data storage making it useless as a currency, and thus indirectly killing its security).

All of that works fine for pure timestamping (which only needs a hash). I'm not convinced it can work for auditing (needs linearly growing data storage), voting (those who pay most win? seems a bad property), or in general anything that needs identities (as miners can always choose to censor who they don't like - or be paid to do so).


text:
datadir compatible between 0.14.0 and 0.14.1
I have a raspberry pi with bitcoin core (0.14.1, self compiled) and a macOS system with bitcoin core (0.14.0, binary from bitcoin.org). I am storing the blockchain (complete datadir) on an external hard drive. Can I expect to plug this hard drive in my macOS system, sync it and later plug it into my raspberry without having any problems?

Switching between different computers/platforms should work. Don't try to use a NAS (network attached storage).
Always make sure you did a clean shutdown before switching the computer(platform.
Make sure you either use the binaries from bitcoin.org or compile with the same berkleyDB version (to ensure to not break the wallet.dat database).


text:
Is there a blockexplorer with a websocket API that includes relay IP address?
I have a visualization that shows realtime bitcoin transactions plotted on earth: https://blocks.wizb.it.
I relies on blockchain.info's websocket API, which used to include the relay IP per transaction but unfortunately it is now always including 0.0.0.0 instead of a public IP. I've tweeted them about it, but I am looking for an alternative. Does anyone know one?
I am running a full node already, however it is not well connected enough to do this myself and actually get more than 10 different peers.

It looks like a blockchain.info API bug.
https://blockchain.info/rawtx/315d3cf722b73a2ad434dc3dba108bfb5ccdb13ea324bfa4d6e17ca3e741ad1f
"relayed_by":"0.0.0.0",
https://api.blockcypher.com/v1/btc/main/txs/315d3cf722b73a2ad434dc3dba108bfb5ccdb13ea324bfa4d6e17ca3e741ad1f?limit=50&includeHex=true
"relayed_by": "213.239.196.9:8333",
Note: I have no association with either API, but I have used Blockchain.info before, and know it can be buggy.
Also, relayed_by: 127.0.0.1 means that blockchain.info relayed it themselves.

Ah blockcypher also has a WS API, I can use this until blockchain.info recovers. Thanks!


text:
utxo vs account-model
There are two possible models, the UTXO model and the account model. Each has advantages and disadvantages. Bitcoin chose the UTXO model. XRP and Ethereum for example use an account model.
What are the advantages and disadvantages of each model?

It is not. My question is generic as you can see he asks something specific.

Maybe the question isn't, but I think my answer there covers your question as well.

Nop. If this would be the case @David Schwartz would not have suggested to open a new question about this topic in this thread: https://bitcoin.stackexchange.com/questions/20611/why-do-outputs-need-to-be-spent-entirely/20623?noredirect=1#comment86236_20623

Maybe he wasn't aware of the question there, or feels information is missing. That's fine. I'm simply stating that my answer to this question would be identical to my answer there.

The question at your link is totally specific, my qustion is generic. I suppose the answer it totally different or lets say the answer here should be much more comprehensive (spv, light-clients trust, privacy, smart contracts etc etc).

That question only addresses scaling and doesn't address any of the other benefits of the account model, such as the ability to manage properties of accounts.

No, it explains how it adds complications (which are solvable, as you point out) while worsening privacy. As a result, I believe there are no advantages to the account model - encouraging linkage of transactions is giving up on creating a fungible currency.

@PieterWuille Being able to rotate your keys without having to move your money or tell everyone who might need to send you money about your new receiving address isn't an advantage? Being able to use a single receiving address for multiple currencies isn't an advantage?

@DavidSchwartz They certainly make things easier to reason about, as they make the on-chain data more accurately match the reality of funds movement. However, I believe that is the wrong place to solve this. Describing more than what is needed for validating the correctness of your ledger is gratuitously giving up privacy, which hurts the fungibility of the currency. All the things you bring up can be solved at higher levels, with better privacy and scalability trade-offs. Anyway, I mostly agree with your answer below.

The primary advantages of the UTXO model are simplicity of implementation and improved privacy.
With the UTXO model, transactions just consume some UTXOs and create some UTXOs. This tight constraint on what transactions can do makes transactions simpler and easier to execute in parallel.
The UTXO model also improves privacy by making it more difficult to associate transactions issued by the same party.
The primary advantages of the account model are improvements in transaction flexibility, account management, and multi-currency capabilities. A transaction in an account model can do much more than just consume and create UTXOs, it can modify persistent data associated with an account. This permits functions like order books and cross-currency payments.
Perhaps most importantly, it allows an account to be managed. For example, the XRP Ledger permits accounts to change their cryptographic credentials. You can have a publicly known receiving address and change the key needed to spend funds sent to that address without having to communicate a new address or move funds.
On a multi-currency system, accounts can specify assets that they're willing to accept as payment. So, for example, if I owe you US dollars, I can check your account settings to see what assets you accept for dollar payments. The enables the XRP Ledger's foreign asset system, enabling the largest decentralized exchange in the world.
Lastly, an account model makes it easier to bring new servers up. The number of accounts will generally be much less than the number of UTXOs in a comparably sized system. This means less data needed to bring on new nodes.

What about light clients and SPV, what are the differences there?


text:
Atomic Swap - Problem?
Can somebody explain me why atomic swaps are not flawed in that way:
When I give him/her my secret he/she could decide wheter to make the trade or not. If the price does favor him/her after a certain amount of time he/she will execute the trade if not wait for the timeout. Do I miss something?

What's the flaw?

I mean not flaw, but it is communicated way better than it actually is imo. I mean is my statement true?

I'm not sure if I understood, but maybe yes. I think people doing that would be blacklisted or something for trolling.

I think it's a very valid point. perhaps can be addressed by limiting the period to a few minutes and automate the channel.

There is a problem with the transaction favoring a party, and they can use the timeout to their advantage. But it is not as dire as some think.
Here is an example:
Alice creates a contract on the Bitshares blockchain that will pay Bob 1 Bitcoin if Bob can come up with the secret. If he does not do this within 24 hours, Alice gets her Bitcoin back.
Bob creates a contract on the Litecoin network that will pay Alice 2.5 Bitcoin if she comes up with the same secret within 12 hours.
Alice has a small advantage here. She has the secret. She can wait until near the 12 hour mark to decide if the price moved in her favor. If the price is not to her liking, she does nothing. Bob gets his Litecoin back, and Alice waits another 12 hours to get her Bitcoin back.
If Alice decides to take the Litecoin, Bob has few choices. He has to take the Bitcoin or leave empty handed.

In the normal case where nobody wants to betray the other party, an atomic swap consists of four transactions:

a hashed timelock contract (HTLC) from party A on chain A.
It contains an if-statement with two paths: One with a check for the hash of the secret and the public key hash of party B and one with the timeout and the public key hash of party A.
another HTLC from party B on chain B. Same structure but the public key hashes are swaped. The locktime is shorter, but the secret is the same.
a claiming transaction from party A on chain B. Party A now wants to claim the transaction value by providing the secret. As party B watches the blockchain, he sees the transaction from A and now also knows the secret.
With the secret he now can claim his part of the trade on chain A.

That's of course a bit of an abstraction, becaus in reallity all of this is further devided into input and output scripts, but for a general understanding I hope, my short explanation is sufficient.
For more deteil (but also more confusion), read https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
So, when you are party A and "give" the secret to party B (by sending your claiming transaction)*, you already have received your part of the trade and don't need to worry about anything anymore.


text:
How many neighbours does a Node have?
I'm writing a blockchain simulator to evaluate the bitcoin network and currently running some evaluation experiments.
I couldn't find a reference for the approximate number of neighbour each Node has in its table.
Can anyone point me to a source?

It is impossible to know how many nodes each node is connected to or has in its peers table. This information is not broadcast publicly and the information that is available publicly (by asking a node) is not representative of what the node actually knows.

do you have a ballpark number?

No, there is no ballpark number that can even be gotten.


text:
How to generate a payment request [BIP70] with specified fees
I am working on an bitcoin payment system that generates invoices, because the invoice is time sensitive we like to control the fees our users pay as much as possible.
Is it possible to create a BIP70 payment request that specifies the fee the payee is expected to pay (either per output to be summed up, or in total for the transaction)? We can do our own validation, this question is just about the creation of the payment request (if the bip70 spec allows for the specifying of fees).

BIP 70 does not allow the merchant to specify the transaction fees to be used.

Thanks Andrew. Would you know of any other protocol (with some wallet support) that would offer this?

No, there are no other protocols.


text:
Geting back transferred Bitcoins when the opposite party denied to accept the transfer
I have sent some bitcoins to Payza Account, but Payza denied the transaction saying that the transfer shall be made through "Add Funds".    Now the Bitcoins are not showing either in my Bitcoins account or Payza Account.
How can I getback those bitcoins into my Bitcoins Account.

If you've sent money to Payza there are just two options: either you figure it out with Payza, or you sue them to have a third party force them to figure it out with you. There is no mechanism for anyone else to get involved provided by Bitcoin.

I think your best bet would be to contact their support and see if they can help.
Bitcoin transactions can't be "cancelled" or "refunded" after they get confirmed. Only the person that owns the address that you sent your BTC to will be able to send you your coins back.


text:
About how the bitcoin network changes the difficulty of mining
As far as I currently know, the difficulty is changed every 2016 blocks.But as for the number 2016, I have a few questions. Does it mean the blocks generated in whole network or just the 2015 blocks generated in the same chain before it?Or, in other words, when difficulty changes, does it only affect one chain(maybe main chain or side chain) or the whole network.

Or, in other words, when difficulty changes, does it only affect one chain(maybe main chain or side chain) or the whole network.

Difficulty adjustments are calculated from the timestamps of the blocks in the chain. Two different chains may have different difficulty adjustments.
However, since the network will eventually agree on the chain tip, it will also agree on the difficulty.