Flexible Transactions; first code published.

[Tom Zander]

I've blogged before about Flexible Transactions as a simpler codebase that could solve the problems that BlockStream has been trying to make SegWit solve. With new issues being found in SegWit even though its now already 5 months over date and more than a year in development, I think its time to take Plan B more seriously.

So this week I started work on Flexible Transactions and I managed to implement the loading and saving of such transactions in Bitcoin Classic. See; https://github.com/bitcoinclassic/bitcoinclassic/pull/186

There are various other steps to make in order to come out with a shippable solution, but this is a large first step that should help tremendously in continuing work. And naturally to show that work is actually happening on the Flexible Transactions hard fork.

Tl;Dr. A simple more clean and future-ready solution for many future Bitcoin problems, including the malleability issue, is being written as an alternative to SegWit. Because its good to have choice.

 

[satoshis_sockpuppet]

I have to admit, I'm a bit lost in Bitcoin atm. I think I understood the "first" Bitcoin version okish, today I have the feeling, that for every two steps in understanding I have to take one step back. So my assessments of the technical "details" aren't very sophisticated.

But from a general engineering standpoint, your solution seems to be very clean and "straight-forward", which I think is about the most important factor.

Slightly OT:
Do you really see a chance for your solution? I find it very, very hard to believe, that Core won't force SegWit with all means necessary. Their "lives" (as core devs, don't take it literally ) depend on SW now imho.

Anyway, keep up the good work. (Including the understandable descriptions. It's the same for Bitcoin Unlimited, I think it's great, that you take your time to explain the stuff to the "regular folk" besides the actual coding)

P.S.: If you just want technical discussion and no meta discussion here, please delete the comment.

 

[Tom Zander]

> I find it very, very hard to believe, that Core won't force SegWit with all means necessary.

In the end its about you and me running and supporting the code we believe in. So you can make a chance. Run Bitcoin Classic!

Try out nightly updated PPA to test, for instance (excludes wallet) our https://launchpad.net/~bitcoinclassic/+archive/ubuntu/nightly

 

[satoshis_sockpuppet]

Try out nightly updated PPA to test, for instance (excludes wallet) our https://launchpad.net/~bitcoinclassic/+archive/ubuntu/nightly

Didn't know you made an PPA for Classic!

 

[solex]

@Tom Zander
Awesome work on flexible transactions (FT). I agree that your whole approach is better than the highly constrained and complex path which SW is treading.
Although Satoshi put in the txn version field which implies future hard-forks, I do not think that HFs will ever become easy events, and we might have to accept the reality that the HF to dump the 1MB might be the only one to ever happen. So, is it feasible to have the FT code advanced, tested and bullet-proof enough so that it could be included in the next HF and be sufficient long-term even if it proves impossible to get another HF done later?

 

[Justus Ranvier]

FT and the block size hard fork should happen at the same time. Switching to a new block format means the small block chain can't ever reorg the large block chain, and so that fork could happen at any hash rate distribution.

 

[HelloGuy]

@Tom Zander
Awesome work on flexible transactions (FT). I agree that your whole approach is better than the highly constrained and complex path which SW is treading.
Although Satoshi put in the txn version field which implies future hard-forks, I do not think that HFs will ever become easy events, and we might have to accept the reality that the HF to dump the 1MB might be the only one to ever happen. So, is it feasible to have the FT code advanced, tested and bullet-proof enough so that it could be included in the next HF and be sufficient long-term even if it proves impossible to get another HF done later?

I think all the non-Core camp developers should spend some time on the Flexible Transactions, and help Tom to work out a good hard fork plan. More people reviewing the code, the less chance to have bug.

 

[Tom Zander]

Good idea @HelloGuy, so far no help yet. Volunteers know where to find me (thats slack, email, reddit, irc, etc. Anything friendly to vpn/tor, so not this site).

 

[Mengerian]

I'm trying to wrap my head around the block structure, in particular how the data is arranged into Merkle trees.

If the transaction ID is calculated without including the signature, then presumably this means that the Merkle tree of transaction IDs does not include signature hashes. Is this correct?

Or are the signature hashes included as separate leaf nodes in the Merkle tree, or in a separate Merkle tree?

I am trying to think through how one could construct a proof that transactions in blocks either have, or don't have, valid signature associated with them. The fact that ECDSA signatures are maleable seems to make invalid signature fraud proofs more difficult.

 

[Tom Zander]

@Mengerian good question
see https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md#block-malleability

----
The effect of leaving the signatures out of the calculation of the transaction-id implies that the signatures are also not used for the calculation of the merkle tree. This means that changes in signatures would not be detectable. Except naturally by the fact that missing or broken signatures breaks full validation. But it is important to detect modifications to such signatures outside of validating all transactions.

For this reason the merkle tree is extended to include (append) the hash of the v4 transactions. The markle tree will continue to have all the transactions' tx-ids but appended to that are the v4 hahes that include the signatures as well. Specifically the hash is taken over a data-blob that is build up from:

1. the tx-id
2. the CMF-tokens 'TxInScript'