diff options
| author | Luke Dashjr <luke@dashjr.org> | 2016-09-20 21:31:47 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-09-20 21:32:44 +0000 |
| commit | 45e859ba9dba42d5cd690c8338e9003b840f6bb5 (patch) | |
| tree | 47da49029d2d569d3726d2043dd7789f9a3839cd | |
| parent | 9d74b593ce85b228ca40ef2628e9903d80edb356 (diff) | |
| download | pi-bitcoindev-45e859ba9dba42d5cd690c8338e9003b840f6bb5.tar.gz pi-bitcoindev-45e859ba9dba42d5cd690c8338e9003b840f6bb5.zip | |
Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
| -rw-r--r-- | 0b/3865e875a90a78ffae524ed6fed9f1d45ad212 | 137 |
1 files changed, 137 insertions, 0 deletions
diff --git a/0b/3865e875a90a78ffae524ed6fed9f1d45ad212 b/0b/3865e875a90a78ffae524ed6fed9f1d45ad212 new file mode 100644 index 000000000..e98aceb4d --- /dev/null +++ b/0b/3865e875a90a78ffae524ed6fed9f1d45ad212 @@ -0,0 +1,137 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 85F3389F + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 20 Sep 2016 21:32:44 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (unknown [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0B5AD1BD + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 20 Sep 2016 21:32:43 +0000 (UTC) +Received: from ishibashi.localnet (unknown + [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id 0E72A38AB7F6; + Tue, 20 Sep 2016 21:31:51 +0000 (UTC) +X-Hashcash: 1:25:160920:bitcoin-dev@lists.linuxfoundation.org::ioIbQ6sQV19TyKtS:hb0sK +X-Hashcash: 1:25:160920:tomz@freedommail.ch::eq3+HKtKj6j8KNVz:CIPX +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org, + Tom <tomz@freedommail.ch> +Date: Tue, 20 Sep 2016 21:31:47 +0000 +User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; ) +References: <7844645.RLYLWYmWtM@garp> +In-Reply-To: <7844645.RLYLWYmWtM@garp> +X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F +X-PGP-Key-ID: BD02942421F4889F +X-PGP-Keyserver: hkp://pgp.mit.edu +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +Message-Id: <201609202131.49881.luke@dashjr.org> +X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC + autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions. +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 20 Sep 2016 21:32:44 -0000 + +On Tuesday, September 20, 2016 5:15:45 PM Tom via bitcoin-dev wrote: +> As the title suggests, I would like to formally request the assignment of a +> BIP number for my FT spec. + +Please open a pull request on the bitcoin/bips repo after this has been +discussed a bit on the ML. + +Note that at least a basic backwards compatibility section is required for +assignment, especially since this appears to be a hard-fork proposal (if it is +meant as a soft-fork, please explain how that would work). + +> ==Motivation== +> +> Token based file-formats are not new, systems like XML and HTMl use a +> similar system to allow future growth and they have been quite successful +> for decades in part because of this property. + +There is already a binary-safe format called EBML. Why not use that as the +basis for this BIP? + +> Next to that this protocol upgrade will re-order the data-fields which +> allows us to cleanly fix the malleability issue which means that future +> technologies like Lightning Network will depend on this BIP being deployed. + +Note this won't fix malleability entirely, only third-party malleability (much +like segwit). The sender can always modify the transaction with more +inputs/outputs. + +> |TxEnd || 0 ||BoolTrue || Required ||A marker that is the last +> byte in the txid calculation + +The last byte in the txid calculation, or the last byte of the entire +transaction? + +It seems from the later comments, that it is the end of the transaction as a +whole. Yet a separator between the txid and non-txid data would probably be +valuable, rather than hard-coding txid to skip signature types (which may be +unknown to old nodes, when extended). + +> The OP_CHECKSIG is the most well known and, as its name implies, it +> validates a signature. +> In the new version of 'script' (version 2) the data that is signed is +> changed to be equivalent to the transaction-id. This is a massive +> simplification and also the only change between version 1 and version 2 of +> script. + +This seems to be a major regression. What is the replacement for +SIGHASH_SINGLE and SIGHASH_ANYONECANPAY? + +When revising OP_CHECKSIG, it would also be nice to add the ability to use +*only* a hash of the prevout's scriptPubKey in the input, so that *when* the +prevtx is malleated, the spending one remains valid. (This use case is +currently not supported.) + +> === Serialization order=== +> +> The tokens defined above have to be serialized in a certain order for the +> transaction to be well-formatted. Not serializing transactions in the +> order specified would allow multiple interpretations of the data which +> can't be allowed. + +What happens if nodes encounter a different order in a block? + +> Notice that the token ScriptVersion is currently not allowed because we +> don't have any valid value to give it. But if we introduce a new script +> version it would be placed in the outputs segment. + +What happens if I put ScriptVersion=1 here? + +> === Script v2 === +> +> TODO: does check-multisig need its own mention? + +Does multisig still require a dummy item on the stack? + +> === Block-malleability === +> +> For this reason the merkle tree is extended to include (append) the hash of +> the v4 transactions (and those alone) where the hash is taken over a +> data-blob that is build up from: + +How should nodes know where in the merkle-tree the txids end, and the v4hashes +begin? + +Luke + |