diff options
| author | Tom <tomz@freedommail.ch> | 2016-09-23 15:13:10 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-09-23 13:13:17 +0000 |
| commit | 38447ea2d9fea2ef5179106d53ca1a1370d158cd (patch) | |
| tree | fae2a9144c99e8b768515c6fe5280d7baedd1265 | |
| parent | 2e75ee045d01856678b22a110e52d204d22f5d85 (diff) | |
| download | pi-bitcoindev-38447ea2d9fea2ef5179106d53ca1a1370d158cd.tar.gz pi-bitcoindev-38447ea2d9fea2ef5179106d53ca1a1370d158cd.zip | |
Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
| -rw-r--r-- | dd/84afdd7b68eceb37ca30357f2dc2bf90b28e3c | 94 |
1 files changed, 94 insertions, 0 deletions
diff --git a/dd/84afdd7b68eceb37ca30357f2dc2bf90b28e3c b/dd/84afdd7b68eceb37ca30357f2dc2bf90b28e3c new file mode 100644 index 000000000..0774c271b --- /dev/null +++ b/dd/84afdd7b68eceb37ca30357f2dc2bf90b28e3c @@ -0,0 +1,94 @@ +Return-Path: <tomz@freedommail.ch> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A5A5C63 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 23 Sep 2016 13:13:17 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BF23F5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 23 Sep 2016 13:13:15 +0000 (UTC) +X-Virus-Scanned: amavisd-new at kolabnow.com +X-Spam-Score: -2.9 +X-Spam-Level: +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) + by mx-out03.mykolab.com (Postfix) with ESMTPS id 7E3B0242B2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 23 Sep 2016 15:13:12 +0200 (CEST) +From: Tom <tomz@freedommail.ch> +To: bitcoin-dev@lists.linuxfoundation.org +Date: Fri, 23 Sep 2016 15:13:10 +0200 +Message-ID: <2344192.PKYylsbkSL@kiwi> +In-Reply-To: <20160923115550.GB17871@nex> +References: <CAKEeUhjisp8qdXDNz3C+pB1MUTfvmHZPmsE-f0DVTxnph6NmMQ@mail.gmail.com> + <2232258.WNiT0kZN2f@kiwi> <20160923115550.GB17871@nex> +MIME-Version: 1.0 +Content-Transfer-Encoding: 7Bit +Content-Type: text/plain; charset="us-ascii" +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Fri, 23 Sep 2016 13:21:05 +0000 +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: Fri, 23 Sep 2016 13:13:17 -0000 + +On Friday, 23 September 2016 13:55:50 CEST Christian Decker via bitcoin-dev +wrote: +> Not sure if the comparison to XML and HTML holds: the lack of closing +> tags makes the meaning of individual tokens ambiguous, like I pointed +> out before. The use of segments gives at most two levels of nesting, +> so any relationship among tokens in the same segment has to rely on +> their relative position, which could result in ambiguities, like +> whether a tag refers to a single input or the transaction as a whole. + + +Practically all tagged formats make ordering a requirement, so indeed this +is relevant, and not unique. + +For instance if you write; + <div> Some line </br>Another line</br>3rd line</div> +you can get a good idea of how ordering is relevant. You can reuse any item +many times. + +Whenever there is a possible confusion the specification specifically +explains which order to use. + +I'm not sure what you mean with the idea this; + +> The use of segments gives at most two levels of nesting + +It looks like you assume there is some opening and closing tags, since +otherwise there would be no nesting. +Such tags are not intended, nor documented. + +> so any relationship among tokens in the same segment has to rely on +> their relative position, which could result in ambiguities, like +> whether a tag refers to a single input or the transaction as a whole. + +I quoted parts of the spec in your previous email stating the same thing, +but I'll repeat here. +Any place that has any sort of possibility to be ambiguous is specified +specifically to have an order. This makes writing and parsing easier. + +Since you wrote two emails now with the same issue, and I addressed it +twice, I would urge you to write out some examples which may be confusing +and if you find that the spec is indeed missing requirements then please +share it with us. I did this some time ago and it helps understanding the +ideas by having actual explicit examples. I am not aware of any sort of +ambiguities that the spec allows. + +Cheers! + |