SegWit versus Bitcoin Unlimited

In the operation of Bitcoin, there is a crisis brewing. Bitcoin mining pools are restricted by a feedback-control loop which they defined, in the days of the inception of Bitcoin, only to be able to “mine” 1 Block every 10 minutes, which is inserted into the block-chain when that has been achieved, and which acts as a slate, onto which all Bitcoin transactions must be recorded. A block currently occupies 1MB of data, and the size of individual transactions to be recorded in it, can vary greatly, but averages 500 Bytes for the simplest types of transactions.

What this means, is that 1 Block can typically hold 2000 transactions, but will only be mined every 600 seconds, on the average, so that a global rate of available transactions of 3 /second would seem to follow. Because the world that uses Bitcoin is presently trying to conduct transactions at a faster pace – because in some parts of the world, Bitcoin is a currency – there have sometimes been escalations in the transaction fees, which are charged according to how many KB of one block the transaction consumes. Recently, the transaction fees were around 2 milliBits/kB, or 0.002 BTC/kB. That counts as extremely expensive, since 1 BTC is approximately worth CAD 2000 right now, meaning that the transaction fee could be around CAD 1.- . Many items and services people might want to buy, would not cost much more than the CAD 1.- of my country’s real currency.

Bitcoin operators recognize that a problem exists, and there exist two camps who are in conflict right now, over what to do about it:

  1. Bitcoin Unlimited
  2. Bitcoin Core

Out of these two groups, Bitcoin Core represents the status quo.

What Bitcoin Unlimited is proposing, sounds straightforward: Increase the block-size, and allow for it to be increased again, as the demand for transactions increases in the future. But there are some problems with what Bitcoin Unlimited is proposing. Changing the format of the blocks, and/or the protocol, would essentially create two types of currencies:

  • The legacy currency, which might be referred to as BTC -units, and
  • A new form of Bitcoins, which might be referred to as XBT -units.

If one mining pool was unilaterally to adopt a new Bitcoin block-format, this would be called a ‘Hard Fork’. In the event of a hard fork, people who held Bitcoin-amounts on the legacy block-chain, would see that that legacy block-chain has been imported into both newly-forming block-chains. Wallet-holders would therefore see, that they have a double-dipping; they’d have their present amounts both as BTC and as XBT. But, if they were to mix their Bitcoins into a new block, using a type of transaction that has more than one input, those Bitcoin-amounts would become invalid on the other, newly-differing chain.

There would be a bigger problem in the event of a hard fork, which is known as the risk of a Replay Attack. Because the legacy chain was not designed with the possibility of two future continuations in mind, after a hard fork, if a wallet-holder was to pay for a service in, say, XBT, then the payee – or somebody else – would be able to use the credentials the wallet-holder used in his own transactions, which worked for XBT, and could replay those transactions – actually signing the same inputs as before surreptitiously – but this time, pay out the amounts to another public address, as a BTC -amount. So the payer would see both his XBT and his BTC coins disappear, while only having authorized one of the two transactions himself, out of the legacy-chain.

As an alternative to a hard fork, Bitcoin Core is proposing a short-term solution named “SegWit”. This is a proposed solution, that will cause fewer bytes of data to be written to the block, per transaction, and which it is hoped, will allow the increased number of transactions to be served, that the world is asking for right this instant.

This is a video, which describes in storybook-form, what SegWit proposes. Essentially, a Bitcoin transaction possesses a list of inputs, and a list of outputs. No public address really owns the transaction, but the transaction proposes to use unspent outputs, made to the person who holds the private key, for the public key the outputs were made to – that constitute his Bitcoin balance – as an input or as inputs, and to state somebody else’s public address as the recipient of the outputs.

What Bitcoin experts know, is that the inputs-list of a transaction takes up much more space, on average, than the outputs list does. The reason for this, is the fact that in order to specify an input, Bitcoin is so restrictive, that one specific output must be identified, and not just one public address, to which the output was received. This means, that the complete Transaction ID must be stated in the inputs-list, as well as the sequence-number, the position of the output received, in the outputs-list, of the specified transaction, so that the current wallet-holder can use it as an input. This is expensive in the number of bytes used, because in addition to that, the public key of the recipient must be embedded in the inputs-list, as well as the signature with which the holder of the public address authorized the received output be unlocked.

  1. Transaction ID : 32 + 4 Bytes
  2. Sequence Number : 4 Bytes
  3. Public Key : 33 or 65 Bytes
  4. Signature : ~72 Bytes
  5. Additional Bytes used for script-instructions: (?)

But there is an added twist to how Bitcoin works. We might expect that this information is simply entered by software, into fields that belong to a transaction with a specific syntax. But as it stands, only the fields (1) and (2) above exist statically in a transaction. The rest is embedded as literal constants, in a very scaled-down forth-like language called “Script“.

The way script works in general, is that the piece of script in the inputs-list of the recipient, is executed before the piece of script in the outputs-list of the sender. The script of the output defines the conditions that need to be met, in order for the recipient – in another transaction than the transaction that states this script as an output – to be able to claim the amount. In order to satisfy those conditions, the script of the recipient – in his inputs-list – leaves a number of objects on a stack, which the script in the outputs-list of the sender can use as input.

According to the way Bitcoin has traditionally worked then, was that the input defined by the recipient, would place his public-key, and his signature onto the stack, in expectation that this is what the output of the sender requires. The input does this in the form of an embedded public key, and an embedded signature, in its actual script, which were placed there by software running normally on computers, and not running through script.

But the output script of the sender would then expect these data to be on the stack in a predefined order, and would verify that two conditions were met:

  1. When hashed, the public-key must equal the public address of the intended recipient (Those are not really the same thing), ( :1 )
  2. The signature must be decrypted by the same public key, to equal a hash of the transaction being claimed as input.

In order for the outputs-script to verify this, it must also receive the Transaction ID of the transaction it belongs to on the stack, but this is not the responsibility of the inputs-script of the recipient to place there.

What SegWit proposes, is that the inputs-script should neither need to state the public key of the recipient anymore, nor his actual signature, thus making the transaction shorter. Thereby, something needs to signal, that this public key should be taken ‘from the side’, from the “Extended Block”, but fed to an established output script.

While this is all very fascinating, it reveals two very serious problems of its own:

Continue reading SegWit versus Bitcoin Unlimited

Bitcoin: Transaction with Multiple Inputs – Example

  • There exists a fact about Bitcoin, which states that each received output can only be claimed by one input.
  • Some people might infer from that – that each transaction could only have one input.

But in reality, the second assumption does not follow from the first. If it did, then the inputs and outputs would perpetually have to become smaller, and in addition, it would be possible to prove that any Bitcoin-amount originated, literally, from one Bitcoin.

In reality, a transaction is possible which has multiple inputs, and two outputs. Each of its inputs has uniquely claimed a received output – without contradicting the first premise above.

(Edit 07/13/2017 : Therefore, none of those outputs can be used again. )

Now, one way I could try to prove this, would be to put together a transaction in my own wallet-program, which clearly displays the inputs-list, as well as the outputs-list, and then to take a screen-shot. But there would be two problems with that sort of ~proof~ :

  1. Somebody could think, that this is just a high-level, GUI operation, which my wallet-software is breaking down into smaller raw-data-operations.
  2. Showing such a screen-shot would also reveal (x+2) of my public keys, where (x) would be the number of inputs I have dialed up, just to take my screen-shot.

But, there is no real need for me to use my own transactions. I can just link to a transaction on ‘’, which belonged to ‘some other person’, who received 31 inputs in one transaction, yielded one main output, and yielded one change-address-output (for them). This transaction has one ‘Tx ID':

Therefore, this is one transaction, at the raw, data-level. It just happens to be atypical.



Bitcoin: Understanding the Block Reward

The subject often gets stated rather loosely, that Bitcoin miners mine Bitcoins. In reality, they mine blocks.

To understand the difference, one needs to understand a basic principle in accounting. If the only types of transaction that exists were such, that the amount of funds need to be withdrawn from one account, before they can be forwarded to another account, then the sum total of the balances of the accounts could never change. And when Bitcoin was starting up, there were initially zero Bitcoins in existence.

But with Bitcoin there exists another type of transaction, which forwards an amount to a mining pool, as a reward for the fact that they have solved the hash-difficulty associated with mining one block. This amount is also referred to as the “block reward”, is not taken from an existing balance, and is capped according to a consensus that surrounds Bitcoin, and that is shared by all the mining pools. I don’t know how many Bitcoins constituted the original block reward, but as I’m writing this, the block reward equals 12 Bitcoins.

Every 210,000 blocks, this reward gets halved, and in such a way that it gets rounded down to the nearest Bitcoin. The last time the reward was halved was in the year 2016, just before which it was at 25 Bitcoins, and the next time will be in the year 2020. Hence, in 2020 the reward will be reduced to 6 Bitcoins.

But this block reward serves more of a purpose, than just to act as a reward to the mining pool, for having solved the hash-problem of one block successfully. It also determines the sum-total of Bitcoins in existence. The mining pool is expected to spend at least some of this amount, thereby forwarding it to other parties in the network, and  causing a positive amount of Bitcoins to exist between wallet-holders.

Therefore, when miners mine blocks, they are also mining Bitcoins.

But as I wrote above, in 2020 the reward will go down to 6, in 2024 it will go down to 3, in 2028 it will go down to 1, and in 2032, the block reward will go down to zero ! And so the question can exist, as to whether Bitcoin will stop working for that reason. And the answer would be No.

In addition to collecting a block reward for mining 1 block, it needs to be remembered that each block potentially records thousands of regular transactions, initiated by wallet-holders, and that miners collect transaction fees for these transactions.

Since the current block-size today is limited to 1MB, and since a so-called typical transaction only takes up 500 Bytes, it could be said that 1 Block can record up to 2000 of these transactions. Since the transaction fee today is approximately 2 millibits per kB, this means that in addition to the block reward, the miners could be receiving up to 2 Bitcoins per block in transaction fees.

Once the block reward has gone down to zero, the assumption everybody is making today is, that miners will continue to mine blocks, but only collect transaction fees. Further, these transaction fees are taken from the holdings of the people who initiated the transactions, but with the expectation that mining pools will also spend them again. This means that by default, the transaction fees will not get sucked out of the system. Those will continue to operate, on the premise that the total amount of Bitcoins in existence will not change.

And so in theory, wallet-holders should still be able to send each other Bitcoin-amounts. Ultimately, it’s difficult for anybody today to know with certainty, what the realities of the year 2032 will be. The entire technological landscape could be very different from what it is today, or it could be disappointingly similar. We don’t know.

Continue reading Bitcoin: Understanding the Block Reward

RBF versus CPFP

One subject which I wanted to give a counterpoint-opinion about, is the fact that transaction fees are rather high right now, on Bitcoin. When I recently transferred a Bitcoin-amount from one of my wallets to another wallet I hold myself, the transaction fee was ‘only’ 0.33 millibit. Because the fees were floating near 2 millibits /kB, this also suggests that this one transaction only took about 165 Bytes of one mined block to confirm. It’s written that more-typical transactions actually require 500 Bytes, which means that those would also cost ~1 millibit. A possible way to exaggerate this could be, to write that that one transaction only cost me

0.00033 Bitcoins

of my own money. But the problem with this representation of the fee is, that it also corresponded to roughly CAD 1.- of our country’s real money. This is close to what the transactions directly from an ATM cost, and so we would not be willing to pay for a cup of coffee under these terms.

There exist some people who have funds stranded in some accounts, either because their fees were not high enough, or because they may have just forgotten that fees are necessary, to see transactions through.

There is a URL which covers two possible ways in which such funds can be recovered:

The two suggested methods are also abbreviated ‘RBF’ and ‘CPFP’. I feel that there is a detail which the above thread fails to point out:

The only Bitcoin nodes which I am presently aware of, that offer RBF, are the Bitcoin Core nodes. And the only mining pool which I am presently aware of, that openly offers CPFP, is named “Eliguis”.

Neither of these resources will offer wallet-holders the means to bypass the need to pay fees. And one of them – Eligius – was not accepting direct connections from a wallet, the last time I checked. Therefore the only way I know of, actually to invoke CPFP, is to use whatever facility our wallet-programs have to create a transaction and sign it – but not broadcast that transaction – and then to save that transaction to a file, and finally to copy and paste the transaction into the box provided by this URL:

And then, Hope Eligius accepts and mines the transaction. In order for this mining pool to do so, the Transaction Fee which the transaction-being-pushed offers, must be high enough to cover all the transactions people are requesting to have recovered, including possibly the Transaction Fee itself, as one additional transaction.

So as it stands, Bitcoin is far from being a perfect world, and one development which I hope for, would be slightly lower Transaction Fees in the near future. One development which I cannot hope for, is shorter confirmation times. And this is because across the Bitcoin network, the total number of blocks being mined is 1 / 10 minutes, and then the question remains a toss-up, whether whichever mining pool we have chosen, will be the next mining pool to solve their hash, and thus to write our transaction into the block-chain. Confirmation times of 10 minutes remain unrealistic to hope for, even if the block-size is increased.

Continue reading RBF versus CPFP