From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F3FCEBFF for ; Fri, 23 Sep 2016 11:42:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1442C1CA for ; Fri, 23 Sep 2016 11:42:39 +0000 (UTC) Received: by mail-wm0-f47.google.com with SMTP id l132so25048718wmf.1 for ; Fri, 23 Sep 2016 04:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=+jUvItm/gsacXHuCCBzr0qn12v1ZkrHQMgw/BYlGfqM=; b=Bb661zjcwxDR9Li0VEdtPXseBc9I/MOSVaxZFZhGHttGRiheZhjxZTAhb/ZrcPIA2V vcM+bNozKKJHiEa4vBY4X1J3CGPMEQD4H/xk+4QeeX/fw3Jk/pZ/ohmGZg6gREI0KERx kMnxHGbzWU6rTnlruCe/5Ij9LSjQpZcP+6U8XByEWvpQCSwVSyg6wQOyerW6lrR17sjq DL/0evBX7iYOkmkO9knnz9kQJ3Xeov9oxK4KgyBS524aH8iWe9tyIeaUMM+twJBQHmGo zMMiIzD/VDVo8fTL6zFbR1PdDIlWjscbeNQwdKLbbcQLk15cK23TfgRicnEG3mIy8myG rbpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=+jUvItm/gsacXHuCCBzr0qn12v1ZkrHQMgw/BYlGfqM=; b=MXwNvL0NBojvOc6XHq96U3n6ovU1l2rTsqhRQrM2Q50L++Fv1kdWw0gkimAzGqx/qd mdMSWAYAyDbUWlHd/OeAhKPjeEtiDY6MkE1BclpmoV6fZFywds69kJNWiRWjZnzEGsdU 7dyec/3MNg7SkIOiMqikwZekrVv7CKiS7yietnmueqzxpJv4scklC7ubbnWVjYng8sEt ysnKqZbiTES6ubXgCaSrOkcm97NOX5Y62TXMXOaTeOAKbLgL6bGxp1LlZF3WDtTcg11p BSTKr6VdC8MLtBIpy6+vZBc4M3TTxJUQO47paIbP97sYokkc7i1kvgawtNRcr+3YaFEc /E8A== X-Gm-Message-State: AA6/9RmMwrkcz3LEyCXfJYZzgG+vVsuFDhV9GHX588LK5+j6pN6KyYKIk9zBywBlYGwEmw== X-Received: by 10.28.14.20 with SMTP id 20mr2666989wmo.6.1474630957527; Fri, 23 Sep 2016 04:42:37 -0700 (PDT) Received: from nex ([2a02:aa16:1105:4a80:eca1:a51:7a7c:5e35]) by smtp.gmail.com with ESMTPSA id g7sm6798663wjc.43.2016.09.23.04.42.36 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 23 Sep 2016 04:42:36 -0700 (PDT) Date: Fri, 23 Sep 2016 13:42:36 +0200 From: Christian Decker To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20160923114236.GA17871@nex> Mail-Followup-To: Christian Decker , bitcoin-dev@lists.linuxfoundation.org References: <7844645.RLYLWYmWtM@garp> <1988067.b5KirJFSKj@garp> <20160922111049.GA592@nex> <6286144.BZfBM3Z3un@garp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6286144.BZfBM3Z3un@garp> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 11:42:40 -0000 On Thu, Sep 22, 2016 at 02:09:38PM +0200, Tom via bitcoin-dev wrote: > On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote: > > > > I think BIPs should be self-contained, or rely on previous BIPs, > > whenever possible. Referencing an external formatting document should > > be avoided > > If luke-jr thinks I should submit CMF as a BIP, I can certainly do that. > Luke, what do you think? > > I don't have a preference either way. > > > > > So the presence is signaled by encountering the tag, which contains > > both token type and name-reference. The encoder and decoder operations > > could be described better. > > I'm sorry, I'm not following you here. Is there a question? Nope, just clarifying how presence or absence is indicated :-) > > > > Minor nit: that table is not well-formed. > > I am not very well versed in mediawiki tables, and I found github has some > incompatibilities too. > The markdown one looks better; > https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md It's just some rows have 3 columns, others have 2. It's a minor nit really. > > As was pointed out in the > > normalized transaction ID BIP, your proposal only addresses > > third-party malleability, since signers can simply change the > > transaction and re-sign it. > > I have to disagree. That is not malleability. Creating a new document and re- > signing it is not changing anything. Its re-creating. Something that the owner > of the coin has every right to do. Same thing I was arguing back then, however Luke pointed out that malleability just refers to the possibility of modifying a transaction after the fact. Always referring to "third-party malleability" avoids this ambiguity. > > This is evident from the fact that inputs > > and outputs do not have a canonical order and it would appear that > > tokens can be re-ordered in segments. > > Sorry, what is evident? You seem to imply that it is uncommon that you can > create two transactions of similar intent but using different bytes. > You would be wrong with this implication as this is very common. You can just > alter the order of the inputs, for instance. > > I am unable to see what the point is you are trying to make. Is there a > question or a suggestion for improvement here? > > > Dependencies of tokens inside a > > segment are also rather alarming (TxInPrevHash <-> TxInPrevIndex, > > TxOutScript <-> TxOutValue). > > Maybe you missed this line; > «TxInPrevHash and TxInPrevIndex > Index can be skipped, but in any input the PrevHash always has > to come first» Nope, that is exactly the kind of dependency I was talking about. Instead of nesting a construct like the current transactions do, you rely on the order of tokens to imply that they belong together. > If you still see something alarming, let me know. > You can look at the code in Bitcoin Classic and notice that it really isn't > anything complicated or worrying. > > > > Finally, allowing miners to reject transactions with unknown fields > > makes the OP_NOPs unusable > > Hmm, it looks like you are mixing terminology and abstraction-levels. OP_NOP > is a field from script and there is no discussion about any rejection based on > script in this BIP at all. > > Rejection of transactions is done on there being unrecognised tokens in the > transaction formatting itself. Ah, thanks for clearing that up. However, the problem persists, if we add new fields that a non-upgraded node doesn't know about and it rejects transactions containing it, we'll have a hard-fork. It should probably not reject transactions with unknown fields if the transaction is included in a block. > Thank you for your email to my BIP, I hope you got the answers you were > looking for :) Cheers, Christian