Flexible Transactions; first code published.

Tom Zander

Active Member
Jun 2, 2016
208
455
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

Active Member
Feb 22, 2016
776
3,312
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 :p ) 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. :p
 

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,694
@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?
 

HelloGuy

Member
Mar 16, 2016
42
20
@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.
 
  • Like
Reactions: AdrianX and solex

Tom Zander

Active Member
Jun 2, 2016
208
455
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).
 
  • Like
Reactions: AdrianX

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
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

Active Member
Jun 2, 2016
208
455
@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'
 
  • Like
Reactions: Mengerian