Signing a raw transaction with multiple inputs So I am creating a simple P2PKH transaction and after I researched about this found few useful posts and answers here; I was able to successfully spend a a single P2PKH UTXO but it is really getting complicated when I try to spend transaction with multiple inputs. I have spent a day entirely on this.

All transactions are on Bitcoin Testnet.

Outputs I am redeeming:

  Tx Hash: 9742ed783bfec215ec6484d82dae20fba582229e54c49e06d662a91ead3f6a54
  Index: 0
  scriptPubKey: OP_DUP OP_HASH160 81f52d4061313b6f63549efc03f3df6cb6f0149e OP_EQUALVERIFY OP_CHECKSIG
  Tx Hash: 40dbd3c25073cb7222becead1eb9bb2195cf309cf5b24af559f3391168ec6318
  Index: 0
  scriptPubKey: OP_DUP OP_HASH160 81f52d4061313b6f63549efc03f3df6cb6f0149e OP_EQUALVERIFY OP_CHECKSIG

Now I read an answer from here that suggested if using multiple inputs, one should replace scriptSig for rest of inputs (the ones not being signed) to empty;  And I have tried these variations so far:

1. Replacing scriptSig for inputs with "00"

So only the input (UTXO) that is being signed will have its scriptPubKey, and other input(s) should have "00" in place.

  Serialized input #1 when signed:
  01000000
  02
  546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
  00000000
  19
  76a91481F52D4061313B6F63549EFC03F3DF6CB6F0149E88ac
  ffffffff
  1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
  00000000
  00
  ffffffff
  01
  c0fb390000000000
  19
  76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
  00000000
  01000000

and...

  Serialized input #2 when signed:
  01000000
  02
  546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
  00000000
  00
  ffffffff
  1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
  00000000
  19
  76a914A17C43FE0E1F8E660B044C9538E2CEF4ABFDCED288ac
  ffffffff
  01
  c0fb390000000000
  19
  76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
  00000000
  01000000

main transaction with both inputs signed: (signatures without 01 hash code type suffix and public keys are bold)

  01000000
  02
  546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
  00000000
  6a
  4730440220E4A366646391B3CFB06C0C4B0343E678B560BE8A2D20418233DEE863986105E502207245C5BA3DB516E59B95764C1716F5B39850E20429F08B91389C4780CE45430E0121025F69830D2BA35D04CA9EFB3EA46AA2645BBBDCB592A189A539480657C9696137
  ffffffff
  1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
  00000000
  6a
  4730440220C41C498D0CA55E38FE85DD158FDE82BB451068124E2B3AA2391D861BA9281EDD0220165712ADF71B19DF525583D8F48B82DFF06B2E556C17A583F4D5C54E99412C6B0121039F9AF4A84A8D5C35DD7A5628F8C2DC1894C2B4BDD4815DAFFDCBC9102FE2BA26
  ffffffff
  01
  c0fb390000000000
  19
  76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
  00000000

now decode raw transaction works but when trying to broadcast it, bitcoind gives these errors:

  mandatory-script-verify-flag-failed (Signature must be zero for failed
  CHECK(MULTI)SIG operation) (code 16)

or

  non-mandatory-script-verify-flag (Non-canonical DER signature) (code
  64)

I have tried different variants:

Replace scriptPubKey of inputs that are not being signed with just "00"
Replace scriptPubKey of inputs that are not being signed with just ""
Remove sequence number from inputs "ffffff"

but nothing seems to work. What am I doing wrong? Your help will be appreciated :)

and other input(s) should have "00" in place.

Keep in mind that you replace the "scriptsig" with "empty" and the 0x00 is the size of the empty script.

  non-mandatory-script-verify-flag (Non-canonical DER signature) (code 64)

The problem here is the DER encoding used in your signatures. r values in a signature are positive and since each r value that you have has its most significant bit set they need a preceding 0x00 to tell the DER-decoder that the numbers are positive:

0xE4 = 0b11100100
0xC4 = 0b11000100

Each signature should change to this: 483045022100E4A3...


How safe it is that a single San Francisco company controls the canonical location of Bitcoin code? The single most-trusted canonical source of Bitcoin client is https://github.com/bitcoin/bitcoin

This URL is controlled by a single US company GitHub Inc., headquartered in San Francisco, United States. The US government (nor any other government) is probably not a friend of Bitcoin, and they could theoretically threat the CEOs of GitHub Inc. with an arrest, unless they implement some kind of backdoor into the Bitcoin code, which could be downloaded by a large number of people before it would get noticed.

If and how is the Bitcoin network protected from being poisoned and destroyed this way?

You should learn more about the way the git scm system works. First, it is distributed so that everyone has a complete copy of the entire codebase; second, every commit is checksummed, so that if github wanted to (or was forced to) underhandedly change code, it would be detected by everyone.


How do I send bitcoin to multiple recipients at once? How do I send bitcoin to multiple recipients at once? Like this. Also, I would like to know if the reason I see people do this is for privacy reasons? As when I sell items online they usually send the btc to multiple recipients at once.

You can "send to many" addresses in the same transaction, most of the wallets have options to create a transaction with multiple output addresses.

Also, I would like to know if the reason I see people do this is for privacy reasons?

There can be lot of reasons. Batching is normally done by exchanges and businesses to use bitcoin in a better way and pay less fees. I am not sure if there is any benefit related to privacy in batching except if the outputs are of similar amounts or amounts are hidden in the case of L-BTC(Liquid) confidential transactions.
Batching can save upto 80% fees by David Harding: https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb
Electrum:

Bitcoin Core:


Unspent transaction I need some help I had a business send me BTC to my exodus wallet.  The transaction is confirmed but about half of the transactions including mine say unspent.  It's been 4 days now.  Can I do anything to help the process?

If the transaction is confirmed, the process is done.  "Unspent" just means you haven't spent the coins yet.  But you can do so whenever you wish.


How do blockchains in each nodes maintain consistency? What I understand as (Please correct me if any statement is wrong)

Every full node tries to generate a new block, in which different amount of transactions are included and what to be included will not be identical. This results in unidentical UTXO set and mempool for every full nodes.

If above statement is true, then is it okay to understand as that when the blockchain is replaced(because a new block was introduced by other node, or the blockchain branch I have became stale anymore), then the UTXO set and mempool I maintained is replaced subsequently?

If it is not the case, then how can a node resume mining after the new block is introduced? A UTXO which is known to be unspent beforehand can turn out to be spent after a new block is introduced.

Most of the full nodes are operating on normal CPUs which is now basically ineffective for mining. The mining process is handled by specific mining pools. So for full nodes that basically sees the same blockchain (there might be inconsistencies at the tip if two blocks are mined at the same time), they have the same UTXO set. This is because the UTXO set is built based on the transactions that are included in the blocks. Whenever a block is received by a full node, they delete the UTXOs which were consumed by the inputs in the transactions and add the UTXOs that were created in the output. For a mining node it is similar. If they mined the last block at the same time as the other miner, then the first miner would be building the next block using a different UTXO set than the other miner. However, after one or two blocks when the network converges (they cannot indefinitely generate blocks simultaneously) the network would have the same UTXO set.

For mempool the story is different. Bitcoin transactions are relayed on the network on a best effort basis. So it might be the case that some nodes do not see some transactions until they are finally included in the blocks. So, yes there are inconsistencies in the mempool.

  how can a node resume mining after the new block is introduced?

As mentioned above, if two blocks are mined at the same time then some miners would be working on a different version versus others. The accepted principle is to build on the block that was received first. However, this is not always the case. So when a mining node who is still calculating the header hashes notice that a new block is mined, they realize that they have lost the 'race' for that particular block height and try to mine on the block that was most recently received.


How can I make my own pool? Me and my friends want to make public pool like rublik.com (site have english vesrion).
So, how can we make a similar pool? Maybe there are some open source solutions like p2pool? We want to make a similar pool, maybe someone knows what solutions rublik.com use? We just want to copy their pool.

Running a public pool comes with the obligation to understand the underlying asset.

Rublik seems to have own proprietary software.

To run a public pool you at least need the following:

Knowledge of linux system administration/security.
A dedicated server.
A coder to write/edit a frontend, reward structure and payout process.
Of course the pool software.

Expect if you run a puplic pool to deal with system exploitation and Ddos.

There is opensource pool software available. However, most are outdated, open exploits or other issues. Either code your own, improve existing software or do DD on maintained software (eloipool by luke-jr --> IRC freenode #eligius for example is maintained).

Just a hint:
https://www.google.com/search?q=bitcoin+pool+software&ie=UTF-8&sa=Search&channel=fe&client=browser-ubuntu&hl=en

There are opensource frontends too but those available last i checked are no out of the box solutions.

Even if you get that far you will face the task to create a reward structure with automatic payout process.

To underline that again: 90% of available opensource software needs workovers, some aren’t maintained for over a year, you hardly will find outofthebox solutions for free.


Multisig scripts hashing (p2sh): difference between legacy and segwit Some time ago I noticed that, given the same inputs, addmultisigaddress and createmultisig Bitcoin core's methods were generating different p2sh (addresses).

I asked around and a user from the bitcoin dev list told me that this was because:

  "addmultisigaddress uses the default address type of the wallet, which
  is p2sh-segwit and createmultisig uses a default address type of
  legacy"

An example of this behaviour is:

bitcoin-cli addmultisigaddress 1 '["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
{
  "address": "36ULucjWUTrDvaJzCyhFoVbDoNS6Zum2Du",
  "redeemScript": "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
}

bitcoin-cli createmultisig 1 '["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
{
  "address": "3GiimyxF1R5VixfBFAbQZbuy9EesD2r6n1",
  "redeemScript": "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
}

The point is that, later, I noticed that with certain public keys the two methods generate the same hash:

bitcoin-cli addmultisigaddress 1 '["03fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d7617631146","02ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd101","04633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac204"]'
{
  "address": "32AVnYUUSvm4bGgEXoQ2zuFAJBPH4P31Gi",
  "redeemScript": "512103fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d76176311462102ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd1014104633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac20453ae"
}

bitcoin-cli createmultisig 1 '["03fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d7617631146","02ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd101","04633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac204"]'
{
  "address": "32AVnYUUSvm4bGgEXoQ2zuFAJBPH4P31Gi",
  "redeemScript": "512103fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d76176311462102ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd1014104633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac20453ae"
}

I don't get how this can be possible if the inputs and the redeem scripts are the same.

What's the difference between the two cases and in general between a legacy multisig transaction and a segwit one?

Reading raw transactions data from the blockchain, how is possible to know whether a script needs to be hashed using legacy or segwit?

I believe the behavior you are seeing is actually a bug.

By default, addmultisigaddress uses p2sh-segwit which is the default address type for the wallet. By default createmultisig uses legacy. These are two different address types, and normally, you get two different addresses.

However segwit does not allow uncompressed public keys. So when the redeemScript is being created, if an uncompressed public key is detected, both RPCs will return legacy addresses. This is why you see the same address in the second example.

But I believe there is a bug. Your first example should also give the same legacy addresses, but it does not. I think that this is because the uncompressed pubkey is not part of the wallet, so it does not correctly detect that it is an uncompressed pubkey. Thus addmultisigaddress follows its default to give you the p2sh-segwit address and createmultisig follows its default to give you the legacy address.

  Reading raw transactions data from the blockchain, how is possible to know whether a script needs to be hashed using legacy or segwit?

For p2sh-segwit, the redeemScript is not actually the redeemScript you get from the RPCs. Rather it is the script for a P2WSH output. The "redeemScript" is actually the witnessScript for the P2WSH script that is the actual redeemScript. The script type (either in the scriptPubKey or in the redeemScript) determine whether that output is segwit or not.


Who is in the Bitcoin Business Alliance? I have stumbled upon the Bitcoin Business Alliance, and heard it includes some of the most influential people in the Bitcoin space.

What businesses or individuals are known to be a part of the BBA?

Well, I won't speak about other people, just that I am now a part of BBA myself.


WIF Format and Storing Private Keys I'm writing an Android app which will be storing private keys for Bitcoin and a few Altcoins in an SQLite database. To store my private keys, I was initially using the WIF. When I take them out of the database, however, I just Base58 decode them back into the 32 byte private key. Is there any real advantage to using the Base58 format for storing the keys in WIF vs basic hex encoding (0x12 to "12")? I know the WIF is useful for human transposition, but I'm specifically wondering about storage here.

So far, what I've come up with is that the Base58 format:

 Takes slightly less space
 Tells me what coin type the address is used for
 Has error checking
 Tells whether the private key is used for a compressed or decompressed address.

Items 2-4, however, are things that I could get from other entries in my SQLite database, so they're not critical. How does the Bitcoin-QT client store its private keys? I know when it dumps them to the user it gives them in WIF, but I'm wondering what it does internally to save keys on the machine and if I should do it the same way.

The Bitcoin Core client stores private keys typically  in DER encoded format, at 279 bytes per key, for compatibility with older versions. There is no good reason for that though. For encrypted wallets, which are more modern, keys are stored using just the (encrypted) 32 byte secret plus the full public key. Compression is derived from the length of the corresponding public key, so it doesn't need to be stored separately.


Where is my bitcoin balance stored in the blockchain? This is possibly a duplicate but, since I am a Bitcoin dummy I cannot find it.

Anyhow; as I understand (and I will make some assumptions here), a block in the blockchain contains one or more transactions.

Transactions are typically bits of information which contains delta's, I mean e.g.: Alice transfers 2 bitcoins to Bert.

So, to determine or verify my bitcoin balance (in order to make a valid transaction), does the whole chain needs to be analysed? If so, is this optimized in any way?

Or am I completely off track here?

The blockchain defines your balance, but it doesn't have a specific field in which your balance is stored.

Yes, it needs to be analyzed to find your balance. However, it doesn't have to be analyzed all over again, just to check for the balance of a new address. Instead, checking the UTXO set (which only has to be created once and then to be updated every time new blocks are received) is sufficient. Furthermore, not the entire UTXO set has to be traversed. There are things like hash maps which make this a lot easier.


How come the bitcoin blockchain is only 285gb only? I found some statistics that the bitcoin blockchain is 285gb.
https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/
Bitcoin has been around for how long? 10 years?
with 1mb blocks every 10 mins.
6mb an hour * 24 = 144mb a day * 365 = 52,5 gb a year * 10 = 520gb
How come it's significantly smaller?
Are my calculations wrong?

Any factor limiting the size of a block is a maximum, there’s no minimum requirement.


Can you verify partial blockchain information from a third party, without yourself having an entire blockchain? I'm considering consuming, or if unavailable, I'm considering providing, a bitcoin blockchain querying service along the lines of json rpc.
Would it be possible for me as a consumer of such as service, to verify the integrity of returned data from such queries, without myself running a full node? (If not there wouldn't be much point using such a service!)
Would it be possible for me as a provider of such a service, to provide enough data for a consumer to verify the validity of the data I send them, when the consumer is not running a full node? (If not there wouldn't be much point providing such a service!)
My end goal is to run something like a bitcoin blockchain explorer website on the cloud, but the cost of running a full node (particularly storage) on the cloud is more than I can afford. Obviously I have some feature ideas I've not yet seen on other explorers

You could use the Simple Payment Verification, or SPV, protocol.
In a nutshell, this works by synchronizing only the block headers for the longest chain. Once the chain is established, individual transactions are proven by using merkle paths leading up to the merkle root in the previously synced block headers.
Note that this only allows for proof that the supplied data exists in the chain - it does not allow the user to verify that you have provided them with all data - it is possible for operators on SPV systems to Lie by omission and simply claim a transaction or block doesn't exist.
Consumer wallets usually get around that by querying multiple such nodes - if at least one node is honest, the wallet is able to detect the lie.


How should I handle cases like this where the documentation for Bitcoin Core states one thing, and the actual program does something else? Bitcoin Core's RPC API call "getnewaddress" is documented here: https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/getnewaddress/

It claims:

  Result: "address"    (string) The new bitcoin address

In other words, it is supposed to return an associative array containing only the element 'address' which is a string representing the new Bitcoin receive address.

However, it actually returns just an "untitled" string without an array/object. It's just a plain string immediately outputted, not wrapped in any array/object/container. Perhaps this is what they mean by "(string)", but it sure looks to me that the "address" part makes it an associative array with one element. This appears to be the case elsewhere in the API:

The "sendtoaddress" call does return an associative array with just a "txid" element, and it's documented just like "getnewaddress": https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/sendtoaddress/

  Result: "txid"                  (string) The transaction id.

(Or all my previous work was in vain and I have actually got that wrong. I cannot easily try sending Bitcoin.)

Should I assume that they won't change the behaviour of the program, but rather the documentation? Or will they really change the program to reflect the documentation? If they ever do, my code breaks since it expects the returned value to be a string and not an array with one element called 'address'.

This kind of thing gives me a great deal of stress, especially as money is involved and the slightest mistake could cause huge losses or (at best) a ton of nightmarish manual work to attempt to "restore the state" after something is messed up halfways.

Note: I cannot report bugs to their GitHub page because MS GitHub doesn't let me register an account. I gave up on even trying.

In the example RPC results, it will show whether the result is a JSON array by including brackets [] or it will show if it is a JSON object (associative array) by using curly brackets {}. If the result does not come with any JSON encoding and is a single string or other data type, then you will not see that in the example.

You can see an example of a result that comes in the form of a JSON array by using listlockunspent:

Result:
[
  {
    "txid" : "transactionid",     (string) The transaction id locked
    "vout" : n                      (numeric) The vout value
  }
  ,...
]

An example of a JSON object using createwallet:

Result:
{
  "name" :    <wallet_name>,        (string) The wallet name if created successfully. If the wallet was created using a full path, the wallet_name will be the full path.
  "warning" : <warning>,            (string) Warning message if wallet was not loaded cleanly.
}

An example of a return value that is not JSON encoded using getbalance:

Result:
amount              (numeric) The total amount in BTC received for this wallet.

I believe you may be mistaken with the assumption that sendtoaddress return a JSON object. The code clearly shows that the result is not JSON encoded:

return tx->GetHash().GetHex();

That is a transaction object, which retrieves the transaction hash (256 bit opaque blob), which is then converted to a string using the GetHex() method.

The code would use UniValue if it were to encode JSON. For example in the code of createwallet:

UniValue obj(UniValue::VOBJ);
obj.pushKV("name", wallet->GetName());
obj.pushKV("warning", warning);

return obj;


Is it possible to convert an address from p2pkh to p2sh? Is it possible to convert a p2pkh address to a p2sh address?

Also, will the balance of the p2pkh address carry over to the p2sh address?

Is it possible to covert a p2pkh adrress to a p2sh adress?

Don't.

Addresses are determined by the wallet. It's the receiver's wallet saying "I will accept payment when it arrives at address X". Sending it to another address may mean the wallet doesn't recognize it. Worst case, if the receiver has some hardware security module that stores the key, it may literally be impossible to even recover the funds when sent to the wrong address.

This is no different from owing a friend some money, and "repaying" them by burying an envelope with cash in their lawn. You may technically consider that a transfer of funds to them, but if it's not done in a matter known or even recognizable by them, it's very hard to consider it a payment.

As a sender, you shouldn't care about what type of address the receiver gives you, and certainly not try to guess how you can modify it.

As a receiver, if you want to give out a P2SH address (presumably because you want multisig security or segwit?), just upgrade your wallet to software that supports said feature and create a new address.

  Also will the balance of the p2pkh address carry over to p2sh address?

No, addresses don't have balances.


Can I gift Bitcoin to young family? Many years ago I looked into gifting 1BTC to each of my God sons, who had just been born. That gift would be worth a fair bit today, but I didn't do it because I couldn't figure it out.
How could I do this today? Remember, the recipient is 0 years old and can't upload their passport :)

Gifting Bitcoin to novice users is difficult. First, your gift is tied to an obligation. In order to make use of it, they need to invest time to understand it and how to access it. This causes such gifts often to not properly connect. Secondly, the Bitcoin gift is often forgotten about because the recipient doesn't have an immediate use for it. Often Bitcoin gifts are somewhat impersonal (e.g. a paperwallet similar to a gift voucher), so they tend to get displaced. Optimally, the gift is personal and unique enough to be kept track of as well as hardy enough to survive until the recipients interest is piqued.
This brings us to another issue. The instructions how to use the Bitcoin gift must be sufficiently accessible and longlasting that a novice users can follow them now or in two decades. And they must be stored with the gift! On the other hand, it should be safe against being stolen through casual observation, like e.g. cleaning helpers. Even using some service is hit-and-miss: the space is only 11 years old, nobody knows which services will still be around in 12–16 years when your god sons get interested?
I surmise that you might have the best chances of success by investing significant effort to make your gift very personal (ensuring that it is treasured) and find a way to integrate instructions with the gift so they don't get separated.
You will want to keep a backup in case it does get lost.


What is the significance of the version byte in front of RIPEMD-160 hash? Public Address is generated from the private key following some steps. Please refer Bitcoin wiki to see the process.

The version byte is used to differentiate between MainNet and TestNet addresses as well as between P2PKH and P2SH addresses.


The logic of exchange services of bitcoin As we know,it takes at least 10mins to transfer bitcoin to other accounts.therefore I guess they actually don't transfer any bitcoins except when their users try sending to others they want.

So do you think what I guess is right?

Transfer of a transaction is immedeate. You can send from one address to the next, and it appears within seconds. However: it is not confirmed (in a block). It takes in average 10 mins, that a new, valid block is created. The block is made of many transactions, that were validated before by the node. There is a mathematical puzzle to be solved, which is adjusted from time to time, so that the "block time" is always equivalent to 10min in average. You can send your tx anytime you want, it just might take some minutes, until it appears in a valid block.
I ercommend reading some more, maybe the online available book of Andreas ("Mastering Bitcoin"). It explains pretty well the details.


What is a relationship with total hash rate(hash power) and average block generation time? This chart - hash rate means total hash rate of All minor?

I think the most significant factor for difficulty and block generation time is the hash rate of the biggest mining pool not total hash rate of all of minors.

I want to assure it that if there is a mining pool have 30% of total hash rate and this mining pool is the biggest pool.

Then this mining pool will succeed to find target hash value faster than others(stochastically).

Therefore, I think difficulty for block generation time will be set by this mining pool.

As a result, if other mining pools don't have a enough hash rate for example,  10% of total hash rate, then stochastically, it will takes 3 time more to find a traget value.

So i think the most significient factor is hash rate of the biggest mining pool

Am i thinking well?

And it seems like out of title, but i have one more question.

If fork is happened, Mining pool can recognize fork is happened?

This chart - hash rate means total hash rate of All minor?

No, it represents the hash rate of the network. It is determined by using the time it took to find the block and the current difficulty of the Bitcoin blockchain. To cite an example, the current difficulty bits are 0x1729fb45, which means we need to find a block header hash that is less than '0x00000000000000000029fb450000000000000000000000000000000000000000. This represents a one in 2.88e+22 chance of finding the header hash. Assuming block time of 10 min, this is 2.88e+22/600 = 47e+18 hashes/sec. If the block are found faster than 10 minutes the hash rate is higher, if it is found in more than 10 minutes, the hash rate is lower. That is what you see in the hash rate graph.

  I want to assure it that if there is a mining pool have 30% of total hash rate and this mining pool is the biggest pool. Then this mining pool will succeed to find target hash value faster than others(stochastically).

No. Your big mining pool will only have a 30% influence over the difficulty adjustment. The rest of the network will have a 70% influence, which is more than what a solo miner has. The block time adjustement is based on how fast the blocks are mined (the algo tends to keep the average time at 10 min) not how much percent hash power each miner has.

  Can a miner find if fork happened?

If miner receives two different blocks at the same height then he will know that the network has forked as half of the network will be seeing a different tip versus others. When the next block will be mined, on top of either of them, the network will converge again.


Trying to reconcile the amount sent versus amount transacted Newbie here trying to understand how an amount sent from coinbase gets put onto the block at a different value.

In this transaction, I sent 0.55076816 LTC to a wallet.

There’s a network fee of 0.00100816 which means I receive 0.54976.

But what I don’t understand is the figure 0.57441138 on the right hand BlockCypher screen.

Where did the extra 0.02364322 LTC (0.57441138-0.55076816) come from that I didn't send from Coinbase???

Say I owe you $8, but all I have is a $10 bill. I'll make a transaction that spends my $10 bill and delivers $8 to you and returns $2 to me. The extra 0.02364322 LTC is Coinbase's change, just as the extra $2 is my change.

Coinbase didn't happen to have precisely 0.55177632 LTC in an unspent transaction output, they had 0.5734121 LTC. So they returned some change to themselves.


How can I solo mine using Bitcoin Core? I want to mine Bitcoin using the Bitcoin Core client.

I have followed the steps on https://www.youtube.com/watch?v=Xd4Opw0Upok, but when I type "setgenerate true" in the console, it replies with "Method not found (code -32601)"

How can I mine Bitcoin with Bitcoin Core?

You cannot.  The mining functionality was removed in version 0.13.0 since it was hopelessly inefficient.  See Since which version the mining functionality removed from wallet?

It is not practical to mine Bitcoin without recent specialized ASIC hardware.  See In the ASIC-age, is it worth starting mining Bitcoin at home?


Understanding Bitcoin prices I followed the prices of Bitcoins during this day, but I am actually very cofused as to why Preev reports it always about $70-$100 less than Bitcoinity. News websites say the price soared to $900 today, which fits Bitcoinity's chart, but I also see people on the BitcoinTalk forums saying it is $500 now, which fits Preev's.

I understand Bitcoinity says that "the big number here is the price at which last trade was made". But since I also understand there is no institution that decides an "exchange rate" for Bitcoins, could I assume it as the price of the last trades? Why such a big difference?

EDIT: Now Preev is reporting more, but it is still a big difference compared to Bitcoinity. Just as a reference, when I wrote this question, Preev was reporting about $510, whereas Bitcoinity $600.

Different exchanges will offer different rates at the same time because of variations in trading volume, markets, etc. This happens in real currency markets, as well. With enough money it is even possible to play the currency market, "buying" dollars with Euros, then buying yen with dollars, then buying euros with yen, and coming out ahead.


Is it possible to restrict Bitcoin's network traffic? Bitcoin is just a software running on a computer communicating securely with peers on the internet.
What will it take purely in technical terms to ban Bitcoin nodes from communicating with the network?

Assuming a node is starting for the first time, I believe it uses DNS seeds to find peers. If those DNS seeds are blocked, is it possible to prevent bitcoin node discovery ?
Is it possible to block certain ports to avoid bitcoin communication ?
Any other ways ISPs can detect bitcoin traffic ?

Banning peer to peer networks is very difficult in general.

Assuming a node is starting for the first time, I believe it uses DNS seeds to find peers. If those DNS seeds are blocked, is it possible to prevent bitcoin node discovery ?

This is possible but all you need in order to bypass it is one IP address of one peer and then you can connect to it manually and join the network

Is it possible to block certain ports to avoid bitcoin communication ?

Again that's possible but easily circumvented by changing the default ports

Any other ways ISPs can detect bitcoin traffic ?

Peer traffic is not encrypted so ISPs can flag bitcoin traffic by performing some inspection on the data being sent. But again this is bypassed by using a VPN or TOR.
Another way someone might try to stop you is blocking your internet access completely but this can be circumvented too because bitcoin is accessible via satellite, all you need is a dish and you don't rely on your ISP any more.


Can a bitcoin transaction be used to send usernames? I'm looking to implement a secure mobile messaging service and looking for a payment system that will allow users to buy message credits and have them be allocated to a specific account however I want to keep user data to a minimum (currently I'm planning for no more than a public key, user name (five random characters), account balance and optionally an e-mail address (in case the user loses their phone).

My questron is can I send the five character username with bitcoin transactions?

I'm not sure how you would make vanity addresses work for this. You don't want to store an address for each user, and if you did you wouldn't need vanity addresses. If you force the user to create a vanity address, I don't see what they would do with it that would help you. It seems kind of bizarre to force them to transfer the coins to their own vanity address and then transfer them to you, so you can see the vanity address as the source.

One possibility is to publish a simple algorithm to convert their user name to a Bitcoin address (that nobody could claim). Then have them use the sendmany API call to send the payment to you and a satoshi to their user name's corresponding Bitcoin address. You would receive the funds and then know what user to credit them to by decoding the address that had received a satoshi. This would waste one satoshi for each transfer.

There are really only two issues with this. First, it's a bit of a pain for your users. They can't use the GUI to send the funds since it doesn't support sendmany. Second, the users have to be careful not to send the actual funds to the Bitcoin address corresponding to their user name. If they did, those coins would be lost forever. They need to understand that they should only send a tiny fraction of a Bitcoin to that address so as to 'mark' the transaction.

All in all, I think all the possible solutions are ugly and you should rethink the decisions that led you to these unusual requirements.


Data for time a transaction spent in a pool before it got added to a block Is it possible to collect data for when an transaction was added to the pool to when it was added to the block?

Kind of.

There is no "the pool" or "the mempool" (which is what I assume you are talking about when you say "the pool"). Rather each node maintains its own mempool which may be different from another node's mempool. Because each node receives a given transaction at different times, the amount of time a transaction spends in the mempool will also vary from node to node.

However, you can still run a node and track how long a transaction spends in its mempool before being included in a block. In fact, Bitcoin Core already does this in order to do fee estimation, although the raw data is not exposed to users.


How to calculate the Public key P2SH from hexadecimal script? My study on the scripts goes next.

I'm creating a ScriptPubKey decompiler, now I have a problem with the P2SH,

So how is calculate the key p2sh?

I using this code but I not think is correct

 string scriptHash = hex.substr(4, hex.length() - 6);

 Bytes bytes = hexBytes(scriptHash.c_str());

 char address[36];
 Base58Check::pubkeyHashToBase58Check(bytes.data(), 0x00, address);

 string stringAddr(address);

 cout << "P2SH addresss is " << address;

I have looked this code inside the class DestinationEncoder of the bitcoin core

 std::string operator()(const CKeyID& id) const
    {
        std::vector<unsigned char> data = m_params.Base58Prefix(CChainParams::PUBKEY_ADDRESS);
        data.insert(data.end(), id.begin(), id.end());
        return EncodeBase58Check(data);
    }

and with this code it seems that the information is queued to something, can you clarify my ideas?

This is specified in BIP 13: https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki

You compute the Base58Check encoding of the P2SH version byte (5 for mainnet, 196 for testnet) followed by the 20-byte Hash160 of the script.

The code you're quoting is for P2PKH addresses, not P2SH.


Are HD wallets private keys any different than regular private keys Aside from the fact that HD wallets derive them deterministically, is it correct to state that keys driven at any path or index under BIP32 isn't any different from a private key that's derived randomly in a non-HD wallet?

In other words, its theoretically possible for someone to derive a private key that's at a particular node under your master key in HD wallets, irrespective of how small the probability is, and actually the same probability that there is for generating a private key (non-deterministically) that's already in use by someone else?

Essentially, private key being just a number in a specific range, you can either guess it randomly every single time or have a mechanism of generating random numbers, it essentially means the same thing and is possible to arrive at the same number from either of the ways.

Correct?

Bitcoin uses ECDSA for signing and verifying. That is, G is a curve parameter (known constant), k is a number, then the public key is kG, etc. The same mechanism is used in different script types too: Multisig scripts and other P2SH scripts. However, note that it is easier to brute-force a P2SH multisig scripts, which is why the Bech32 format P2SH scripts have longer hashes. Similarly, P2SH scripts might not use signature validation at all.

An HD private key can be encoded in the WIF private key format, and any wallet supporting importing private keys would be able to spend its outputs. This doesn't hold true for other address types.


How can I verify a signed message? I can send a signed message using the standard client, but if I see a signed message in, say, a forum, how can I verify it?

I understand this hasn't yet been implemented in the GUI for the standard client.

According to this bitcointalk thread, it can be done via the JSON-RPC API:
Code:

verifymessage [address] [signature] [message]

This feature has also been included in the GUI of the Armory client:

  To Verify a Signature Block with Armory (works fine in offline mode):

Open Armory, go to the menu, "Tools"-->"Message Signing"
Click on "Import Signature Block" at the bottom of the screen.
Paste the signature block, and click "Okay"
Address will be checked against public key, public key checked against signature for the given message

  None of this requires the blockchain, so if you are on a system that
  couldn't normally run Armory, you only need to run with the
  "--noblockchain" option.  This allows you to verify Armory signature
  blocks without even having an Armory wallet!  If you're intrigued, try
  this one:  (get Armory if necessary)


Bitcoin values change in each exchange Well, I am starting now with bitcoin in Brazil (realizing my country is a non-concern in terms of the answer), I noted that final value change depends on exchange used.

So, if I buy a bitcoin in MERCADOBITCOIN (Exchange 1) for R$ 2383,00, I can sell this in FOXBIX (Exchange 2) for R$ 2500,00 in same minute. Is this difference in value normal ? Why does bitcoin have different values across different exchanges?

This is perfectly normal and a sign that the decentralized value system is working just fine. The valuation is different across exchanges because the value of Bitcoin on exactly one exchange is determined by the active trading on said exchange.

It just depends on supply/demand on each exchange. It is recommended to have a multi-exchange approach with an offline wallet holding the majority of your funds.


How could we determine that a particular transaction in which block's Merkle tree? https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ :

If the light client wants to determine the status of a transaction, it
can simply ask for a Merkle proof showing that a particular
transaction is in one of the Merkle trees whose root is in a block
header for the main chain.

Please note that image is taken from reference 1.

Verification of a Merkle path proceed from the leaf node to the Merkle
root.

As seen from the example image, we actually could not know that transaction-3 is located under that specific block and leaf-node since a light client only downloads the merkle root.
[Q] How could we determine that a particular transaction in which block's Merkle tree and Merkle tree's which leaf node? In order to determine the status of that transaction should we iterate through all blocks in the blockchain until we find the specific transaction? And when we find its block number, how could be actually determine its leaf node.
Thank you for your valuable time and help.
(1) https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/

As seen from the example image, we actually could not know that transaction-3 is located under that specific block and leaf-node since a light client only downloads the merkle root

As a light client, you would be given the branch/path of the tree which corresponds to the transaction you wish to know about, not just the merkle root. By giving you the transaction itself, and the branch of the tree, it lets you verify that the transaction was indeed part of that merkle root. Otherwise there is no way to tell, it is not possible to extra transaction IDs from a merkle root without being given the tree of transactions themselves. A merkle root is just a hash, a 'summary' and commitment to the transactions, it doesn't actually contain any information.


Transaction Output Order Suppose I generate a transaction with 5 outputs.
Is there a deterministic way to know how the outputs will be ordered on chain (their .n values) or will they simply appear in the order in which I arranged them when created my rawTxn that I signed?

If you create a raw transaction yourself, then that is the raw transaction. Whatever you put in it is exactly what the transaction will be, in the same order.
There are some conventions around output ordering. Some software will randomly permute the outputs; other software uses BIP69 which specifies a deterministic ordering. There is however no requirement to follow either rule.


Can I add Bitcoins by address? I signed up for bitcoin ages ago, but never used it; I forget who I signed up with I have had to reinstall the OS (Win 10) on my computer and lost the program I used. I do still have a copy of the address though. How do I add the address to MultiBit?

Edit: I apologize I was for some reason still thinking MultiBit classic, if you are using HD there is a possiblity you created seed words which you would be able to restore from.

Information is per: https://multibit.org/try-multibit-hd.html

Classic:
You're going to need the backup wallet or private keys that were automatically created for you by MultiBit. By default they would have been located in a sub-directory of the folder your original MultiBit wallet was created in.

This information is per: https://multibit.org/en/help/v0.5/help_walletBackups.html

If you do not have any of these files/private keys you are out of luck with regards to recovering the funds. The wallet address alone will only allow you to view the funds, there is no way to recover funds with a bitcoin address alone.


Is the block timestamp reliable enough to timestamp the hash of a document? In using the blockchain to timestamp the hash of a document, so to prove that it existed before a certain time.

Is it reliable? Do you think it can stand on court? (IANAL and probably you neither) What is the worst that can happen? For example, What if many nodes change their internal clocks to hack the median of the time.

A hard fork, which is essentially a blockchain split, would result in the current blockchain to be declared as deprecated and worst of all; not verifiable in the future by the new/upgraded software which will abide by different rules and will not be able to accept pre-fork blocks and their transactions as valid, so if the above scenario would come in life then you would need to legally prove that some contract existed a few years ago in a blockchain that is now deprecated and off-line, whose value would not be much different than this of digitally signed plain-old text document. As a consequence, to prove that smart contract which was associated with a certain tx in the old-chain was signed before a certain time would be even more difficult.

It's also important the precision of time you're after. If a few seconds or even few minutes could invalidate your claim then this will not work for you as geographically distant nodes will receive blocks at different micro-times, as it happens with all large-scale p2p networks.


Is original bitcoin program needed with multibit? I have only MultiBit installed. Is this enough, or do I have to install the original bitcoin program to download the blockchain?

You don't need the original Bitcoin QT progam installed to use MultiBit.


What are the consequences from the leak of xpub and child private key? Let's say the following keys are leaked:

Extended public key derived from path 44'/60'/4'
Leaked child private key from path 44'/60'/4'/0

Does that imply all the child private keys of the root 44'/60'/4' can be computed? Looking and reading at the BIP32 and BIP44 - that doesn't seem to be the case. But wanted to confirm.

Also, if we know that it doesn't cause the sibling keys to be derived, then can I go and safely use the following public key of path 44'/60'/4'/1 without any worries?

If the above two keys are leaked, then your master private key at the account level (m/44'/60'/4') can be back-calculated. That means, any private key (both receiving and change) that you derive from that account is compromised.

To elaborate, BIP 44 uses non-hardened derivation to derive private keys after the account level. The child private key derivation equation is kchild = kpar + hash(Kpar, cpar, i). Here k represents private key, K represents public key, c is chain code and i is the index. Now, since your xpub at m/44'/60'/4' is leaked, the attacker has Kpar (first 256 bits of xpub) and chain code, c (latter 256 bits of the xpub). Since your child private key (m/44'/60'/4'/0) is also leaked, that means the attacker has kchild. Using the above equation the attacker can simply back-calculate kpar. Even if he doesn't know the index number (0 in your case), the attacker can simply run an iteration (just a space of 231 to exhaust).

Since your parent private key at the account level is compromised, you cannot use any addresses derived from the m/44'/60'/4' account unless you want to lose your bitcoins. However, you can safely use m/44'/60'/5' or other accounts.


Blockchain receive payments API Network propagation I'm using the Blockchain API to generate an address to receive payments. I received a payment to a generated address, then Blockchain sends the received amount to the address I defined but that transaction is never confirmed and has Very Poor network propagation 1% - 7 Nodes.

There is no problem if I'm using Blockchain to manage my wallet but my bitcoin client running on my machine never sees that transaction so my blockchain wallet has 0.86964083 Bitcoins and my local wallet (with the same priv keys) has 0.84787744 Bitcoins due to the poor propagation.

What can I do to propagate the transaction to my bitcoin client?

This is a shot in the dark, but perhaps you could get the raw transaction from Blockchain from http://blockchain.info/rawtx/$tx_hash and send it from your client with sendrawtransaction.


Why isn't my transaction going through? I'm using kryptokit to send my funds. I sent a transaction at about 10pm last night and here it is 10+ hrs later still unconfirmed. Is there a way to cancel it that's easy?

Your transaction is non-standard because one output is only 379 satoshi, and therefore below the dust threshold of 546 satoshi. Most nodes don't relay non-standard transactions, and most mining pools do not include them in blocks.

You might want to consider recreating the transaction and folding this sixth of a dollar cent into the transaction fee instead. In the essence, you'd create a doublespend spending the same inputs but redeclaring the outputs. Unfortunately, I'm not sure how you would be doing that with kryptokit.

The easiest would probably be to import the originating address to another wallet and send a new transaction with that.


How do pools get the needed transaction information? How do the mining pools obtain the transaction information required to create a new block? Do they communicate with the network directly, or perhaps through a Bitcoin client, like bitcoind?

The Bitcoin client tracks transactions that can validly be included in a block. Mining pool controllers issue a getwork command to the client to get work units to give to their miners. The client includes as many valid, normal transactions as will fit in the block, preferring transactions with higher fees and priorities and ignoring transactions that are non-standard or look spammy and have too low a fee.


Transaction with 0.0002 BTC fee but not confirmed sice 2 days I'm a Bitcoin noob.
This is my second Bitcoin transaction and I'm getting very nervous.

My wallet (KryptoKit on Chrome) doesn't have a possibility to change the fees or anything on transactions.

Could anyone say what happens to my transaction (~100 USD) if no miner confirms it for some reason?
Now the transaction is unconfirmed since 48+ hours.

Here you can see the transaction:
https://blockchain.info/tx/2362971d010c0d38e51019139a4ebee899d0861af3d5288fae6494bad5ecd3d2

Many thanks in advance

Edit:

This is a very weird situation. At the same moment I posted this question, the related transaction were cancelled and I got my BTC back.

Here you can see the note of blockchain.info:
"Transaction rejected by our node. Reason: Transaction was previously accepted but has been pruned from our database."

The transaction were automatically resented, here is the id:
https://blockchain.info/tx/2362971d010c0d38e51019139a4ebee899d0861af3d5288fae6494bad5ecd3d2

this tx has "dust" output of 300 satoshi. miner nodes treat such transactions as non-standard and do not confirm them

  Could anyone say what happens to my transaction (~100 USD) if no miner
  confirms it for some reason?

nothing happens to your transaction


How can I test if a bitcoin address is compressed or not? I have two bitcoin addresses:

1D8VSXHFAWNhAbruwUMbNp4hsXAnRNkYvX
12T15tvMGaymMX97X9KxVzyLF323r8v6Hg

One is compressed, one is not.

How can I test which is which? (Preferably using python 2.7)

Thanks in advance :)

You cannot determine (from only a base58check address) if the corresponding public key is compressed.

A "normal" pay-to-public-key-hash (P2PKH) is a cryptographic hash of either a compressed or an uncompressed public key. Because hashes cannot be feasibly reversed, you cannot tell if the public key, before being hashed, was compressed or uncompressed.

More specifically, a public key in Bitcoin is a pair integers (x,y). For uncompressed public keys, these integers are encoded as 256-bit unsigned big-endian ints, concatenated together, and then prepended with a single 0x04 byte. The result is 65 bytes long.

For compressed public keys, only the x coordinate is encoded (like above, as 256-bit unsigned big-endian int). It turns out that the y coordinate can only be one of two values, one even and one odd. Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte is prepended depending on y's value (0x02 for even, 0x03 for odd). The result is 33 bytes long.

Finally, these bytes (from one of the two paragraphs above) go through the address conversion process described here in the bitcoin.org Developer Guide, which includes taking an irreversible cryptographic hash (actually, two hashes).

Note that in order to redeem a UTXO associated with a P2PKH address, the redeemer must create a transaction which includes the unhashed public key, either compressed or uncompressed. If such a tx exists in the blockchain, it can be connected to its "normal" base58check address. This is one of the reasons why address reuse is discouraged: once you redeem a UTXO, you "reveal" your public key, which is slightly more sensitive than your bitcoin address.


Probabilty of a Race Attack in time t with hashing power q I read the original Satoshi's paper on bitcoin as well as Rosenfeld's paper on "Analysis of hashrate-based double-spending". However, they don't answer my question, which is as follows.

Let's assume attacker has q hash power (less or more than 50%) and that the merchant is waiting k confirmations (e.g. 6). What is the probability that after time t (e.g. 12 hours), the attacker will produce longer chain in order to double-spend money?

I have seen formulas to calculate the probability, that the attacker will eventually produce the chain, but what I am looking for is, what happens if the attacker is constrainted by time t. I know that the attacker has 100% chance on eventually getting the longer chain, but I also know that when the hashing power q is around 50%, it would take a lot of time and you would normally need around 60-70% of hashing power.

So there are two ways to launch this attack.

(stupid way) get 6 confirmations on a transaction, the go back to the block before the transaction and mine 6 blocks in a private chain before catching up to the mainline and eventually beating it. I would describe this as a race between main chain and private chain where the main chain has a 6-block lead.
(smart way) immediately after the transaction is in the mempool of the main chain, start a private chain with the double spend tx and keep the chain private until there are 6 confirmations on the main chain and release the longer chain into the world to win. I would describe this as a race between the main chain and private chain where they start from the same place.

I think you're talking about doing (1) where (2) is the more likely to succeed attack. With (1), yes, this will take a long time since you have 6 more blocks to catch up. With (2), you're likely to beat (1) soon after however many confirmations. Since the length of the chain is determined by how much proof-of-work is in it, you might be able to win with a shorter chain (!). In any case, calculating the probability of doing so by time T is an interesting problem for (2) but it's at or above your percentage of the hashing power at any length as long as the second method of attack is used.


Receiving payment on Lightning Network with LNBig as initial funder? I was able to open a channel to myself from LNBig and withdrew 100 sats from Reddit's lntipbot. This appeared to be successful!

Output of lncli channelbalance:

{
    "balance": "100",
    "pending_open_balance": "0"
}

However, when I attempt to re-deposit 10 sats back to lntipbot, I get this error:

[lncli] insufficient local balance

I was hoping I could do this without doing an on chain transaction myself, hoping LNBig provided this piece of the puzzle. Am I having a large misunderstanding, should I be able to spend from my channelbalance without doing an actual on chain funding transaction myself?

In principle what you do should work. However there is a subtle but important feature in the lightning network protocol (meaning this is with every implementation) which we call the channel reserve.

If you want to send money along a channel your node has to keep at least 1% of the channel capacity as a reserve / collateral to protect your channel partner in case you try to steal funds.

Let's say lnbig opened a 1 million Satoshi channel with you. As long as you do not have 10 thousand Satoshi on your side you will not be able to send money. If you have 11 thousand Satoshi in such a channel you can send up to 1000 Satoshi because you have to keep above 10000.


Could a 2/3 majority vote be used as a consensus I understand that Bitcoin currently is using the chain with most proof-of-work as consensus. However could this method be improved, like only allow one block being generated at any given time, and each node verifies this block with its own past data. If there are more than 2/3 nodes prove the block to be valid then the block is added to the chain. If someone wants to create a fake block, then he must control at least 2/3 of the total nodes. What kind of attack is this consensus vulnerable to?

Your proposal is not sufficiently specified:

How is the authoring node selected?
How does a node prove his authority to author a block?
How do other nodes show support for the published block?
How can the support for a published block be verified by other nodes?

It is not clear how your proposal achieves consensus at all. Additionally, there doesn't seem to be a significant cost associated to vote on blocks, so the proposal is vulnerable to Sybil attacks.


Cannot start C-lightning after reboot I have problems starting up C-lightning's lightningd on Debian Buster under vagrant.
Steps I followed:

Fresh install bitcoind
Install lightningd
Run rpc commands - all good.
Reboot system
Get the error

Following is the output of lightnind after reboot:
2020-07-20T02:59:44.639Z UNUSUAL plugin-bcli: Could not connect to 'lightning-rpc': Connection refused
2020-07-20T02:59:44.652Z INFO plugin-bcli: bitcoin-cli initialized and connected to bitcoind.
2020-07-20T02:59:44.730Z UNUSUAL lightningd: Waiting for initial block download (this can take a while!)
2020-07-20T02:59:44.732Z UNUSUAL lightningd: Unable to estimate opening fees
...
2020-07-20T02:59:44.732Z UNUSUAL lightningd: Unable to estimate max_acceptable fees
2020-07-20T02:59:44.925Z UNUSUAL plugin-bcli: bitcoin-cli getblock 00000000000000ad6082acfe902b2ee294f4d1219f12b67bf59f88bb9d4af729 0 exited with status 1

The first line is normal behaviour:
UNUSUAL plugin-bcli: Could not connect to 'lightning-rpc': Connection refused

Your lightningd cannot start if the underlying bitcoind is not up-to-date:
2020-07-20T02:59:44.730Z UNUSUAL lightningd: Waiting for initial block download (this can take a while!)
2020-07-20T02:59:44.732Z UNUSUAL lightningd: Unable to estimate opening fees
...
2020-07-20T02:59:44.732Z UNUSUAL lightningd: Unable to estimate max_acceptable fees

You just need to wait for bitcoind to finish IBD. lightningd will regularly poll it and launch as soon as it's synced.


How to avoid Bitcoin-QT's transaction fee or change size limit? I'm trying to find an easy way to enable my website to accept bitcoin payments.  I'm trying to test out Blockchain.info's "receive payment API" (http://blockchain.info/api/api_receive).  Near the bottom of the page, there is a PHP example (https://github.com/blockchain/receive_payment_php_demo) which I like to test out.  To test it out, I need to send bitcoin to Blockchain.info's address, who will later send the bitcoin back to me.  When I try to send 0.0005 BTC in my Bitcoin-QT client (v0.8.6-beta) , I get the following message:

"This transaction is over the size limit. You can still send it for a fee of 0.0005 BTC, which goes to the nodes that process your transaction and helps to support the network. Do you want to pay the fee?"

There are only two buttons for me to click:  Cancel  or Yes.  0.0005 BTC is worth approximately 50 cents or 100% of the amount that I want to send.  This is an incredibly expensive fee and not at all what is touted as a cheap way to send money.  When developing and testing, one will likely need to send bitcoin through this PHP code many times, which means that these fees can add up, and all I'm doing is testing.

How can I send BTC to test payment processing without paying this fee?

You are probably trying to pay with BTC collected from very small payments (known as dust). This dust is commonly collected from advertisement sites. Though they know sending small payments will break your wallet this way, they just don't care as long as you keep clicking ads!

Since transaction size depends greatly on how many payments you're drawing money from, this generates a very large transaction which is very expensive both for miners and other nodes in the network. To reward miners for this cost you have to pay a fee or they will just refuse to mine/broadcast it.

Unless you pay this fee the transaction will be rejected by peers/miners, no matter what you do.

As a workaround you might want to consolidate all the dust sending smaller payments to yourself, but it's a tedious process, still has high fees and might not be possible depending on the concrete amount of payments you've received.


avoid rounding errors in javascript with bigdecimal? a user submits a buy request: 0.0104 BTC at a rate of 345.92 EUR

config:

var mode = RoundingMode.HALF_EVEN();
var satoshi = new BigDecimal("100000000");

user input:

var btc_b = new BigDecimal("0.0104");
var rate_b = new BigDecimal("345.92");

convert amount to smallest unit:

var btc_s = btc_b.multiply(satoshi);

btc * rate = spend:

var eur_s = btc_s.multiply(rate_b).setScale(0,mode);
console.log(eur_s.longValue());

output: 359756800

eur / smallest unit:

var eur_b = eur_s.divide(satoshi, 8, mode);
console.log(eur_b.longValue());

output: 3.597568

but since eur has only 2 decimals:

console.log(eur_b.setScale(2,mode).longValue());

output: 3.6

i assume the user must spend 3.6 EUR for 0.0104 BTC at a rate of 345.92 EUR

here's a fiddle: jsfiddle.net/nvkja98c/

please correct me if i'm wrong!

This is not a rounding problem.  The 3.6 EUR is correctly rounded to two decimals from 3.597568 EUR.

Computers don't know when we want to see trailing zeros.  The problem is formatting:

console.log(eur_b.setScale(2,mode).longValue().toFixed(2));

output: 3.60

(fiddle)


where are the 21.co bitcoin tutorials? I had a bunch of links for the 21.co bitcoin tutorials. It was quite extensive, and I thought I would start working on them for some day. The day has come, but I can't find the material.

They have rebranded the website so it became earn.com and I can't find the tutos anywhere on the web. I guess another good reason to dislike coinbase.

If you have info, or a mirror link, or whatever, I would be grateful.

Edit: The url https://earn.com/learn/ gives a 404 which is a sad thing.

It looks like they have been archived over at archive.org.


Solo Mining vs Pool Mining for users with high computing power Let's say that a user has a decent amount of computing power. At the current difficulty of 1777774.4820015, he could have for example 10Gh/s (he would earn around 5 BTC per day according to a calculator).

Is it more profitable for him to solo mine or to pool mine? What are the differences in this situation?

It completely depends on the "pool fee". Theoretically, with a zero percent pool fee, solo mining and pooled mining should, over the long term, produce precisely the same revenue. The only exception is that some (most) pools keep the transaction fees for themselves.

If you mine solo, with an expected 5 BTC/day take, that will mean on average you'll mine a 50 BTC block every ten days. It will be completely random though. You could mine two blocks in a day. You could go three weeks without a block. When the difficulty changes, not only will the amount you get paid change (that always happens) but the time between payments will change drastically as well.

If you mine in a pool, you take the pool fee right off the top. A 3% pool fee means you make 3% less. Also, most pools don't pay transaction fees. But your revenue is more predictable. You'll get paid on a regular basis and your payments won't vary much (until the difficulty changes, of course).

One advantage to solo mining is that it's more reliable. Pools have outages and have had a problem with denial of service attacks lately. Mining solo, you aren't relying on other people's systems to keep your mining going. If you pick a very reliable pool, or use a mining proxy with a "fallback pool" configuration, this isn't a major issue.

One advantage to pooled mining is that you get to use the pool's tools. These include things like web-based control panels, alerts, and so on.


Good informational material on BTC trading? Market vs limit? I just signed up on Gemini, and I have to admit that I have no idea what I'm doing. Is there any place I can study up on how this works?

Investopedia.org is good, in general.

To answer the other part of your question (Market vs. Limit):

A market order is an order that will execute at whatever the current price is (no matter what - so be careful).  A limit order is an order that will execute only at the price you specify (or better, so it's much safer).


Can the Bitcoin Miner run offline? Is it possible to run a Bitcoin Miner offline and calculate hashes without being connected to the Internet?

You cannot earn Bitcoins mining unless you either add blocks to the blockchain or cooperate with others to do so. Without being online, you wouldn't know the current head of the blockchain (or any information based on it), so there's no way you could actually do either of those things. You could hash all you want, but you would never mine a block nor contribute towards mining one, so there wouldn't really be any reason to do so.


Block messages with transactions hashes instead of full transactions When a bitcoin node has the blockchain in sync, most transactions in incoming block messages may have been already received as standalone tx messages before.

With a block message with only transaction hashes, the receiving node could try to reassemble the full block with its unconfirmed transactions and just request the missing transactions to complete the block.

Since this way to save bandwidth looks too obvious, I'm guessing there must a reason to always include the transactions in block messages, even after downloading the blockchain.

There are probably several reasons, but it's mostly historic. There is no inherent problem with just sending transaction id's. There is a disadvantage too, though, namely increased latency, which is not necessarily a problem when doing an initial sync, but it is not wanted when a fresh new block is propagating.

In fact, this idea is part of BIP 37, which specifies a protocol extension for requesting filtered blocks. To avoid the increased latency, matching transactions that are not known to the server to be already known to the receiver, are sent immediately after the filtered block itself.

Edit: BIP152 compact blocks also use this idea, though they use shortened 48-bit transaction ids instead to save space.


Sgminer No Login Credentials Supplied I just started using sgminer but ran into some issues trying to get it to run correctly. Upon running my bat file I get an error saying: 'No login credentails supplied for hash-to-coins.com'. Below are my config and bat files with the worker name/password faked. If I run without the config file the miner recognizes the 9790m but will still fail to connect to the stratum. Any help is appreciated, I've been trying to fix this for several days now.

bat:

Config:

After a lot of search I finally found what was causing the issue. Apparently with Asus routers the AIProtection regarding malicious site blocking will actually block the connection to the pool. Disabling this setting in the router resolved the issue.


How to broadcast a transaction without using third parties Without running a node, just via terminal, can you build and complete the broadcast of a transaction without using a third party PushTx API? How do I connect directly to the network? Is it possible? What do you need?

Yes, it is possible. You need to have a software that can connect to nodes on the network and speak the P2P protocol. That software can then broadcast the transaction by relaying it to multiple nodes who will relay it to their peers and so on and so forth.

One such software is the submittx script writen by Wladimir J. Van Der Laan.


Wasabi CoinJoin Produces Non-Existent Coins/Transactions When using the wasabi coinjoin feature, the coin(s) are queued up and the status makes it all the way through four green circles.  After the signed status appears next to the enqueued coin(s), 4 new coins appear each with a separate Privacy indicator:

The new coin with the green checkmark has no status, the coin with the yellow & the coin with unchecked-green say waiting for confirmation, and the red 'x' coin says registered.  However, when I right click any of the new coins and select 'Open Details' the transaction ID doesn't match any existing transaction.
Similarly, the history entry for the transaction fee is also associated with the same transaction id that doesn't match an existing transaction.  And the address for the original coin shows no confirmed/unconfirmed spend transactions.
After waiting a period of time the four new coins disappear, the original coin re-appears, and the history entry for the transaction fee disappears.
How can coinjoin be used to avoid this error?  Why is there no error status for the operation?
Thank you in advance for your consideration and response.

There was a bug in the full node software we were using to broadcast transactions: Bitcoin Knots 0.19. Adam Ficsor (nopara73) upgraded the backend yesterday with Bitcoin Knots 0.20, which has already fixed the bug. However things will take a few days to fully resolve (probably 99% of issues have already resolved though) as the backend's mempool have to get in sync with the mempools of other nodes on the network.
About the bug
It turns out when you broadcast transactions to Knots .19 through RPC, it allowed double spending (without RBF.)
So, if it's fixed why does it take a few days to fully resolve?
Consider the following event:
Yesterday, after Adam upgraded the backend with the proper full node he participated in the first coinjoin. It happened and even his own personal Bitcoin full node accepted it. But when he looked at it in various block explorers it turned out they were not aware of it. What's going on here?
He traced back that one of the input has participated in another coinjoin that neither the backend, nor his local full node knew about. So everything worked properly based on what the Wasabi software knew about the network.
However this first coinjoin had to confirm in order for his local full node and for the backend's full node to be aware of it and realize it's the tx that actually happened. But why weren't the full nodes aware of it in the first place?
His local full node was not turned on at the time when that first coinjoin happened. This is how Bitcoin Core works, when it's restarted it doesn't start asking for full mempools, but it rather works with what it has.
The backend's full node did know about the first coinjoin tx, but because of the double spend bug, it threw that out. However with the correct full node version the correct mempool did still not instantly came back, but right now it's working correctly with the wrong mempool and in a few days as transactions are confirming everything will be back to normal, if not already.
If you are still experiencing this issue 3 days after my post, try to turn Wasabi off, then turn it on again.


Unspendable outputs vs Black Hole address On the Script page of the Bitcoin Wiki, in the "Provably Unspendable/Prunable Outputs" section, it gives an example of a script which would make that output of the transaction unspendable. In the example they give,

txid eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29

The unspendable output has zero value so the entire input amount goes to the miner of the block.

But if that output had been given some value of bitcoin, would I be correct in assuming those bitcoins would be provably unspendable forever? If that is the case, what is the need of a black hole address like the bitcoin eater? Couldn't bitcoins be provably "destroyed" simply using such an unspendable script transaction output?

Thanks

If that is the case, what is the need of a black hole address like the bitcoin eater? Couldn't bitcoins be provably "destroyed" simply using such an unspendable script transaction output?

There is no need for addresses like the Bitcoin eater, but it is far easier to send Bitcoin to burn addresses than it is to create provably unspendable outputs. This is because most wallet software do not have the functionality to create outputs that are not P2PKH or P2SH, so it is more difficult to create the provably unspendable outputs.

However if you do want to burn some coins, you should use provably unspendable outputs as these do not bloat he UTXO set and there is not a no possibility that someone can get those coins (the burn addresses technically have a private key so someone could in theory get those coins by figuring out the private key).


how pool mining works? To my understanding, miners with small computational capacity are merged within a pool with the advantage to reduce the variance of rewards.

does this miner merge all the computational power so that Pow is calculated quickly??

But it is said that the even in the mining pool , there will be only one miner who will solve the puzzle and the reward is shared by the others miners in the pool depending upon the shares solved by them . The miner leader will identify the ones which are active in solving with providing the puzzle with lower difficulty and share the reward with them.

If there is only one miner finally which solves the problem. How is this miner helped by other miner for computation? if this one miner uses only its computation power then what is different in mining solely?

Mining is a game of luck, only one miner ends up mining a block but they all compete. Its like buying a lotto ticket. If one person buys a lotto ticket (i.e. mining by themselves), they will get to keep all the winnings to themselves if they win, but there chances are very slim at winning. On the other hand, if 20 people all buy lotto tickets together and agree to share the winnings between all 20 if any of the people wins, they have 20x higher chance of winning together, but get only a 20th of what they would have got if they were alone. That is what is meant by a more consistent income, you get a lot less per block but its more likely that you will at least get something, not nothing.


How key chain works for Bitgo multi-signature wallet? I am using bitgo service for Bitcoin wallet creation. Once I am creating bitcoin wallet using bitgo service, getting three different key chain which are user key chain, bitgo key chain, backup key chain which are storing in my database.

Suppose, hackers will get two key chain out of three, will they  make transaction or not?

Please assist me.

Anyone who has 2 out of the 3 private keychains (the private component of each keychain) can spend the Bitcoin. If you were hacked and the hacker was able to obtain 2 out of the 3, then they can spend your Bitcoin.


How can I get logging information on incoming transactions with bitcoind? Im running two Bitcoind Nodes. Is there anyway to log the incoming transactions and the output?

If you run the daemon or the GUI (bitcoin-qt) using the debug=1 argument, then bitcoin will write a variety of events to the debug.log file, including info about transactions received by your node.

I just ran a test to confirm this. You could follow these steps if you want:

(1) From the terminal window, start bitcoin-qt like this: $bitcoin-qt -debug=1

(2) Navigate to the /.bitcoin folder: $cd .bitcoin

(3) View the last few recent entries into the debug.log file: $tail debug.log

When I did this, I saw the following entry:

2017-11-21 12:58:54 AcceptToMemoryPool: peer=3: accepted 4e1a7429f28c7410e177bf3278aca76b6e32e097ed8d87dbd18980de9c23f343 (poolsz 18765 txn, 94644 kB)

I then copied the transaction ID and cross-referenced it at blockchain.info:

https://blockchain.info/tx/4e1a7429f28c7410e177bf3278aca76b6e32e097ed8d87dbd18980de9c23f343

And as expected, it was there as an Unconfirmed Transaction (which makes sense because the log entry mentions "AcceptToMemoryPool", so it sound like my node received a transaction from a peer, and has decided to put it in the mempool - that's just my guess, maybe I'm wrong)


How many nonces on average do I need to try in order to get n leading zeros? Assuming 256-bit hash output, how does the (average) number of nonces I need to try (to solve the proof-of-work puzzle) grow with the number of leading zeroes required, n? Is there a bound on this number?

If you want n zeroes when written in binary, 2n.

If you want n zeroes when written in decimal, 10n

If you want n zeroes when written in hexadecimal, 16n.

If you want n zero bytes, 256n.

However, none of these things are relevant in terms of Bitcoin. The difficulty is not the number of zeroes required; the difficulty is the minimum ratio between a well-defined maximum value, and the hash you got (when interpreted as a 256-bit unsigned integer).

In practice, the formula is that you need difficulty * 248 / 65535 attempts.


Historical rollbacks of Bitcoin and Etheruem blockchain I'm trying to get all historical rollbacks of Bitcoin and Ethereum. I get that there were hard-forks (e.g. DAO incident for Ethereum). How about rollbacks because of attack or miners failed to validate the block, etc.? Appreciate it if anyone knows or can point me to some external resources

Apart from Ethereum uncles and Bitcoin orphans which are tiny forks that happen all the time, these were two instances that I found related to bitcoin bugs:

https://en.bitcoin.it/wiki/Value_overflow_incident: rolled back by community patch
https://en.bitcoin.it/wiki/DOS/STONED_incident: no rollback needed

To answer your question, the blockchain can never be rolled back due to failure of miners to validate a block. By definition, a block gets added once a miner validates a block. If all miners suddenly turned off their equipment, no blocks would be produced, and transactions would sit in mempool until some miner took advantage of the extremely low difficulty and started producing blocks again.


Just received $50 worth of Bitcoin from someone? I am not sure who has sent it to me and why but I just received $50 worth of BTC. How do I find out where it came from?

Accepting an anonymous payment may bite me in the behind later on. Is there an option to deny BTC payments?

Something to think about....

It's impossible to deny BTC payments, you have probably provided your btc adress somewhere. It's extremely improbable that they typed in your adress randomly.

Only reason why you should worry is if published your private information and an that btc adress. But in this case it's just $50 and you can keep it unless you would like to return it to the sender.


Pool comparison list? Where can I find a list of pools and their features? I want to choose the best pool. On google I find no good comparison.

https://blockchain.info/pools

You can browse bitcoin wiki:

https://en.bitcoin.it/wiki/Comparison_of_mining_pools

As Egor notice, here a litecoin.info:

http://litecoin.info/Mining_Pool_Comparison

Partially outdated, http://pastehtml.com/view/awb1vg03r.html

Also, there is thousand of sites, like this:

http://www.coinindex.org
http://howtobitcoin.info
http://www.tblob.org
etc...

Probably, nowhere you can find a full list of alt-coins pools, because this part of net changes so fast.

See,

https://www.google.com/search?q=BOTPOOL
https://www.google.com/search?q=MPOS+by+TheSerapher <-- from the second page start pools, 6 pages, about 20 pools.


identical coinbase transactions this sounds like an old topic but i have not found a satisfying answer yet; in history there lived two blocks with identical coinbase transactions:

https://www.blockchain.com/btc/block-index/106662
https://www.blockchain.com/btc/block-index/106692
https://www.blockchain.com/btc/block-index/106572
https://www.blockchain.com/btc/block-index/106730

but if you check the receiver address (1, 2)you would find they both get rewarded only once not twice; even though the same transaction was being used repeatedly, the two blocks have different nonces, which proved two shares of work in mining; then, which rule regards this as invalid and why is it designed like that?

Duplicate txids were made invalid with BIP30 in 2012. The code was updated here: https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514 to apply the new rule "to all blocks except the two historic blocks at heights 91842 and 91880 on the main chain that had to be grandfathered in." (These are the blocks you linked above).

The reason why they received the reward only once is because a given txid can only be spent once (no double spending is allowed). If one of the utxo is spent, then both get marked as spent since they have the same txid and vout index, so only one is listed as received. It also depends on the block explorer and how it handles the duplicate txids.


Unable to view coinbase transactions on blockchain.com I'm trying to view some of the transactions I've made on coinbase on blockchain.com. I copied  my btc wallet address from coinbase and searched it on blockchain.com -- nothing showed up.
Why is this the case?
Per my understanding, given that coinbase stores my btc inside blockchain-powered wallets after I buy them, I should have been able to see all of my transactions.

Since a Coinbase account is custodial, Coinbase can move money from internal account to internal account without recording it on the blockchain. These sort of internal transactions between Coinbase and its customers are not normal Bitcoin transactions. So far as the Bitcoin network is concerned, Coinbase own the money not you.
I'm not sure what a Coinbase account "BTC wallet address" would be, but I guess either it isn't a valid Bitcoin address (but instead something proprietary and internal to Coinbase) or it was mis-typed or just hasn't been used yet for any on-chain transactions.


hello please let me know whats wrong with this script for find Reuse R value hello friends here is the code to find reuse R values of bitcoin transaction but unfortunately it is not scanning more than 51 transaction secondly it can only use one address at a time and i want to use text file to check multiple addresses as well as i want to save the output in a text file please help me to sort out

import json

import urllib2

import time

import sys

#for some reason blockchain.info api-chain is 59711 blocks short..

blockstart = 170399

blockstart += 59711

blockcount = urllib2.urlopen("https://blockchain.info/de/q/getblockcount").read()

print "WELCOME TO R-scan v0.1.2!"

print "ADDRESS-R-SCAN: "

addr = raw_input("type address:  ")

urladdr = "https://blockchain.info/de/rawaddr/" + str(addr)

#control api-url

print urladdr

addrdata = json.load(urllib2.urlopen(urladdr))

print "Data for pubkey: " + str(addr)

print "number of txs: " + str(addrdata['n_tx'])

#tx-details:

y = -0

inputs = []

while y < addrdata['n_tx']:

print "#################################################################################"

print "TX nr :" + str(y+1)

print "hash: " + str(addrdata['txs'][y]['hash'])

print "number of inputs: " + str(addrdata['txs'][y]['vin_sz'])

#only if

#if addrdata['txs'][y]['vin_sz'] > 1:

zy = 0

while zy < addrdata['txs'][y]['vin_sz']:

  print "Input-ScriptNR " + str(zy+1) + " :" + str(addrdata['txs'][y]['inputs'][zy]['script'])

  inputs.append(addrdata['txs'][y]['inputs'][zy]['script'])

  zy += 1

y += 1

print "compare: "

xi = 0

zi = 1

lenx = len(inputs)

alert = 0

#compare the sig values in each input script

while xi < lenx-1:

x = 0

while x < lenx-zi:

  if inputs[xi][10:74] == inputs[x+zi][10:74]:

      print "In Input NR: " + str(xi) + "[global increment] " + str(inputs[xi])

      print('\a')

                   print "Resued R-Value: "

      print inputs[x+zi][10:74]

                   alert += 1

  x += 1

zi += 1

xi += 1

#check duplicates

#alert when everything ok

if alert < 1:

print "Good pubKey. No problems."

sys.exit()

Use my code located here:

In your working directory (that you cd'd into) create an addr.txt containing your list of addresses separated by space or a newline.
Run it as python3 rscan.py 2>out.txt. It'll print the progress and if anything bad is found it'll be in out.txt in your working directory.


How do we have one-to-one mapping given the key size differences? If public keys are 34 characters long, and private keys are 61 characters long, then the combinations of 34 characters is not sufficient to give each combination of 61 characters a unique pair.

My calculations show 8.6 * 10^89 combinations for a private key.

And 9.0 * 10^59 combinations for a public key.

So how do we have one-to-one mapping?

(Please correct me if I am wrong).

We don't have a one-to-one mapping in the sense that you are talking about. But, for practical purposes, we have a one-to-one mapping. Yes, if someone tried to map every single key, after a few million centuries, they'd have a problem. But we won't have to worry about that until long after the stars burn out.

To find two keys that hash to the same ID, you'd have to try on average 2^80 keys. If you had a million computers, each capable of trying 1,000 keys a second, it would take 380,000 centuries to find a single match. And all you could do with those two keys was claim money sent to the same ID with either one, which would cause no harm at all.

Now, if you want to find a key that matches a key that actually has Bitcoins already, that's a much harder task. Say there are 10,000,000 IDs that have coins. The odds of a single key matching one of these 10,000,000 is 2^160/10,000,000 -- even with 1,000,000 computers each trying 1,000 keys a second, it would take billions of billions of centuries.

So for practical purposes, it's one-to-one.


Can a coinbase transaction have a segwit output? And more generally speaking, are there any restrictions on the output of a coinbase transaction?

Other than the total value needing to be correct (no more than the block reward plus fees), the outputs of a coinbase transaction are completely unrestricted and act the same as any other transaction.


To what is bitcoind memory usage bound? I am interested in running a well-connected node, and I was wondering: is the memory footprint directly correlated to the number of connections?

And more broadly: with what RAM usage increases?

RAM usage increases until it is slightly less than the total RAM available. This is due to the design of the operating system which intentionally keeps as little RAM free as possible, using all excess RAM as a disk cache to reduce I/O.


What is the largest transaction by value to date for bitcoin currency? As the title asked - what is the largest transaction by value to date?

Probably this one, 550,000 BTC transferred at one time.

http://blockexplorer.com/tx/29a3efd3ef04f9153d47a990bd7b048a4b2d213daaa5fb8ed670fb85f13bdbcf

Now the question, was it a transfer from one person to another, or was it a transfer simply to, for example, another wallet once the passphrase encryption feature was made available.


How can I compile bitcoin on debian 7.x Wheezy? Missing libmemenv.a In the bitcoin leveldb branch, the file libmemenv.a is missing. Because the debian leveldb package does not include it, bitcoin will not compile on debian systems.

Is there any workaround? Will you all be including this library in an upcoming release?

As per: https://bitcointalk.org/index.php?topic=270852.380

Try:

make -f makefile.unix "USE_UPNP=-"

UPNP is not enabled by default anyway, so compiling without it shouldn't be a problem for normal operation.


Which country has the highest number of Bricks and Mortal merchants who accept Bitcoin per Capita? I have seen many online directories of Bitcoin merchants but fewer bricks and mortar directories.

Is https://coinmap.org comprehensive? The great majority all of the listings are for North America and Europe?  I hope that listings are being missed in countless other parts of the world.

Many say the 3rd world is potentially the largest beneficiary of blockchain technology but the current statistics are not painting a bright picture for adoption in most areas.

Coinmap is definitely not comprehensive. I imagine most of the listings are in NA and Europe because the site itself is in English. I doubt there will ever be a comprehensive centralized repository of brick-and-mortar stores taking bitcoin just due to the nature of the network itself.


How does the CPU hashing algorithm used in Yacoin differ from scrypt? Alt-coins are now a dime a dozen and with only minor changes to generation rates, difficulty, and algorithms, they all tend to use the SHA-256 (bitcoin) or the scrypt (litecoin/tenebrix)  hashing algorithms for solving blocks.

A friend of mine recently told me about Yacoin and it uses a modified version of scrypt so that mining via GPUs is currently "impossible".

What are the specific differences between the standard litecoin scrypt algorithm and the yacoin algorithm that makes yacoin currently infeasible to mine on GPUs?

The scrypt-jane modification allows the N in scrypt(N,1,1) to change. Litecoin uses scrypt(1024,1,1). GPU miners haven't taken this into account. But now you have the opposite issue. Instead of the GPU miners getting everything, it's the datacenters who have the advantage.


Trying to understand how exchanges handle crypto From my understanding. (which is very very limited)
Crypto exchanges give their users a bitcoin address to send their crypto to. This address is a derived/child key from their own wallet. Once this wallet receives bitcoin the exchanges then credit their account.
But this means that the crypto is on two different wallets which means they'll have the send the crypto again which means another onchain update which means another bitcoin transaction fee
If the logic above is correct then 3 transaction fees are required to take place. Sending the bitcoin in. Merging the bitcoin into a main wallet. Withdrawaling the bitcoin. (Merging may not always be required)
My question is, if this is true (which it may not be, in which case PLEASE correct me and explain how it works) why would crypto exchanges give users their own bitcoin addresses? Why would they not just give the users their main bitcoin address and ask the users to include a user_id on the transaction memo?
Edit: I asked a similar question recently which stated, that only 2 onchain events happen. This is because the public address the user is given is actually directed to the exchanges wallet. How is an address generated from a public address?

Why would they not just give the users their main bitcoin address and
ask the users to include a user_id on the transaction memo?

Bitcoin is not the Ethereum and historically the fees were cheap in past. With creation of altcoins (shitcoins) a lot of them implemented this memo ability, in many cases wallets of altcoins support it by default. But this feature is available in bitcoin (OP_RETURN script) it isn't implemented in vast majority of bitcoin wallets. So exchanges historically haven't had an incentive to drag users this way.

If the logic above is correct then 3 transaction fees are required to
take place.

Not really, in most modern exchanges the withdrawals are being paid directly from depositors' addresses. So it's 1 transaction to put money into exchange backend, and 1 to withdraw it. With the change usually going to main "hotwallet" of exchange or series of "change" addresses. And deposits aren't swept in if they don't have to usually (to save on fees).

Why would they not just give the users their main bitcoin address and ask the users to include a user_id on the transaction memo?

I think you are misunderstanding how it works, if user controls the address, the exchange is not. When it comes to key ownership, as long as more than 1 party owns the private keys, it can't be deterministically decided who "really" own it, until one of the party decides to manage these coins. When it comes to your memo idea most of the altcoin exchange integration works in a way that exchange is providing user with common exchange hot wallet address and unique memo id. The one exception to above may be some escrow multisig scheme.

why would crypto exchanges give users their own bitcoin addresses?

They never do. Exchange won't cooperate with party that has ownership of their own keys, because of fraud possibility, in the case I mentioned above. The only exception are businesses that sometimes have static addresses in exchange system, that they own - like liquidity providers. But it is a very rare practice and can happen on a basis of complicated legal constructs.