BIP 134: Flexible Transactions

zander commented at 9:16 am on September 23, 2016: contributor

Introducing Flextrans. Requesting a BIP number assignment. Thank you!

Adding Flexible Transactions proposal. 605cb29934

Assign BIP 134: Flexible Transactions b3654088cc

luke-jr renamed this:
~~Adding Flexible Transactions proposal.~~
BIP 134: Flexible Transactions
on Sep 23, 2016

luke-jr added the label New BIP on Sep 23, 2016

luke-jr merged this on Sep 23, 2016

luke-jr closed this on Sep 23, 2016

petertodd commented at 7:15 pm on September 23, 2016: contributor

Wait, did you notice the license on this? That’s not a free software compatible license due to the clause “Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.” and even more worryingly: “Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.”

In general, we probably should require authors to use a specific license to keep things simpler.

This needs to be reverted and/or fixed.

MarcoFalke commented at 8:43 pm on September 23, 2016: member

(slightly OT) BIP1 requires all BIPs to be either licensed according to the OPL or be placed in the public domain. Both are a bad choice in my opinion and even though BIP1 does not forbid dual-licensing the work, I’d very much prefer to explicitly have a wider choice of accepted licenses. I had some hope that BIP2 (#350) solves this, but unfortunately it was deferred.

petertodd commented at 8:52 pm on September 23, 2016: contributor

@MarcoFalke Yeah, I can’t imagine Amir Taaki meant for the non-free, restrictive versions of the OPL to be used; with this BIP’s licensing terms it wouldn’t be possible for, say, Andreas to include it in the next book on the Bitcoin protocol that he writes. Nor would it be possible for a future version of Flexible Transactions to do the obvious thing and include/modify the text of this BIP without first obtaining the author’s explicit permission.

For standards that need to be distributed widely, public domain (or equivalent) is much more appropriate.

luke-jr commented at 10:45 pm on September 23, 2016: member

I did notice the license, but it follows the rules in BIP 1 and doesn’t legally impede the publication in the BIPs repository.

BIP 2 was held back by objections to the BIP Comments changes. I suppose I could try removing that and reopen it for discussion. Perhaps I ought to forbid the additional OPL restrictions in the process…

luke-jr commented at 10:46 pm on September 23, 2016: member

@zander Would you be okay with removing these restrictions from the BIP? Would you object to BIP 2 if it forbade such restrictions in the future?

in bip-0134.mediawiki: in b3654088cc

64+a transaction.
65+
66+CMF tokens are triplets of name, format (like PositiveInteger) and value.
67+Names in this scope are defined much like an enumeration where the actual
68+integer value (id, below) is equally important to the written name.
69+If any token found that is not covered in the next table will make the

hoffmabc commented at 11:21 pm on September 23, 2016:

If any token found that is not covered in the next table it will make the …

hoffmabc commented at 11:21 pm on September 23, 2016:

Missing the word ‘it’.

in bip-0134.mediawiki: in b3654088cc

79+|-
80+|TxPrevIndex   ||  2 ||Integer  ||      0       ||Index in prev tx we are spending (applied to previous TxInPrevHash)
81+|-
82+|TxInScript    ||  3 ||ByteArray||  Required    ||The 'input' part of the script
83+|-
84+|TxOutValue    ||  4 ||Integer  ||  Required    ||Amount of satoshi to transfer

hoffmabc commented at 11:23 pm on September 23, 2016:

Satoshi -> satoshis

in bip-0134.mediawiki: in b3654088cc

162+version it would be placed in the outputs segment.
163+
164+=== Script v2 ===
165+
166+The default value of ScriptVersion is number 2, as opposed to the version 1
167+of script that the is in use today.  The version 2 is mostly identical

hoffmabc commented at 11:26 pm on September 23, 2016:

Remove extraneous the.

in bip-0134.mediawiki: in b3654088cc

182+broken signatures breaks full validation. But it is important to detect
183+modifications to such signatures outside of validating all transactions.
184+
185+For this reason the merkle tree is extended to include (append) the hash of
186+the v4 transactions. The markle tree will continue to have all the
187+transactions' tx-ids but appended to that are the v4 hahes that include the

hoffmabc commented at 11:28 pm on September 23, 2016:

Hahes -> hashes

in bip-0134.mediawiki: in b3654088cc

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

hoffmabc commented at 11:28 pm on September 23, 2016:

Built not build.

in bip-0134.mediawiki: in b3654088cc

213+
214+SPV (simple payment validation) wallets need to be updated to receive or
215+create the new transaction type.
216+
217+This BIP introduces a new transaction format without changing or
218+deprecating the existing one or any of its practices. Therefor it is

hoffmabc commented at 11:29 pm on September 23, 2016:

Therefore misspelling.

hoffmabc commented at 11:31 pm on September 23, 2016: none

Very minor spelling/grammatical borks.

zander commented at 9:26 am on September 24, 2016: contributor

On Friday, 23 September 2016 15:46:09 CEST Luke-Jr wrote:

@zander Would you be okay with removing these restrictions from the BIP? Would you object to BIP 2 if it forbade such restrictions in the future?

My suggestion would be that we replace OPL as an allowed license with one or two Creative Commons licenses. Following the suggestion from the OPL creators themselves. According to Wikipedia;

Open Publication License was created by the Open Content Project in 1999 as public copyright license for documents.[1] The license was superseded in 2003/2007 by the Creative commons licenses.[2]

I’d suggest saying that “Share alike” is required and “Attribution” is optional.

Executive summary; give the user the choice (next to public domain) between CCO and BY-SA see; https://en.wikipedia.org/wiki/Creative_Commons_license#Seven_regularly_used_licenses

I would gladly change to one of those two licenses.

luke-jr commented at 9:41 am on September 24, 2016: member

What I do right now is dual-license under the OPL and the 2-clause BSD license. You could also do OPL + some CC license immediately.

In the near future, I’m proposing BIP 2 replace BIP 1. It allows both CC0 and CC-BY-SA as license options for BIPs. I would appreciate if you could help review it. :)

cpacia commented at 10:40 pm on October 17, 2016: none

Regarding the spec.. it looks like a tag needs to be defined for Sequence (for RBF purposes). Probably only one per tx instead of per input?

Also, it’s unclear how standard nLockTime would be handled. I assume LockByTime and LockByBlock are intended to be used for relative locktime (as they reference bip 68). They could also be treated as standard locktime if they are put in the additional part of the transaction. Otherwise a separate nLockTime tag should probably be defined.

And in regards to LockByTime and LockByBlock when used for relative locktime they should probably be added to the input sections no? For example:

Inputs = TxInPrevHash, TxInPrevIndex, LockByTime or LockByBlock. Similar to how TxInPrevIndex is set to zero if omitted, LockByTime and LockByBlock should also be treated as having a zero value if omitted.

My 2¢

zander commented at 11:11 pm on October 18, 2016: contributor

And in regards to LockByTime and LockByBlock when used for relative locktime they should probably be added to the input sections no?

The reason that the BIP68 data was added to the inputs was only because that was the only place in the transaction where there was space to use. Inputs are about using a former transactions output. The user of the output would not be the one that specifies how long that output has to be locked. You don’t specify the rules of spending months after it confirms on the blockchain.

cpacia commented at 0:53 am on October 19, 2016: none

The user of the output would not be the one that specifies how long that output has to be locked. You don’t specify the rules of spending months after it confirms on the blockchain.

When combined with CSV I believe it works that way.

BIP 134: Flexible Transactions #445