Running a command line bitcoin CPU miner on ubuntu for slush's pool I don't intend to do this long term as I am pretty sure the cost of the power would exceed the earnings, this is more for educational purposes. What I'm looking for is a command line miner for Ubuntu. What I've tried so far is using poclbm.py

./poclbm.py -d 0 http://worker:pass@api.bitcoin.cz:8332

however this only gives me

No PyOpenCL

Not using OpenCL

Nothing to mine on, exiting

I've found several guides on how to use poclbm however they seem to be out of date. That is to say that the command line arguments don't match up with the current project. I also have pyserial installed.

To sum it all up I don't care if I use poclbm or not I'm just looking for a tool to get up and running.

I suggest to use one of the updated cpuminer versions which support more than one algorithm. This way you are also set up to mine different coins which use other PoW functions. The most versatile one is tpruvot's fork:cpuminer-multi. For me this one worked out of the box on a recent Ubuntu 14.04 installation.

The syntax is similar to all other cpuminer versions:
cpuminer -a sha256d -o stratum+tcp://pool.com:port -O username.workername -p password


How to transfer bitcoins from one Currency to Another from Brazil I want to send money from real BRL to euro EUR. I live in Brazil.

How can I use bitcoins for that? And How would I make the bitcoins available for the person to spend in Euros?

Thanks.

You both need to have bitcoin wallet and know each other BTC address.

If you both have both bank accounts in each country it makes easy.

Buy BTC in your country with BRL.
Send BTC to the person living anywhere in the world.
He can convert his bitcoin against EUR via lobalbitcoins, exchanges or ATM in some cities.
Converting bitcoin to EUR might not be easy. Exchanges will require verification documents. If he can contact persons or go to an bitcoin ATM machine, that will probably not require verification process.


Transfer from old brainwallet to Trezor I have an old Bitcoin brainwallet that I created a few years ago (before any forks) with almost 1 BTC in it.  I know it's not a lot, but I decided to get a Trezor as a safer storage method.  I now want to move the BTC into my Trezor wallet, along with any of the forked coins that have happened since (BCH and ???).

What is the safest and simplest way to do this?  I'm not particularly technically savvy, so please break it down for me step by step.

By brainwallet do you mean a secure 12-or-24 word phrase? Or actually the incredibly risky and insecure method of deriving a Bitcoin private key from a short memorable string? Many brainwallets (like movie quotes, song lyrics, even complete sections of the US Constitution) have already been swept by attackers, and even more brainwallet addresses are being constantly monitored by bots that will sweep funds as soon as the address is used.

How did you generate your bitcoin address a few years ago? Is that software still available? You might be able to use it to sweep the funds to an address generated securely by your Trezor.

I have a brainwallet sweeper tool I use for fun low-value demonstrations, with lots of warnings about security:

http://dotshift.space/starservice/bitcoin/

You should audit the code before using if you can, but this webpage will search the blockchain for any brainwallet and if there are UTXO available, allow you to sign a new TX and sweep the funds to an address you provide.

As for the fork-coins, you may need to seek out resources in those communities separately, maybe someone can fork the code I used above and reconfigure it for other blockchains.


What determines BTC's wallet size in bytes? Does wallet.dat contain every address that I created?  Even if I didn't get any coins from it?
To be clear, suppose I run bitcoin-qt in Linux, and, in the GUI, I click on Receive then click on Create new receiving address:

At this point, no coins are received.  Will this immediately generate a new public-private key pair?   How was this public-private key generated?
Is this new key pair stored in wallet.dat even before me receiving any payments?
I receive coins on that address.  Will this affect the size of wallet.dat?

Basically I'm concerned on the size of wallet.dat as I keep creating new receiving addresses.
What determines the size of wallet.dat?  It's about 1.4 MB now.  What made it so?  What will make it change?
This is a graph showing how wallet.dat's size increases as I keep adding new addresses:

Looks pretty linear to me with a slope of 1135.0361445783133 bytes per address.  I wonder why is this?  Is it because wallet.dat is storing a whole new public-private key pair per address?  Or what is happening?
I then delted all those addresses, but  wallet.dat's size didn't reduce.  In fact it even increased!

Does wallet.dat contain every address that I created?  Even if I didn't get any coins from it?

Yes

To be clear, suppose I run bitcoin-qt in Linux, and, in the GUI, I click on Receive then click on Create new receiving address:

At this point, no coins are received.  Will this immediately generate a new public-private key pair?

Yes. Well, not quite, but in essence, yes. Bitcoin Core pre-generates 1000 keys in a structure known as the keypool. When you request a new address, one of those pre-generated keys is returned to you and another one is generated to replace it in the keypool. This replacement generation can be deferred to a later time, if, for example, your wallet is locked.

How was this public-private key generated?

Depending on when you created your wallet, either randomly, or with BIP 32. Newly created wallets with modern versions of Bitcoin Core will use BIP 32. BIP 32 is a deterministic way to generate keys from a randomly generated seed. Bitcoin Core randomly generates the seed and derives the actual private keys from it using BIP 32.

Is this new key pair stored in wallet.dat even before me receiving any payments?

Yes

I receive coins on that address.  Will this affect the size of wallet.dat?

Yes. When you receive a transaction, that transaction is added to the wallet and this will increase the size of the wallet.dat.

Basically I'm concerned on the size of wallet.dat as I keep creating new receiving addresses.
What determines the size of wallet.dat?  It's about 1.4 MB now.  What made it so?  What will make it change?

The size is largely determined by the number of addresses you have requested already, the size of the keypool, and the number of transactions that you have, both incoming and outgoing.

Looks pretty linear to me with a slope of 1135.0361445783133 bytes per address.  I wonder why is this?  Is it because wallet.dat is storing a whole new public-private key pair per address?  Or what is happening?

Yes.
If your wallet is unencrypted, each new keypair that is generated will add at least 388 bytes.
If your wallet is encrypted, each new keypair will add at least 120 bytes. This size difference is because encrypted private keys are encoded more efficiently than unencrypted private keys.

I then delted all those addresses, but  wallet.dat's size didn't reduce.  In fact it even increased!

Bitcoin Core does not allow you to delete addresses. However you "deleted" them, it was likely just hiding them.

If you want a smaller wallet, then you should create a new encrypted wallet. Note that this means creating a new wallet and choosing the option to make it encrypted. Creating a new wallet and then encrypting it after the fact will create extra keys that are never used and just take up space.


Understanding trading history On BTC-E, you can see the recent trade history for the different currency pairs. For example right now you see these recent trades:

14.05.13 01:27  Sell    112.75 USD  4.77859 BTC     538.7860225 USD
14.05.13 01:27  Sell    112.76 USD  0.359638 BTC    40.55278088 USD
14.05.13 01:27  Sell    112.76 USD  0.122198 BTC    13.77904648 USD
14.05.13 01:27  Sell    112.76 USD  0.022195 BTC    2.5027082 USD
14.05.13 01:27  Sell    112.76 USD  0.0100155 BTC   1.12934778 USD
14.05.13 01:27  Sell    112.76 USD  1.20736 BTC     136.1419136 USD
14.05.13 01:27  Sell    112.76 USD  0.360915 BTC    40.6967754 USD
14.05.13 01:26  Buy     112.9 USD   1 BTC           112.9 USD

Shouldn't every trade of type "sell" match a trade of type "buy"? Or at least the amount of all recent sell-trades should match more or less the amount of all recent buy-trades? If you look at the history of the last 15 minutes right now, the amount of BTC in sell-trades is much higher then the amount of buy-trades. How can this be?

Most exchanges work with an order book. In this method, the two parties involved in the trade are slightly different.

The order book lists prices at which people want to buy and prices at which people want to sell.

You can see btc-e's order book on their homepage. Let's assume the following simple order book:

SELL ORDERS:
    person 1 wants to sell 3 BTC for 101 EUR/BTC
    person 2 wants to sell 1 BTC for 100 EUR/BTC
BUY ORDERS:
    person 3 wants to buy  2 BTC for  95 EUR/BTC
    person 4 wants to buy  5 BTC for  90 EUR/BTC

Note the ordering of the orders, it's on purpose. In all order books, the highers buy price is always lower than the lowest sell price.

Now, these people are passive traders (this is afaik not an official term), meaning that they are waiting for the price to reach a certain value in order to trade. Mostly, they do not need to buy/sell fast, but want to have a good price.

Then, there are active traders, that want to do their trades immediately. So, when I want to buy 1 BTC immediately ("at market price"), I will have to pay 100 EUR for it, as this is the best sell offer I can buy from. If I wanted to fast sell 1 BTC, I would get only 95 EUR for it, meeting the best buy order to sell at.

So in fact, when an active trader wants to buy 1 BTC, he actually creates a buy order for 1 BTC ar 100 EUR/BTC. This order will match the order from person 2, so they will trade. This means that the trade is initiated by the buy order from the active trader. For this reason, this trade will be logged as a buy trade.

Rounding up: Trades are logged according to the type of trade the active trader did.

Some things that are useful to keep in mind:

The bid/ask prices that most exchanges advertise, are the highest buy and lowest sell prices from the order book, respectively.
A buy trade will raise the lowest ask price (or keep it the same), while a sell trade will lower the highest bid price.


What is the current (Feb 2012) "bus factor" of the standard client? Bus Factor (Youtube) is the

  total number of key developers who would need to be incapacitated (as
  by getting hit by a bus) to send the project into such disarray that
  it would not be able to proceed

What is the current bus factor of the Bitcoin standard client?

As of today, perhaps 20

Generally what makes a "core developer" as opposed to a "contributing developer" is an ongoing interest in the codebase that typically equates to near full-time employment. Should all core developers fall under the wheels of this continent-spanning bus of doom then Bitcoin would suffer a significant blow.

For a while.

Then various contributing developers (of which there are legion) would likely step up to act as replacements. The discussions on the forums, IRC channels, mailing lists and version control systems will be read and acted upon. Bugs will be fixed and life will go on.

Edit: So where does this number "20" come from? Well it's based largely on my experiences from reading the development mailing list, IRC logs and various Google+ circles. There is no real exact number, though, activity varies over time and various people are "core" to a particular issue as it passes through.


Test in a box duplicating addresses how come? I copied the whole directory for bitcoin data and then ran two instances one for the first directory and the other for the copied one, and then I generated a new address from the old instance go to the new instance and ran validate address it showed "ismine":true !!

Could you please explain this ?

Bitcoin Core uses a "keypool".  When it first runs, it generates a list of 100 new addresses.  After that, each time the user asks to "generate a new address" (or an address is needed for change, etc), the next address from the keypool list is used, and a freshly generated address is added to the end of the list to replace it.  The keypool keys are stored in wallet.dat along with your other private keys.

The purpose of this feature is so that when you back up wallet.dat, you get not only the keys you have already used, but also the next 100 you will use.  If this were not the case, then everytime you generated an address or made a transaction (generating a change address), you would have to immediately backup wallet.dat again, and you'd be vulnerable to losing coins if your disk crashed in the meantime.

So when you copied the entire Bitcoin data directory, including wallet.dat, you also copied the keypool.  As such, the next 100 addresses "generated" by both installations will be the same.    After that they will differ.

But you probably didn't really want to share the wallet between both installations, since this can cause confusion unless you really pay attention to what you are doing.  So you can delete the wallet.dat from one of the installations (if you have made real transactions with it, back it up first) and let it be regenerated.


where to get specifications about how to make a block in bitcoin mining I read that i have to hash 3 things(previous block's header, nonce, current block contents) using the sha 256 algorithm to get a hash that has required number of zeros at the start, in order to add my block to the blockchain.

where are the specifications for combining to form a block?

I have a sha 256 program that can perform a hash. I need to know
1. where to get the latest block?
2. what parts of the latest block to use?
3. where to get the latest transactions?
4. what parts of the latest transactions are to be put in a block?
etc

there must be specifications for these. can anyone please tell me where to find it?

Thanks much,
ms

You'll need to hash the block header, which is actually made up of 6 items: the version bit, the hash of the previous block, the merkle root of transactions you're including in your block, a timestamp, a target difficulty, and a nonce value. This page on the bitcoin wiki contains more info, I think you'll find it helpful.


Is there a list of established sites that have started accepting Bitcoin? Cross posted to Reddit.

I believe the Trade page mostly has new sites, not a lot of existing ones. To me, any existing, established site that goes Bitcoin is worth more than ten new Bitcoin-accepting sites.

http://stuffexists.com/  has a good list.


wondering How to use Bitcoin Parser? I'm a freshman of bitcoin system and I'm trying to find out how to use bitcoin parser. I downloaded several from internet but they were not work out. Currently I am using Bitcoin Knots wallet and downloaded all blockchains (approx.223GB). I know those data are preserved in the file names blockchain and they are in the form like blk0xxxx.dat. But how to parse those files? I really want to know the answer!

But how to parse those files?

It is not too difficult to parse bitcoin blockchain if you have programming skills and know what you want to do. Have a look to my piece of code - this is just a working example that parsing is easy. Of course, you have to write code in your favorite language for your task

#include <QTimer>

#include "BlockChain.h"
#include "Util.h"
#include "MyByteArray.h"
#include "Target.h"

BlockChain::BlockChain ( QObject* parent ) : QFile ( parent ), blkFile ( START_BLOCK )
{
  connect ( this, SIGNAL ( block ( const QByteArray& ) ), parent, SLOT ( block ( const QByteArray& ) ) );
  connect ( this, SIGNAL ( doneFile ( ) ), parent, SLOT ( doneFile ( ) ) );
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}

void BlockChain::start ( )
{
  setFileName ( blkFileName ( blkFile++ ) );
  if ( !open ( QIODevice::ReadOnly ) )
  {
    _trace ( QString ( "cant open [%1]" ).arg ( fileName ( ) ) )
    emit block ( QByteArray ( ) );
    deleteLater ( );
  }
  else
  {
    _trace ( QString ( "processing [%1]" ).arg ( fileName ( ) ) )
    QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
  }
}

void BlockChain::next ( )
{
  if ( pos ( ) < size ( ) )
  {
    quint32 magic;
    quint32 sz ( read ( (char*)&magic, 4 ) );
    while ( !magic && pos ( ) < size ( ) - 4 )
      read ( (char*)&magic, 4 );
    xassert ( ( ( magic == MAGIC_ID ) || !magic ) && ( sz == 4 ) )
    if ( magic )
    {
      read ( (char*)&sz, 4 );
      emit block ( read ( sz ) );
      QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
      return;
    }
  }
  close ( );
  emit doneFile ( );
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}

const QString BlockChain::blkFileName ( const int i ) const
{
  return
    ( i < 10 ) ? QString ( DATA_ROOT "\\blk0000%1.dat" ).arg ( i ) :
    ( i < 100 ) ? QString ( DATA_ROOT "\\blk000%1.dat" ).arg ( i ) :
    ( i < 1000 ) ? QString ( DATA_ROOT "\\blk00%1.dat" ).arg ( i ) :
    QString ( DATA_ROOT "\\blk0%1.dat" ).arg ( i );
}


Completing a bitcoin transaction I sent bitcoin to a company address for investment .  Transaction was confirmed. The output to the company address indicates that it has been spent.  However, the output to the other address shows output is unspent. Two questions: Does this mean the company has received the payment for the investment? Can l claim the unspent output ?

Does this mean the company has received the payment for the investment?

Yes

Once a transaction has more than about 6 confirmations it is regarded as complete and the money is fully under the control of the recipient

  Can l claim the unspent output ?

No and Yes.

If the recipient hadn't yet spent the money you sent them, it is still their money not yours. You no longer have any control over it.

The change returned to you is under your control, you can spend it whenever you want. Your wallet should show this change amount included in your wallet "balance"


Is Bitcoin antifragile? A friend presented me the concept of antifragile and asked me if Bitcoin is antifragile. I couldn't answer properly, so I'm asking the experts:

Can bitcoin be categorized as antifragile?

With my only knowledge of the concept of "antifragile" being the slideshow I just read, my initial assessment is yes, Bitcoin is antifragile.

  Antifragile benefits from randomness and gains from disorder.

Randomness in Bitcoin appears in the random generation of keys and in the whims of its users' spending habits. No one person controls the system, and a transaction may or may not get processed based on connectivity and fees. There is an incentive to connect to as many nodes as possible in order to broadcast a transaction.

In Bitcoin, anyone is allowed to participate, because no one is prohibited. Participation may be cost-prohibitive now, but as time goes on, it won't be.

There are stressors on the Bitcoin ecosystem: block chain dust, nodes disappearing, nodes flooding transactions, etc. None are as close of a match as sudden jumps in hashrate and the subsequent adjustment to difficulty. Too much of a jump, and the "body" breaks: someone gets a 51% attack going. But, enough of a push and the difficulty increases, making it harder to break that 51%. Also, if the body hasn't been used enough - there hasn't been a high enough hash rate to produce the expected number of blocks - the difficulty lowers in order to allow more blocks to be found.

Thus, the Bitcoin system adjusts to its environment. Moreover, it does so in a chaotic way: there are rules set in the protocol, but those rules can be change if a majority of participants in the system agree to change the rules and agree on a new set of rules. In the absence of Internet, Bitcoin transactions can propagate through sneakernet or through even basic text format printable on paper.

Moreover, given the randomness of human economic behavior and the external environment which Bitcoin uses to propagate, various edges and remote notes of the network graph may have sudden activity that the rest of the network doesn't see. The rest of the network has to deal with that activity or risk invalidating itself.

Slide 40 is one where Bitcoin really is antifragile:

  Complex systems resist top-down design, and oftentimes even top-down interference. This is because these systems are simply too complex to be controlled from the outside.

Bitcoin is resistant to top-down design now because of the number of people using it and processing its transactions. Gavin Andresen could not suddenly make a change, because 51% of the network hashrate would have to agree with his change. No one can interfere, only vote to support or not support a given transaction by directing their miners to include or not to include a certain kind of transaction in the blocks they produce. Moreover, Bitcoin cannot be controlled by anyone except participants in its ecosystem (not matter what governments might think or try to do!).

All participants in Bitcoin have a skin in the game. By processing transactions, they in turn process their own transactions as well as the transactions of their peers. If they can get 51% of the miners to act a certain way, then that's the way the economy goes.

So, yes, I believe that, based on this slideshow, Bitcoin is antifragile.


Key Derivation - CKDprv & CKDpub I would like to replicate this derivation of keys.

Chain m
ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8
ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi

Chain m/0H
ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw
ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7

Chain m/0H/1
ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ
ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs

I correctly derived the keys in 0h using the CKDprv function. Here are the steps:

xpriv in m:

0488ade4 xpriv
00 depth
00000000 parent fingerprint
00000000 key index
873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d508  Chain Code
00e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35  Key
e77e9d71 Checksum

CKDprv:
HMAC-SHA512 (873dff81c02f525623fd1fe5167eac3a55a049de3d314bb42ee227ffed37d508 (Parent's chain code); 00e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b3580000000 (Parent's Key + Child'index))

Result (64 bytes + 64 bytes):
04bfb2dd60fa8921c2a4085ec15507a921f49cdc839f27f0f280e9c1495d44b5
47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141  (Child's Chain Code)

To find the child's key, I added the first 64 bytes with the parent's key

Now, for the next step, having a non-hardened index, I wanted to use CKDpub.

This is the parent's public key:

0488b21e
01
3442193e
80000000
47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141 (Chain code)
035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc56 (Key)
b8b9c580

In the HMAC-SHA512 operation I pass these parameters as input:
47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141
035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc5600000001

I get this result (64 bytes + 64 bytes):

b7d40c610c146701cdabb2df826716086d591664eb77de90b40c115bb653fb4d
5c8c3990242778e21f3d47c20428181c65de054baba9a156b798c0e85a10d9e4

By checking the chain code that the next key must have, the chain code obtained is wrong.

0488b21e
02
5c1bd648
00000001
**2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19**
03501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c
6f6e2af7

  What am I doing wrong?

If I understand your question correctly you want to take m/0h public extended key:

xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw

and derive m/0h/1 public extended key?

These are my values:

version: 0488b21e
depth: 02
fingerprint: 5c1bd648
child: 00000001
data: 03501e454bf00751f24b1b489aa925215d66af2234e3891c3b21a52bedb3cd711c
chain: 2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19

What is b8b9c580 in your result? //edit: I am guessing it's the checksum.

chain input to HMAC: 47fdacbd0f1097043b78c63c20c34ef4ed9a111d980047ad16282c7ae6236141
data input to HMAC: 035a784662a4a20a65bf6aab9ae98a6c068a81c52e4b032c0fb5400c706cfccc5600000001
Calculated hmac: 4eb9d78157bae7a24115001621c4d91e3a3110e11e143c5259eaa4e55c5ec4bf2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19
left: 4eb9d78157bae7a24115001621c4d91e3a3110e11e143c5259eaa4e55c5ec4bf
right: 2a7857631386ba23dacac34180dd1983734e444fdbf774041578e9b6adb37c19

Looking at your values, they are correct except the HMAC result. In python you'd do:

I = hmac.new(chain, data, hashlib.sha512).digest()

I used bip32utils python library to present the result, the end result (m/0h/1 xpub) is correct.


What is the data structure of the signature cache in Bitcoin? There is a signature cache in Bitcoin, which is used to cache the result of signature verification to avoid extra signature verification. What data is stored in the signature cache? Is it stored in the form of key-value pairs or other forms?
When a Bitcoin node performs block validation, how does it determine that the signature verification result of a transaction is already in the signature cache?

The signature cache is basically a set of public key, message hash, and signature tuples. When there is a valid pubkey, message hash, and signature combination, all of those are hashed together with SHA256. This hash is then inserted into the signature cache. So the signature cache contains only the hashes of valid combinations. When verifying a signature, the pubkey, message hash, and signature are hashed together, and that resulting hash is looked up in the signature cache. If it is in there, then the signature is known to be valid and actual signature verification can be skipped.
The signature cache itself is not just a set. It is actually a Cuckoo cache which is a type of hash table that guarantees constant time lookup in the worst case.


What makes cross input signature aggregation complicated to implement? What makes cross input signature aggregation complicated to implement? Other than for design space reasons why didn't it make it into BIP-Taproot? (Key aggregation within one input can be achieved with MuSig, MuSig2 etc but signatures cannot be aggregated across different inputs with BIP-Taproot.)
This questions was asked by Thorkil Vaerge on Twitter.

Pieter Wuille answered this on Twitter.
The most important complication of cross input aggregation is explained in this Bitcoin dev mailing list post by AJ Towns.

TL;DR: if softforks change which signatures are checked, they mustn't
change what is aggregated together. This is especially complicated when they interact with BIP341's OP_SUCCESSx upgrade mechanism, which could easily let future softforks change script semantics entirely. There is nothing fundamentally hard here - it's just engineering complexity to make sure everything works well together.

Pieter added at a London BitDevs Socratic Seminar on BIP-Taproot:

Graftroot and cross input aggregation are such deeply conceptual changes. You can’t permit building them later. It is such a structural change to how scripts work. These things are not something that can be just added later on top of Taproot. You need a successor. Cross input aggregation, the concept of script verification is no longer a per input thing but it is a per transaction thing. You can’t do it with optimal efficiency, I guess you can invent things. The type of extensibility that is built in is new opcodes, new types of public keys, new sighash types, all these things are made fairly easy and come with almost no downsides compared to not doing them immediately. Real structural changes to script execution, they need something else.


Create raw transaction in python I have a private key (raw + WIF) and I want to send all funds from that address - fee to another address.

Is there a raw python function that can do that for me ? I will broadcast the tx manually.

I tried to look into electrum source code but I find it to complicated for this task please help.

pycoin is probably your best bet. You need the utxo first, which you'll need to look up somewhere (blockchain.info is fine). Once you have the utxos, they'd need to be TxIns like this:

tx_in = TxIn("<utxo hash in binary here>", <utxo position, usually between 0 and 5>)
script = standard_tx_out_script(address)
tx_out = TxOut(<btc amount to send - fee>, script)
tx = Tx(1, [tx_in], [tx_out])
lookup = <this part you have to figure out>
tx.sign(lookup)
print tx.as_hex()

You can take the results and paste to something like blockchain.info's send transaction page.

NOTE: It's very easy to screw this up and have a too-high tx fee or lose your coins altogether. I would NOT recommend it. Install Armory and import the key or do the same using Mycelium. It's a lot safer to do it that way.


Bitcoin / blockchain security proof Has there been any research papers where someone has completed a full security proof model on blockchain / bitcoin ?

Yes, there is just such a paper, it is:

The Bitcoin Backbone Protocol: Analysis and Applications

by Aggelos Kiayias, Juan A. Garay, and Nikos Leonardos.

From the abstract:

Bitcoin is the first and most popular decentralized cryptocurrency to date. In this work, we extract and analyze the core of the Bitcoin protocol, which we term the Bitcoin backbone, and prove two of its fundamental properties which we call common prefix and chain quality in the static setting where the number of players remains fixed. Our proofs hinge on appropriate and novel assumptions on the “hashing power” of the adversary relative to network synchronicity; we show our results to be tight under high synchronization. Next, we propose and analyze applications that can be built “on top” of the backbone protocol, specifically focusing on Byzantine agreement (BA) and on the notion of a public transaction ledger. Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashing power is bounded by 1/3. The public transaction ledger captures the essence of Bitcoin’s operation as a cryptocurrency, in the sense that it guarantees the liveness and persistence of committed transactions. Based on this notion we describe and analyze the Bitcoin system as well as a more elaborate BA protocol, proving them secure assuming high network synchronicity and that the adversary’s hashing power is strictly less than 1/2, while the adversarial bound needed for security decreases as the network desynchronizes.


Bitcoin Pay-to-PubKeyHash (P2PKH) in multi-sig addresses Can we send Pay-to-PubKeyHash (P2PKH) to an address which starts from 3 . I tried to send raw transaction to one of my coinbase address which starts from 3 but it send to completely different address which starts from 1 . How can I send transaction to address which starts from 3 ?

Can we send Pay-to-PubKeyHash (P2PKH) to an address which starts from 3

No.

  How can I send transaction to address which starts from 3 ?

Construct scriptPub as OP_DUP OP_PUSH(bytes20) OP_EQUAL where bytes20 decoded from 3-address


How does Lightning Network over TOR work? I'm interested to understand in detail how the lightning network works over Tor. Implementations like lnd, c-lightning etc. offer an extension which allow running TOR with Lightning. I would like to understand how running Lightning with TOR works in practice. In particular I'm interested in the following cases:

1) I am the sender, but I enabled Tor in my node. How does sending to a node R outside Tor network looks like?

2) I am the recipient node, and I do not advertise an IP address, but an onion address. How do I receive payments?

3) The sender node S is a regular LN node, without any Tor connections. As a sender, I want to send a payment to node R and my LN node finds the best path to send my payment to R. Is it possible that this path will at any hop go thought Tor or go through onion node, because any of the nodes in the selected path happens to be onion or has access to Tor? And if yes, how the routing looks then?

Running lightning node over TOR is no different than running it over normal IP connection. Sending payment, fulfilling incoming payment, sending error messages etc. would happen in the exact same way in both cases. The only difference is that the above messages that you send to your peer will now happen over TOR network rather than a direct IP package.

If you are using only TOR without any public IP address then to route your payment to a node that is using only public IP address you will need to have a node in your path to the receiver that is (1) running TOR and public IP or (2) or running public IP and can connect to TOR nodes using the socks5 proxy. If you do not have this node in between you would not be able to send the payment.

When Tor service starts it creates a socks5 proxy which is by default at address 127.0.0.1:9050. If a node with public IP is started with the option --proxy=127.0.0.1:9050 (or including it in the config file) the node will be able to connect to nodes running TOR (like yours).

If you are running TOR and have a public IP address then you can directly connect with nodes that run tor or public IP nodes via the tor service socks5 proxy.

  I am the sender, but I enabled TOR in my node. How does sending to a node R outside TOR network looks like?

The network routing happens according to what I mentioned above. However, the path calculation for sending the payment to the receiver happens on your node so it does not involve what network routing you are using. You would construct the onion routing packet with the path to the receiver (the channels you will use to send the payment), and try to send this onion and the payment_hash to your peer via the update_add_htlc message. This message will then go over TOR nodes before reaching your peer, instead of a directly reaching your peer.

  I am the recipient node, and I do not advertise an IP address, but an onion address. How do I receive payments?

You can receive payments from nodes directly that are running TOR. If you want to receive payments from nodes that have only public IP, then you would need to have a node in your path that has the proxy option set so that it can connect to TOR nodes via socks5 proxy.

  The sender node S is a regular LN node, without any Tor connections. As a sender, I want to send a payment to node R and my LN node finds the best path to send my payment to R. Is it possible that this path will at any hop go thought Tor or go through onion node, because any of the nodes in the selected path happens to be onion or has access to Tor? And if yes, how the routing looks then?

Assume you the path from S to R looks like this: S -> T -> U -> V -> R. Number of cases can arise:

S and R do not run TOR: It depends

All the nodes could be on public IP and your payment goes through.
T could be node running public IP and TOR. It has a public IP channel with you, and TOR channel with U. U can then have a proxy option set that allow it to have TOR based channels with T and public IP channel with U. V is a public IP node and U routes payment to V in normal way.

R runs TOR: At least one node in between should run/understand TOR

T/U/V has a public IP, and have TOR so that they can make channels with TOR nodes and public IP nodes
T/U/V are all public IP nodes but V has a proxy option set which allows it to have a tor based channel connection with R.


Why bitcoin rise causes altcoins to drop? Bitcoin has grown significantly in the last few days. From what I can see on Binance, price of the majority of altcoins has dropped significantly relative to bitcoin at the same time. I've been thinking that bitcoin rise should make another cryptocurrencies even more valuable but looks like there is an inverse correlation.

So why are the altcoins dropping related to bitcoin so heavily? Can anybody explain what's causing such relationship? Thank you.

There are a few reasons, some examples (not limited to the below of course):

People will buy coins before forks, in the hope of claiming both coins and getting a "dividend" even if they don't believe the fork coin has value, they can simply sell at any price to get "free" money.  Possibly these people will then sell the coin they bought for bitcoin anyway, benefiting from the rise as other people bought in, and the sale of the fork.

Another possibility, if you're a BTC maximalist (and a "Whale"), is driving alt coins up, after the coin has pumped, you can sell back for BTC, increasing your BTC holdings.  Buying randomcoin and a few cents, driving the price up, or waiting for an announcement etc, will mean, again, you can safely move back to BTC increasing your holdings.  There's some circumstantial evidence of this happening.

People realising "gains" from alts, moving to BTC, people tell you to "diversify", but that's not always the best long term strategy, especially if your altcoins have experienced a gain, moving profits back to BTC (in lieu of FIAT) makes sense.

Dont forget the power of FOMO (Fear Of Missing Out), people will buy anything if the price is rising!


How to share your wallet key/seed in case you are hit by a bus This very useful answer says:

Share overlapping parts of your private-key or seed phrase with several family members with instructions on what to do if you are hit by a bus this afternoon.

This sounds like very good advice, but the details of doing so seem like a complicated balance of trust and chance of dying.  For example, I may trust my spouse most, but they are likely to be in the same car as me.  My parents next, but they are old and frequently in the same car driven by an old person.  My siblings next, but there are not many of them.  My friends somewhat, but there are lots of them and they do not all talk to one another.
Has anyone devised an algorithm to split up your private key or seed such that you can balance these considerations?  Perhaps something like allowing you to specify that any one of these sets of people are sufficient to access funds:

spouse and one sibling
both parents and one sibling
All siblings
7 out of 15 friends

You can accomplish all of this and more using a "pay to script hash". You can even do more complicated rules like "let my business partner have access to my account if either my lawyer or my wife agrees (but lawyer and wife can not together access account, so more complicated than just 2-of-3)."
Here is a great chapter on this stuff...
https://www.oreilly.com/library/view/mastering-bitcoin-2nd/9781491954379/ch07.html


Data type limit boundary in difficulty first and foremost I never read the bitcoin source code (I can't read any C) and I was wondering if Bitcoin, and any other crypto currency follow that they have data limits such as a maximum value of a long int is 4,294,967,295. If that case is true what would happen when the difficulty goes above the long int value. Hopefully this makes sense in how I worded it.

Of course they make use of these datatypes. They have to because it is how the CPU is constructed, the CPU and its instruction set architecture (ISA) work with fixed amounts of memory. This can be different per instruction, but can not be arbitrary.

If you need to perform arithmetic on arbitrary sized words, your only option is a software approach called a BigNum library. Bitcoin uses a BigNum library too (I believe some Boost stuff, but correct if I'm wrong). Examples include but are not limited to: GMP, Java's BigInterger class.


How can I troubleshoot whether an unconfirmed transaction that seems stuck is a problem on my end or just from high volume on mempool? Never had transaction hang unconfirmed like this before. Granted its only been a few hours but it's not like I skimped on fees either. I always choose the default electrum fee, but when it got stuck I doubled it using RBF to increase the fee.
But it's still stuck!
How can I check whether I'm really in the queue being ignored because people are paying higher fees or if there's something wrong I'm doing on my end?
Regenerating my wallet in electrum at least restored my pre-send balance. So at least I can see my coin even if there's no movement on this transaction that I'd love to either cancel out of or see confirmed.

How can I check whether I'm really in the queue being ignored because people are paying higher fees or if there's something wrong I'm doing on my end?

What was the fee rate used for the transaction?
https://mempool.observer
Example: I will have to use fee rate more than 100 sat/vbyte for a quick confirmation right now


Deriving payable address from mnemonic using BIP44 I'm trying to go from seed phrase/mnemonic to payable address using BIP 44.  Here is a simplified version of the code I'm using.  However, when I compare with https://iancoleman.io/bip39/ the private, public, and address don't match up.
var mnemonic = require('bitcore-mnemonic')
var bitcore = require('bitcore-lib')

var code = new mnemonic("width bicycle axis tell burst outdoor tray episode where they forest meadow enhance twin focus");

var xpriv = code.toHDPrivateKey(bitcore.Networks.livenet);
var derived = xpriv.derive("m/44'/0'/0'/0/0")

var privateKey = derived.privateKey
var publicKey = derived.publicKey
var address = new bitcore.Address(publicKey)

console.log(`address: ${address}`)
console.log(`privateKey: ${privateKey}`)
console.log(`publicKey: ${publicKey}`)

This code outputs:
address: 14TomZRSGPtoPGy9HZA8WfX2veMbDXyAAJ
privateKey: 34fb6aee170bb41fe47f97ab601fea589620cf182ecf031688c25e5491c2c06f
publicKey: 027869eb83bbb44621c868fbd2a31daed4a0f8dbaa73d3fd79a597cdb1afcc9d1d

However when I go to https://iancoleman.io/bip39/
it give as the first address with this seed phrase to be:
path: m/44'/0'/0'/0/0
address: 1BogrbApan5Q9xEFEzwPioRu3ogYkzAQZU
public: 0236f0bf97fa766301e1137bef8377e6f6063b8a576bda57220c7ab6cf531cc992
private: L46hcht5ue2tsSKmPEV2v41CrGU8DEJAP1w7XYPbvJ72v5NBPsPF

When you say simplified code it's hard to tell where you are going wrong.
Here's an example of how you can derive a bip44 key pair from a mnemonic using bitcoinjs-lib v3.3.2
let mnemonicInput = 'width bicycle axis tell burst outdoor tray episode where they forest meadow enhance twin focus';
let seedHex = bip39.mnemonicToSeedSync(mnemonicInput).toString('hex');

//"14a3235efb14b096e8cc3082b89e0b629ec5c7b2c6621343b2657cb61853b0830623e97b8aeac416d3377b4da90a4838d9aea4d83e0117fd833049305af46f10"

let root = bitcoin.HDNode.fromSeedHex(seedHex);
let deriv = 44;
let account = 0;
let change = 0;
let index = 0;

let acct = root.derivePath("m/"+deriv+"'/0'/"+account+"'");
let xpub = acct.neutered().toBase58();
let pair = acct.derivePath(change+"/"+index).keyPair;

let wifkey = pair.toWIF();
let address = pair.getAddress();

//"address":"1BogrbApan5Q9xEFEzwPioRu3ogYkzAQZU"
//"wifkey":"L46hcht5ue2tsSKmPEV2v41CrGU8DEJAP1w7XYPbvJ72v5NBPsPF"


Is there a limit to how much extra data can be put into blocks via scripts? According to this answer, miners can include extra data in blocks.

Is there an upper bound to how much a miner can add? How much?

The maximum size of a block is 1MB. A block can be filled entirely with arbitrary data.

Namecoin actually puts its extra data into the "coinbase" parameter, which is specifically designed to hold arbitrary data. Data put here is limited to 100 bytes, and this data will in the future be safely forgotten by most clients.


Colored coins implementation in Python Is there any implementation of this Colored Coins Protocol in Python?

I have found colored coins implementations in Python but, as far I as understand, they implement different protocol specifications (for instance Chromaway's ngcccbase or Open Assets).

Thanks!

There aren't any, unfortunately.

Rolling your own shouldn't be that difficult - I'd suggest using CoinSpark's OP_RETURN library as a starting point. All the best!


What is the difference (or relation) between a Bitcoin "Block" and a GPU workunit called a "Block" I'm looking at OpenCL and GPU programming and see the term "Block" used to describe a unit of work sent to a GPU.

What is the relation between a Bitcoin Block and a GPU workunit called a block?

If there is a relation, was this intentional?

No, these two terms are completely unrelated.

Bitcoin block is a record of some or all of the most recent Bitcoin transactions that have not yet been recorded in any prior blocks.

GPU block is just an unit of organization of threads running in parallel. The threads running on GPU are organized in blocks, and threads belonging to same block have effective means of interacting with each other. The size of single block and number of blocks affect application performance, and optimal parameters differ between different hardware. Surprisingly, while most GPU miners are written in OpenCL and not in CUDA, the 'block' term comes from CUDA and OpenCL specs use 'workitem' to refer to this concept.


When we receive a transaction or BitCoin payment, do we need to verify the message? I'm new to BitCoin, and as I'm doing my adventure, found a site and gave me some micro BitCoins to test and see how the system works. Now, I finally received a message in my Transactions in my Wallet and it was marked with a '?' in front of the message. Hovering over it showed that 0 of 6 verifications. So, do I need to verify the message? When I opened the menu on File, I saw it has a verify message option.

There are two distinct concepts here, confirmation and message verification.

Confirmation is a process by which transactions are confirmed as authentic and permanent by miners on the Bitcoin network.  Once a transaction is made, it will automatically accumulate confirmations over time without any further action on your part (and the the number you see when you hover over the transaction will increase).  The time required for each confirmation is random, but designed to average about 10 minutes.  6 confirmations is considered to be sufficient to essentially eliminate the risk that the transaction could be invalidated by a so-called double-spend attack.

Message verification is a more specialized feature of Bitcoin, whereby a user can sign a message proving that she is the owner of a particular address, and other users can verify this.  It is useful for certain specific applications, but isn't needed to send and receive ordinary transactions.

A good source for information about all these concepts is https://bitcoin.it.


Bitcoin RPC connection I am trying to insert bitcoin transactions into MongoDB using python3. Below is my code :

import pymongo
import sys
import json
import time
from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException

rpc_connection = AuthServiceProxy("http://xxx:xxx@ipaddress:port")

def getTransaction():
    addresses = []
    txa = []
    commands = [ [ "getblockhash", height] for height in range(400000,550000) ]
    #print(commands)

    block_hashes = rpc_connection.batch_(commands)
    blocks = rpc_connection.batch_([ [ "getblock", h ] for h in block_hashes ])
    print(blocks)
    for txpre in blocks:
        #print(txpre)
        for txs in txpre["tx"]:
            txa.append(txs)
    trans = conTransaction(txa)
    return trans

I am getting following error :

Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "Test06.py", line 252, in getBTCTransaction
    block_hashes = rpc_connection.batch_(commands)
  File "/home/administrator/.local/lib/python3.6/site-packages/bitcoinrpc/authproxy.py", line 165, in batch_
    'Content-type': 'application/json'})
  File "/usr/lib/python3.6/http/client.py", line 1239, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1285, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1065, in _send_output
    self.send(chunk)
  File "/usr/lib/python3.6/http/client.py", line 986, in send
    self.sock.sendall(data)
BrokenPipeError: [Errno 32] Broken pipe

I checked bitcoind  rpc connection,its connected.
   block_hashes = rpc_connection.batch_(commands) this code line is giving error. Can somebody tell me what's wrong?
Working on a remote server.

I found the solution. After doing changes in bitcoin config file, I just reduce the range of records to be inserted. RPC server cannot handle loads of data at one time. Otherwise, server down problem occurs and connection failed. Max 100 records get inserted at a time or less than that.
And one more thing, keep restarting bitcoind RPC server by stop and start commands given below:

sudo killall bitcoind
bitcoind -daemon -rpcuser=xxx -rpcpassword=xxx -txindex -rpcallowip=youripaddress


How is Transaction malleability affected by SIGHASH flags? SIGHASH flags allow for the flexible alteration of a transaction.

Given that there are legitimate usages of SIGHASH, and changing a Tx (and presumably the TxID as well), what is the correct way of using Sighash w.r.t. a TxID and tracking its progress?

What malleability risks do SIGHASH transactions incur by virtue of their usage?

SIGHASH flags allow for the flexible alteration of a transaction.

Yes, but the SIGHASH types mainly allow for incremental progress towards creating a full/final transaction, such as combining multiple transactions signed with SIGHASH_SINGLE. Once the transaction is fully created, there are certain tweaks that can be done to it that don't invalidate the tx but change the TxID, and these tweaks can be done regardless of how it was signed.

  What malleability risks do SIGHASH transactions incur by virtue of their usage?

I think the SIGHASH signing types allow for the alteration of transactions before they are final. Once a transaction is final, the malleability issues persist regardless of how it was signed. In fact, ECDSA signing itself (regardless of which SIGHASH type is used) is non-deterministic, so you could sign the same transaction twice and distribute them, and they would both be valid (but conflicting), but have different TxIDs.

  Given that there are legitimate usages of SIGHASH, and changing a Tx (and presumably the TxID as well), what is the correct way of using Sighash w.r.t. a TxID and tracking its progress?

To track a transactions progress, you will probably need some other way to identify the transaction other than the raw TxID (double hash of tx data). i.e. Some number associated with a transaction that is passed around to all who are editing it, or keeping track of the outputs of the transaction.


Does the value of my Bitcoin fluctuate automatically? If you own a small amount of Bitcoin (say,$10) does one have to "invest" it somewhere for it's value to change or will the $10 fluctuate by just sitting in one's wallet and one can see the value fluctuate by checking the wallet from time to time?

Whether it fluctuates or not depends on how you express value. If you happen to be one of them American folks, who use dollars to express value, then a fixed amount of money in other currencies (such as euros or bitcoins) will fluctuate.

But similarly, a $10 dollar bill will fluctuate in value, if you express value in euros or bitcoins (basically, that is if you live anywhere on the planet except the US).

It's all a matter of perspective.


How is "bytes to push" distinguishable in the scriptPubKey? Trying to parse scriptPubKeys and get the individual opcodes. My question is: How would you identify the "bytes to push" values?

Here's an example of the typical scriptPubKey:

  76       A9             14
OP_DUP OP_HASH160    Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA   88         AC
                      Data to push                     OP_EQUALVERIFY OP_CHECKSIG

bitcoin.it/wiki

Does "bytes to push" only occur after specific opcodes? Or is it that anything that doesn't correspond to an opcode is interpreted as indicating the upcoming number of bytes to push on to the stack?

Note: Basically any tips/advice on parsing the locking script would be handy.

It appears that anything between 0x01 - 0x4b in the scriptPubKey signifies the number of bytes to be pushed on to the stack.


Future of Pooled Mining What do people think lies in store for the future of mining coins from the point of view of both pooled mining and mining individually?

My assessment is that Mining Pools are the only mining operations that will exist and their fees will make the pool operators money, but the actual miners will only know Booms & Busts as the spot price, electricity costs, difficulty, etc will always vary.

If you want to make money in the mining world, your best option is to start a pool.


If newer versions of bitcoin and or bitcoin cash don't allow 0x04 uncompressed public keys, what do you do if you have an address based on one? So if you have an address with coins in it that uses an uncompressed public key (preceeded by a "04") then how can coins from that wallet be utilized with a network that doesn't allow such public keys?  Compressing the public key changes the relevant wallet address and would prevent one from being able to access one's coins at that point.  Does bitcoin still allow the "04"?  I've read, it seems, that bitcoin cash does not.

Uncompressed keys are only disallowed for segwit output types. Since segwit outputs are a completely new type of output that requires new addresses (and a new address type eventually), there won't be any effect on your current addresses and keys. Non-segwit transactions and outputs can still exist and will happen. These transactions will work  in the exact same way they do now; you won't be using segwit (and thus not allowed to use uncompressed keys) unless you explicitly go to use it.

Bitcoin Cash does not have segwit, so they are not invalidating uncompressed keys. The only part of BIP 143 that Bitcoin Cash is using is the sighashing algorithm.


Can addresses used in a single tx be assumed to be from the same wallet? can addresses of input of a single tx be always considered as belonging to same account?

Above is a sample transaction on bitcoin.
Here, input addresses are

3P2hJg8iRSBExAjd9yQGaazCLPFLeGB3hU (0.88970519 BTC - Output)
35jRUYxAwkqFhGyiGvS6Q4Aqxgcru7m9DM (0.43636859 BTC - Output)

My question is, since these two addresses are in a single tx, can they be considered as coming from same account (or wallet)?

The reason why I ask is I want to extract account-like info because bitcoin world actually has no account concept.

No, you cannot assume this.

There are a number of ways in which individual inputs may belong to different wallets/owners. For example:

They could come from a hosted wallet or exchange, where inputs may span coins deposited by thousands of individual users, and selected for a transaction with no particular relation to the user making that transaction
Coinjoin techniques allow multiple individual transactions from any number of actors to be combined into a single large transaction, mixing all of the individual inputs and outputs


My Bitcoin transaction hasn't confirmed in over 57 Hours. What can I do to speed it up? Here is the transaction 5f15aae40fad7328f8ea2986595c105d423d429e3513d8bcbb1b93934ff0c0f7

Your transaction paid a fee of 101 satoshis per byte. With the current fee market, your transaction should be confirmed in about 17 hours. You could try using a transaction accelerator but the network is pretty jammed right now.


BitInstant "Bitcoin Address" option is down! I want to cash deposit directly to my Bitcoin Address, but the option to do so has disappeared from BitInstant. Any ideas as to why? Do you think it'll ever be back?

From what I heard browsing /r/Bitcoin, it might be due to BitInstant running out of coins in their hot wallet to fulfil transactions. However, this question would be best asked to BitInstant directly.


Is there a way to know the Bitcoin Network transaction fee BEFORE actually submitting the transaction? I am using the RPC API to submit automated transactions to my Bitcond, the user introduces the Amount and I check it against its balance before submitting the transaction.

I would like to also check if the user has enough balance to pay the network fee as well.

Is there a way to know the Bitcoin Network transaction fee BEFORE actually submitting the transaction?
Is there a way I can define the network fee?

Yes.

Use createrawtransaction with the outputs you want, but no inputs.
Use fundrawtransaction to make the wallet add inputs and a change output if necessary.
Check what fee the resulting unsubmitted raw transaction has. If you like the result, continue:
Call signrawtransaction to sign the inputs.
Call sendrawtransaction to broadcast it on the network, and as a side effect, list it in the wallet.

You can't control the network fee directly (as it is per byte, and you don't know the size beforehand), but you can set the feerate using -paytxfee. In a new release, you'll also be able to pass the feerate to fundrawtransaction.


How do devs decide who should have commit access? what is the process? Andrew Chow (2020) compiled a great list on when people gained/lost commit access to Bitcoin Core.
Satoshi asked Andresen to take over as Lead Maintainer, and Andresen passed the responsibility to Van Der Laan. The Lead Maintainer appears to be selected by the previous Lead Maintainer (by convention).

Many others have received/lost commit access. How exactly is
this decision made? and by who?

If the Lead Maintainer unexpectedly died (hope not), but if he
did, who would decide upon the next Lead Maintainer and how?

Many others have received/lost commit access. How exactly is this decision made? and by who?

Nowadays the decision is generally made by the developers during one of the weekly IRC meetings. This is not done by committee nor a specific group, just whoever is attending the meeting when the topic is brought up. It's usually the same people at every meeting.
Typically how adding a maintainer works is that someone brings up a topic for adding a maintainer, others nominate a person to be that, and then the group votes. Since in the past there have really only been one person nominated at a time, it's been a yes/no vote rather than a vote for a candidate. The process is largely informal as the people nominated are typically well known developers and have been around for a while.
For revoking access, the process works pretty much in reverse. Someone brings up a topic to remove access for particular users, typically because they are inactive, and the group votes on whether to do so. There have been a few exceptions to this - Gavin Andresen's commit access was revoked after concerns that his accounts had been compromised. Since he was also inactive, it was decided to leave his commit access revoked.
Developers may also choose to no longer have commit access in which case their commit access is revoked upon asking.

If the Lead Maintainer unexpectedly died (hope not), but if he did, who would decide upon the next Lead Maintainer and how?

It would pretty much be the same process as adding a new maintainer. This is also likely the same process if the lead maintainer decided to step down. Someone would volunteer or be nominated, likely one of the current maintainers, and then that person is voted on by the group at a meeting.

In general, there is a formal process for adding or removing commit access. It's generally done by the group of developers attending an IRC meeting with those developers essentially voting yes/no.


Offchain transactions New here, but have some intermediate knowledge of Bitcoin and Blockchain. My question is in regards to the off-chain transactions.

For example, today I paid a coffee shop using my Coinbase wallet. I scanned and paid. The transaction pended for about 5 mins, then was successful. Problem is, the coffee shop didn't receive it. So I had to repay them using cash just to settle it and not give the staff an awkward moment since they didn't know what was going on as well.

I wasn't sure what Bitcoin Client or "App" they were using, but it was on an iPad.

If I paid them using coinbase wallet, does this count as a offchain transaction? If it was an offchain transaction, shouldn't it be instant? Why did it take 5 mins of pending to clear?

Also, if I did want to pay them a transaction on the blockchain, would i need a different app that isn't online wallet based? Apps such as Bitcoin Wallet App instead of Coinbase or Xapo?

Many thanks.

Coinbase will do an offline transaction depending on whether the recipient address is part of coinbase wallet. If recipient address is part of a coinbase wallet then the tx can be easily done offline, otherwise the tx has to be on bitcoin blockchain.

If you use wallets like electrum/mycelium they will always do onchain transactions.


Hybrid Bitcoin web wallet for performing multi-sig transaction on an e-commerce site Two participants in a transaction, a buyer and a seller, need to interact financially. For security, they themselves keep their private keys and sign transactions on client using JS.

I want to create a 2 in 3 multi-sig address, i.e: "3...", and have the buyer pay to this address. When a confirmation is received for the acceptance of BTC I will tell the seller to ship product. When it physically arrives to the buyer - he will approve getting the product and sign the multi-sig transaction. In case any dispute site admin will have the third private key to resolve any issue.

My question is how to implement this on my site. There are many open source JS Bitcoin libraries supporting multi-sig out there. There is copay/bitpay api, bitgo, gem.co, coinb.in outcast3k, bitvault, coin kite. Not much online about how to properly go about doing this.

The best implementation I have seen is taking place on http://www.coincola.com/

Anyone can help clearing the fog here?

Most of the libraries you mentioned would work for this problem. However, some are built more like libraries to be called from other javascript (eg. BitcoinJS), while others are designed with a full user interface so a semi-technical user can host multisig signing functionality on their browser (eg Copay). Some options you mentioned are also multisig wallet services which require you have an account with them, and they are taking care of some of  the nitty gritty of multisig (eg. BitGo). Since you are trying to build your own e-commerce site around multisig, where one key is always some key you control, you probably want a library you can call in your code, without a user interface.

Without commenting on the suitability of each and every library option, I will say that BitcoinJS can do what you need here. They provide a set of library functions that can create multisig addresses with any set of public keys and M-of-N requirements as well as signing functionality to sign those with private keys (which your buyer and seller could do on a browser hosted solution you provide or own their own).

See BitcoinJS's example for creating a 2-of-3 P2SH address, creating a transanction (to fund your multisig address) and spending from a 2-of-2 multisig address (you will need to modify to spend from a 2-of-3 address).

Bitcore by Bitpay (which Copay is built on) can also create multisig addresses and sign/create transanctions: https://github.com/bitpay/bitcore. You can use it in the browser with bower for easy setup, and their API is very well documented. You can see their example for generating a multisig address.

With all of that said, be very careful with your implementation. This is people's money and you don't want to be introducing vulnerabilities that loses people their money (or yours). If you don't feel comfortable with the security implications of your design decisions, create example demonstration versions and have them well vetted by more experienced people before bringing them into production.


Can a Mining Pool Force Changes Without Agreement from Bitcoin Core Developers? I'm trying to understand a @petertoddbtc tweet about Chinese miners making a controversial stance.
 According to the accompanying article https://www.cryptocoinsnews.com/bitcoin-market-needs-big-blocks-says-founder-btc-top-mining-pool/, the Chinese miners advocate Bitcoin Unlimited.
 Bitcoin Unlimited allows large blocks (>1MB?). In contrast, Bitcoin Core Developers
 are considering limiting to smaller blocks (300KB).

There are quotes from Zhuoer who controls 8% of total hashrate and is rallying the Chinese miners:

  Who goes against the market will be destroyed, unless he can show more money.

In regards to Luke-Jr's (Core developer) threat of hardfork, there is the reaction:

  We have prepared $100M USD to kill the small fork of CoreCoin.

Isn't change supposed to be with the agreement of all developers, miners, and consumers?
 Can the mining pool group force this change on the Core developers?
 Why is Bitcoin Unlimited so different from Core, and what makes it incompatible to Core
 in that now there is a rift between miners and the Core developers?

In contrast, Bitcoin Core Developers are considering limiting to smaller blocks (300KB).

First of all, for these kinds of changes, Bitcoin Core only merges things with very wide consensus. There was a proposal for 300kB blocks by one individual developer, which I think everyone considers to be very controversial.

Furthermore, these kinds of changes are not proposals for changing Bitcoin Core's behaviour and forking off. They're proposals for changing Bitcoin, and that's not something that is to be decided by the authors of one piece of software.

Then, on to answering your question:

The (collection of) economically relevant full nodes on the network determine the network's rules. I say economically relevant, because someone running 1000 nodes in a cluster, and have them do nothing but connect to the network and relay transactions and blocks is not going to affect anyone. I also say collection, because I'm ignoring the issue of how those nodes' operators come to an agreement.

Miners' job is to build blocks that satisfy those rules. They can choose to not do so, but their blocks will be rejected by the network if they do, and they'll lose their income from those.

However, miners can always choose to enforce extra rules on top of those demanded by the network. That's the first step towards a soft fork, but it's not enough. It's just a collusion of miners agreeing among each other to only build on top of other blocks that satisfy some extra criterion. They could even do this without telling anyone.

That is not yet a softfork, because they could just as easily agree to stop doing something like this. To make it a successful softfork, economically relevant full nodes in the network need to start enforcing the same rules at the same time. That is what makes the change lock in. Because if full nodes are in on it, miners can no longer back out - doing so would either invalidate their blocks, or cause an irreconcilable fork in the chain. BIP9 is a mechanism for allowing miners to coordinate the activation of a new feature, and having full nodes activate it simultaneously.

So in short: softforks are subject to a majority of the hashrate plus significant adoption of enforcing code on economically relevant nodes. Developers of particular software do not directly control either, but obviously do have an influence by providing the means to deploy such software.

Disclaimer: I'm a Bitcoin Core developer.


Can I create a private bitcoin network? Say if I was creating a new bitcoin website and I want to transfer some bitcoins from one of my own private wallets to another would that make it so the transaction would confirm almost instantly because it is a closed loop?

Yes you're talking about an off-chain solution. Exchanges use this solution.

It would be prohibitively expensive and impractical to transfer ownership on-chain for small amounts and/or frequent changes, so you send your coins to a single wallet owned by the exchange.

The exchange has their own system to keep track of who owns what. This system is private and not transparent, but fast and potentially free. Then when you choose to send it from the exchange to your wallet, a network fee is incurred at that point.

The off-chain solution could also be a blockchain solution, though not distributed as no one else would have any interest in maintaining your businesses ledger.

e.g. with coinbase.com

The Deposit:
Your wallet -> "your" coinbase wallet
  occurs on main net blockchain
  network fees incurred
  technically deposited into a single main net wallet
  wallet controlled by coinbase
  you trust them with your coins at this point

Interwallet transfer on coinbase:
"your" coinbase wallet -> another wallet on coinbase of "your"s
  occurs off the chain
    as such it's free
    as such is opaque
  could be implemented however coinbase sees fit:
    vb running in an excelsheet for all I know!

Withdrawal:
"your" coinbase wallet -> Your wallet
  occurs on main net blockchain
  coinbases single wallet is paying you
  network fees incurred
  grouped with other withdrawals for network fee efficiency
  coins in your full control again


What is this 18-word seed of random letters? I have a seed from a few years ago that looks like this:
this is not the actual seed, but it's random letters just like this:
nasd oasi lksn oifd nwee ckvj osdi pwer asem
pasd werw nase nwqe noas pmrr nolv psme ksdw

How can I recover the wallet?

It's an armory backup seed. See https://www.bitcoinarmory.com/. It's a wallet that requires bitcoin core full node so you'll need that as well.


Compatibility questions regarding Native Segwit addresses I have a question regarding Native Segwit addresses. I understand that those addresses are more efficient and that you save on fees when you send BTC from them. However, does it matter which type of address (legacy, segwit, Native Segwit) the recipient uses? Will I get the same fee reduction benefits no matter what?
Also, I often read that many wallets don't properly support Native Segwit addresses. My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?

Sending bitcoins means to lock funds to a specific output script. The output script determines how the funds can later be spent. E.g. if funds were sent to a P2WPKH (Pay to Witness Public Key Hash) address, they can later be spent using a P2WPKH input script. If funds were sent to a P2PKH (Pay to Public Key Hash) address, they have to be spent using a P2PKH input script instead.
The (native segwit) P2WPKH input script has less weight than the P2PKH input script, so receiving funds to P2WPKH addresses will save you fees when you later spend those funds. The output scripts for both are similar in size.

Funds of any type of input can be assigned to outputs of any type in a transaction. You can even mix: spending a native segwit and a non-segwit input, and sending to a non-segwit and a native segwit output in one transaction works fine.
However, as you say, some wallets may not support sending to native segwit addresses. In that case, the receiver should fall back to providing a backwards compatible P2SH-wrapped segwit address which is still cheaper than non-segwit but can be sent to by almost all wallets. You can track native segwit adoption on Bitcoin Optech's Compatibility Matrix or whensegwit.com.

My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?

Correct. A wallet that does not know how to interpret native segwit addresses would not be able to spend funds received from a native segwit address. This is not a problem in practice, because the receiver provides the spender with the invoice address they want to receive the funds to. The receivers wallet will not generate a native segwit address, when it is unaware of native segwit.


What's the minimum age to join or use Bitcoin? What is the minimum age a person must be to use the Bitcoin service?

There is no minimum age, my children have Bitcoins and have for years.

Service by service should implement whatever safety or age restrictions they need.

I am not aware of any work done on this front, perhaps somebody else can enlighten.


Is it necessary to mount an external hard disk to save blockchain to external hard disk on Raspberry PI? I have a Raspberry Pi 3.  I'm running bitcoind for the first time and would like to save the blockchain to an external hard disk.

When I run
bitcoind -datadir=/media/pi/FreeAgent\ GoFlex\Drive

I get the following error:

Error: Cannot obtain a lock on data directory /media/pi/FreeAgent GoFlex Drive
Bitcoin Core is probably already running. No such file or directory.

I tried stopping the process with

bitcoin-cli stop

But that didn't seem to do anything.  Is the problem that the external hard disk has to be formatted and mounted, as per instructions here?

As a test, I tried writing a file to the hard disk from the system and received the following error:

mv: inter-device move failed: 'testfile' to '/media/pi/FreeAgent GoFlex Drive/testfile'; unable to remove target: Read-only file system

This does seem to confirm this hypothesis that the disk needs to be formatted/mounted.

I get the following error:

Error: Cannot obtain a lock on data directory /media/pi/FreeAgent GoFlex Drive
Bitcoin Core is probably already running. No such file or directory.

  I tried stopping the process with

bitcoin-cli stop

Bitcoin Core is already stopped when you get that error. It can't run without the datadir.

  But that didn't seem to do anything.  Is the problem that the external
  hard disk has to be formatted and mounted, as per instructions
  [here][1]?

  As a test, I tried writing a file to the hard disk from the system and
  received the following error:

mv: inter-device move failed: 'testfile' to '/media/pi/FreeAgent GoFlex Drive/testfile'; unable to remove target: Read-only file system

  This does seem to confirm this hypothesis that the disk needs to be
  formatted/mounted.

No, it does not necessarily need to be formatted.

The problem is that your user does not have the correct permissions to write to your external drive. Make sure that your drive is writable and that your user has the permissions to write to the external drive. You may have to change how it is being mounted to the system (drives always have to be mounted in order to be accessible).


Does each miner in a bitcoin mining pool has a chance to win the block reward? Suppose there is mining pool XYZ. 10 miners 1 through 10 are subscribed to it and miners have varying hash power, some have 10 GPU mining rig while others have just a single CPU running 24 hours a day seven days a week. Suppose 12.5 BTC are won by XYZ each week.

Does it mean that each week one of those 10 miners win 12.5 BTC and XYZ then distributes BTC to each of the 10 miners in accordance with their contribution of hashing power?

OR XYZ gathers together hashing power of miners 1 to 10 to try to be the first to solve the puzzle to win 12.5 BTC ?

Is it possible for a solo miner with 10+ GPU rig to win 12.5 BTC block reward even though mining pool XYZ has much greater combined hashing power? I mean is there randomness also involved in wining block reward in addition to hashing power?

OR XYZ gathers together hashing power of miners 1 to 10 to try to be the first to solve the puzzle to win 12.5 BTC ?

XYZ assigns work to miners in its pool. The work mines blocks that pay BTC to the pool's distribution account. When a block is mined, the pool distributes from the distribution account.

  Is it possible for a solo miner with 10+ GPU rig to win 12.5 BTC block reward even though mining pool XYZ has much greater combined hashing power? I mean is there randomness also involved in wining block reward in addition to hashing power?

Yes. Everybody who is trying to mine a block has the same chance of succeeding with each hash they do. Mining a block is so hard that somebody somewhere succeeds on average once every ten minutes.


How does the client know the number of keys and coins when recovering from a seed? When I have a seed and use it to recover my keys, how does a client find out which keys I had and their respective amounts?

To clarify, I understand how a deterministic key works and that we can generate more keys from it. What I'm not sure is how the client knows how many private keys / wallets I had and the units of currency in each of them.

There is a so-called gap limit. In Electrum, it's 20 by default but can be changed. But if you changed it up, remember that! Preferably write it next to your wallet's seed.

This means that the HD wallet determines the first 20 addresses and checks on a server whether any of them have every been involved in a transaction. Let's say these addresses are numbered. Number 7 is the one with the highest number to ever have been involved in a transaction. Then, 7+20 = 27 is computed and all addresses up until and including 27 are checked. It's found that 21, 23, and 25 have been involved in transactions. Then, 25+20 = 45 is computed and all addresses up until and including 45 are checked. It's found that none of the addresses from 28 to 45 ever had activity on them. Therefore, the search is stopped because there is a cap of at least 20 addresses. If address 46 had a transaction on it, that's not discovered until the user uses the wallet enough such that that address is searched for activity or the gap limit is increased.


bitcoind API sendrawtransaction error 500 I'm getting an error 500 from my web server when I try to send a raw transaction through the RPC API.

PHP message:

PHP Warning:  fopen(://...@IP:8332/): failed to open stream: HTTP request failed!
HTTP/1.1 500 Internal Server Error
in /usr/share/nginx/html/common/jsonRPCClient.php on line 132

PHP message:

PHP Fatal error:  Uncaught exception 'Exception' with message
'Unable to connect to://bitcoinrpc:PASSWORD@IP:8332/'
in /usr/share/nginx/html/common/jsonRPCClient.php:140

Stack trace:

#0 /usr/share/nginx/html/tools/do_sendBTC.php(131):
jsonRPCClient->__call('sendrawtransact...', Array)
#1 /usr/share/nginx/html/tools/do_sendBTC.php(131):
jsonRPCClient->sendrawtransaction('010000000115d34...')
#2 {main}

This is the line that crashes:

$result = $bitcoin->sendrawtransaction($tx_data);

Every other API call works, for example validateaddress.

Any idea why this fails? The same raw transaction works if sent through the bitcoind command line.

Thanks

You cannot send one transaction twice. If you have already sent it from bitcoin commandline, then it will fail with -22(cli) or 500(http) error.

500 means incorrect data: insufficient funds, bad syntax, bad type, impossible command...

Try to cast to string: $bitcoin -> sendrawtransaction((string)$tx_data), and do var_dump($tx_data) to find the type.

If it doesn't help, send this POST request from cURL, as in tutorial: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)#Command_line_.28cURL.29


How to get sender address from transaction with JSON RPC? I'm using JSON-RPC call to connect to local bitcoin node on my clouding server.
I could get all transactions with wallet name by using gettransactions.
Now I need to get sender's address for each transaction but result contains only receivers' address.
Following is response of gettransactions request.
{
"result": [
{
"address": "bc1qd9mgd4ynryaw2kp0pzfjdxguhz9dzvs5vh0nfn",
"category": "receive",
"amount": 0.001,
"label": "",
"vout": 27,
"confirmations": 1322,
"blockhash": "000000000000000000074551080f954e790edfe6ad810ecebf4691e881175eaf",
"blockheight": 660029,
"blockindex": 106,
"blocktime": 1607147554,
"txid": "07ab59c8d3a204172887085258460d0058c20a9acdb451daa5ad4290cbd461b0",
"walletconflicts": [],
"time": 1607147511,
"timereceived": 1607147511,
"bip125-replaceable": "no"
},
{
"address": "bc1q6dh3h5e3qgku8u9s8y664844fj4fkm08n7cnwt",
"category": "receive",
"amount": 0.0011,
"label": "",
"vout": 9,
"confirmations": 1313,
"blockhash": "00000000000000000000960f4476a8552cac203eec6e0f826886b41fae402bec",
"blockheight": 660038,
"blockindex": 393,
"blocktime": 1607153799,
"txid": "af0885e4c1d10e935de525680c6c33d221ab506742b08e34a0322bba90b56fb0",
"walletconflicts": [],
"time": 1607152236,
"timereceived": 1607152236,
"bip125-replaceable": "no"
},
{
"address": "1L8ZNCibVVpPjJ8VJ1ALLuTjtctA4mzGPw",
"category": "send",
"amount": -0.001,
"vout": 0,
"fee": -0.00008536,
"confirmations": 706,
"blockhash": "0000000000000000000c3230522e267980bb990883cc0b36460ad3efc1f8fed4",
"blockheight": 660645,
"blockindex": 1049,
"blocktime": 1607529332,
"txid": "a2056e7a49bc608435713519bc038ed7da2e65f588495f36c6628f5ca6fe2d7d",
"walletconflicts": [],
"time": 1607528963,
"timereceived": 1607528963,
"bip125-replaceable": "no",
"comment": " ",
"to": "seans outpost",
"abandoned": false
},
{
"address": "1L8ZNCibVVpPjJ8VJ1ALLuTjtctA4mzGPw",
"category": "send",
"amount": -0.0005,
"vout": 1,
"fee": -0.00008536,
"confirmations": 705,
"blockhash": "0000000000000000000994e21412109847caffa2bd990884f49461d53c047055",
"blockheight": 660646,
"blockindex": 844,
"blocktime": 1607529675,
"txid": "ddbe1dce4537926b6cf5bc1e222e5cd32de224cf346ca89251c127ce32226f30",
"walletconflicts": [],
"time": 1607529401,
"timereceived": 1607529401,
"bip125-replaceable": "no",
"comment": " ",
"to": "seans outpost",
"abandoned": false
}
],
"error": null,
"id": "curltest"
}
How can I get sender's address ?

Despite how it looks on most block explorers, Bitcoin doesn't really have a concept of a "sender address", at least not on the raw transaction level. What a transaction has is inputs and what block explorers do is go look up those inputs and guess the address that was used to create those UTXOs.
You might find these related questions useful (just search this site for "sender address"):
How to findout the sender of a transaction
Sender address from DecodeRawTransaction (C#)


Multiple wallets on one browser I have several wallets on blockchain.info

My problem is that when I log in to my wallet the id of one of the wallets appears automatically and I can't type the data in of the other wallets.

How can I operate several wallets from the same browser (not simultaneously though)?

Can anyone help?

Im using Chrome but on other browsers it should be same...
Browser holds in memory some data about your last login - session, so you have to open several incognito windows(CTRL+SHIFT+N chrome) or open several browser programs, by which I mean, one chrome, one IE, one mozzila. Becose every program has its own cache... But really easiest way is to open chrome and ten incognito windows with ctrl+shift+n...

so
for every wallet go to main page of CHROME browser CTRL+SHIFT+NEW will open incognito and type there blockchain.info


Testnet can hash problem be reduced I have a question concerning setting up a testnet.
I am setting up a testnet. I tried to get some testnet coin be I did not a success.
But anyway is it possible to reduces the probability of getting a coin on a test net without recompiling the bitcoin source.
I remember in 2011 it was relatively easy to get coins for test.

Can you set a parameter in the bitcoin.conf to reduces the hash probability

Best
Carsten

You're looking for regtest. It lets you generate as many blocks as you want on a private network.


How does headers-first prevent fill-disk attack? Checkpoints prevented an attack where a node could mine many many low-difficulty blocks from an early point in the blockchain and serve those blocks to syncing nodes who would see their disks fill up. This is described in https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download#Checkpoints.

Now since checkpoints are removed, we would be vulnerable to this attack. But it is stated in (https://bitcoin.stackexchange.com/a/75735/69518) that this is prevented by the newish headers-first synchronization mechanism.

How does the headers-first synchronization prevent the fill-disk attack?

A syncing node downloads all headers from a single peer. If that peer only sends headers from its malicious low-difficulty branch, won't the syncing node try to download all those blocks, and get it's disk filled?

since checkpoints are removed, we would be vulnerable to this attack

Where did you see that checkpoints are removed?  They're still in src/chainparams.cpp as of current master (commit f8bcef38f).

  How does the headers-first synchronization prevent the fill-disk attack?

Headers-first prevents a related attack where the client would accept "orphan" blocks---block with no known parent---and store them until their parent was received.  This prevented wasted bandwidth and sped up validation in the normal case but made disk-fill attacks easier in the pathological case.

Headers first allows Bitcoin Core to discover the most proof of work block chain (headers chain) that its peers know about before downloading any blocks, which allows it to ensure any blocks it receives are on that chain.  This, in turn, means that it never needs to download or store orphan blocks.

  A syncing node downloads all headers from a single peer. If that peer only sends headers from its malicious low-difficulty branch, won't the syncing node try to download all those blocks, and get it's disk filled?

That's correct, and that's why checkpoints are still used in the code as far as I know.  My understanding is that, for the ultimate removal of checkpoints, three things were desired:

Minimum chainwork: a feature coded into a node that tells it the legitimate chain must have at least X amount of chainwork, with X being set to the value for a recent block near the time of a software release.  This replaces the original use of checkpoints in preventing network-level attackers from feeding clients long, low-PoW chains containing valid blocks but which aren't the consensus best block chain.  This was deployed in Bicoin Core 0.13.2.
Assumed Valid Blocks: a feature designed to replace the secondary use of checkpoints for (optionally) speeding up Initial Block Download (IBD) by skipping validation of signatures in old blocks.  This was deployed in Bitcoin Core 0.14
A minimum difficult soft fork: a change to directly address the block-fill (or header-fill) attack you described by raising the minimum difficulty at various epochs in the block chain to correspond roughly with the actual observed increases in difficulty.  This would make it more expensive for an attacker to feed fake blocks to a node.  To the best of my knowledge this has not yet reached the BIP stage and I'm not sure it's currently being actively championed.

For reference, this topic was discussed in the 2017-03-02 Bitcoin Core developer meeting: https://bitcoincore.org/en/meetings/2017/03/02/#discussion


Is there a reference, authoritative resource or book on Bitcoin programming? Is there any reference or authoritative resource, or book on Bitcoin programming?
Bitcoin is dubbed "programmable money" but there is no obvious resource for how to do that aside from trudging through subsections of hack-prone forums.
Altcoins many times are simply finding and replacing the word "bitcoin" in the code base and clients, so it seems even in that case their programmers have a thin understanding of various bitcoin programming paradigms.
I'm sure a "book" would be outdated by the time it was published, but regardless it would be helpful to have everything in one place for a potential target audience that doesn't want to reverse engineer commit history just to see whats going on.

I was asked by Hasan Hasan, a junior developer, which of the following three books I'd recommend. Personally I think all three books are fantastic (I would recommend them all) but they do approach the topic from very different angles.
Mastering Bitcoin (2nd edition, Andreas Antonopoulos) was the first technical Bitcoin book to be published. The 2nd edition was published in 2017 so there may be some outdated details but the vast majority should still be accurate today. It does have some chapters on concepts but not as comprehensively as Grokking Bitcoin (see later). It will provide instructions for configuring a Bitcoin Core build from the command line and contains a lot of Python code examples. It is especially strong at explaining Bitcoin scripting. For an example of Antonopoulos teaching Bitcoin Script see his 2017 presentation at SF Bitcoin Devs (video, transcript).
Programming Bitcoin (Jimmy Song) is also a technical Bitcoin book but covers different topics in depth than Mastering Bitcoin. Mastering Bitcoin mostly avoids cryptography but Programming Bitcoin has three detailed chapters on finite fields, elliptic curves and elliptic curve cryptography. If you like math or want to understand how public keys and signatures are generated in detail this is the book for you. There are also more Python code examples in Programming Bitcoin than Mastering Bitcoin. There are some conceptual explanations but generally I would say it assumes you understand most concepts covered in Mastering Bitcoin and Grokking Bitcoin (or that you best learn those concepts through code rather than written explanations.) For an example of Jimmy Song teaching ECDSA and transactions see this presentation at Bitcoin Edge Dev++ in 2017 (video).
Grokking Bitcoin (Kalle Rosenbaum) contains minimal code, instead it focuses on the various challenging concepts that you need to understand to get to grips with Bitcoin. For example, Kalle Rosenbaum presented  how SegWit works at London Bitcoin Devs in 2020 using the content from Grokking Bitcoin (video, transcript). If you are having trouble understanding a concept I'd recommend that book as some of the diagrams, explanations and exercises are really useful. It is easy to discount this book as being the less technical of the three but if you are already a junior developer you may have more trouble with concepts than command line and code. It is a technical yet accessible book.
They are all open source so you can try before you buy. Mastering Bitcoin is here, Programming Bitcoin is here and Grokking Bitcoin is here with a special build of the book including diagrams here.
If you like them and can afford to buy them I encourage you to support the authors and publishers by purchasing them. Whether the authors publish future editions of the book or continue to produce these kind of educational resources depends on how successful the books are. In Grokking Bitcoin's case you can buy directly from the Manning publisher here but all are available from Amazon or your usual book seller.


Difference between Sign Message and Sign Transaction Using "Sign Message" one can prove ownership of an address.
This happens by signing a human-readable string using the private key belonging to the address.
The owner then provides the address, message and signature, and anyone can verify that they indeed hold the private key of the address.
The ECDSA signature is normally provided in 65-byte format (Recovery byte + 32-byte R + 32-byte S) and base64 encoded.

However, there is also another type of signature, which is used for "Sign Transaction".
For each input of a transaction, there is some data to be signed. This data is binary data, normally provided in hex format.
The corresponding signature is provided in 70-, 71-, or 72-byte DER format.

In both cases, the message (message string in the first case, and binary per-input data in the second case) is transformed into a byte array, and the private key is used to generate an ECDSA signature for that message byte array.
The output format is different, but the 65-byte format can easily be converted into DER.

Consequently, I thought that I could just use "Sign Message" (with a minor modification, so that it takes a hex string instead of an ASCII/UTF-8 string) to sign a transaction's hex-encoded binary per-input data.
I did that, converted the signature to DER format and tried to send the transaction, but it didn't work, because the signature was wrong.

So my question is, what is the difference between how "Sign Message" and "Sign Transaction" generate signatures, and why aren't they compatible?

Is the difference that for "Sign Message", first a digest is created, which is then signed, while for "Sign Transaction" (in the meaning written above), the input is already a digest, so it shouldn't be hashed again?

Thank you!

Is the difference that for "Sign Message", first a digest is created, which is then signed, while for "Sign Transaction" (in the meaning written above), the input is already a digest, so it shouldn't be hashed again?

No. It has nothing to do with the hashing. Furthermore, the input is not already a digest, it must be hashed before signing. Both the message and the input data are hashed twice with SHA256.

The difference between message signing and transaction input signing is that message signing prepends the string Bitcoin Signed Message:\n (with \n being a newline character, not literally \n) to the message before it is hashed.

Additionally, the 65 byte signature produced by message signing has a byte at the beginning that is not part of the cryptographic signature itself. Instead it is a recovery id so that the correct public key can be recovered from the signature during signed message verification. In transaction signatures, there is a different byte appended to the end of the signature which is the sighash type, usually it is the byte 0x01.


Can I sell my BTC and still claim my BCH? I held a small amount of BTC back in August (had them since 2014) but now wish to sell them. Do I need to claim my BCH before selling my BTC or am I correct in thinking that the two completely independent and selling one will have zero affect on the my ability to either claim or sell the other?

Because you owned Bitcoin (BTC) at the time of the fork, you also own Bitcoin Cash (BCH) with exactly the same addresses and private keys.

You need to:

Export the private keys from your BTC wallet.
Download and install a wallet that supports BCH. I recommend Coinomi via Bluestacks. It runs about 100 different alt coins side by side with your BTC and has exchange integration via Changelly and Shapeshift. (I have no affiliation with these services).
Sweep the private keys exported from your BTC wallet into your BCH wallet.
Consider sweeping those same BTC private keys to a new BTC address. There was some issue at the time of the fork with transaction replay (you transact on one coin and someone dupes the other to steal from you).

It's pretty easy, just keep track of what coin you're working with. A lot of people have sent their BTC to a BCH address they don't control. Then they lost their coin.

But wait, there's more

BTC was forked again in November into Bitcoin Gold (BTG). It's currently trading at $250. Do the same process with this new fork and claim even more coin.


How to import an existing extended private key to bcoin? I´m searching for a way to import an existing extended private key, exported from electrum, into a bcoin node. Reading https://bcoin.io/api-docs/ I can´t find a description to do this.

Am I missing a part or does someone have a solution for this?

What exactly do you have from Electrum? Is it an xprv... ?

What you need to do is create a wallet and assign the master private key:

https://bcoin.io/api-docs/#create-a-wallet

bwallet-cli mkwallet --id=WALLETNAME --master=xprv...

Note that Electrum's address derivation scheme may not match bcoin's exactly (since bip32/bip44 don't provide metadata like address type). Therefore you may also need to include the flag --witness=true which will derive bech32 addresses along the bip44 path. If Electrum is using bip49 or bip84 derivation schemes, you will have to run a modified branch of bcoin to recover the same addresses.

If you want to chat about this the developers are usually available on slack or IRC #bcoin


Is it possible to bruteforce the seed? Is it true that the "seed words" bruteforce more reliable for to get profit than searching of a "random number" for to open some profitable outputs?

The last one is impossible due to math, but the first one?

No, it is not true. Both are impossible due to math. The mnemonic is just an encoding of a number that is randomly generated (i.e. just like a private key) so it has the same security properties of that 256-bit number.

If you ignore that it encodes a number, consider this: a seed phrase encoding a 256-bit number needs 24 words in the mnemonic. There are 2048 possible words which means that there are 2048^24 = 2.964... × 10^79 possible mnemonics. There are 2^256 = 1.157... × 10^77 possible 256-bit numbers. There are actually more possible mnemonics than there are values to be encoded in the mnemonic. Thus the mnemonics are just as secure as a randomly generated private key (256-bit number) itself.