From: Tom <tomz@freedommail•ch>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Date: Thu, 22 Sep 2016 14:09:38 +0200 [thread overview]
Message-ID: <6286144.BZfBM3Z3un@garp> (raw)
In-Reply-To: <20160922111049.GA592@nex>
On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote:
> On Thu, Sep 22, 2016 at 10:56:31AM +0200, Tom via bitcoin-dev wrote:
> > On Wednesday 21 Sep 2016 18:01:30 Gregory Maxwell via bitcoin-dev wrote:
> > > On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev
> > >
> > > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > > > BIP number for my FT spec.
> > >
> > > This document does not appear to be concretely specified enough to
> > > review or implement from it.
> > >
> > > For example, it does not specify the serialization of "integer"
> >
> > It refers to the external specification which is linked at the bottom.
> > In that spec you'll see that "Integer" is the standard var-int that
> > Bitcoin
> > has used for years.
>
> 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.
> > > nor does it specify how the
> > > presence of the optional fields are signaled
> >
> > How does one signals an optional field except of in the spec? Thats the
> > job of a specification.
>
> 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?
> > > nor the cardinality of
> > > the inputs or outputs.
> >
> > Did you miss this in the 3rd table ? I suggest clicking on the github
> > bips
> > repo link as tables are not easy to read in mediawiki plain format that
> > the
> > email contained.
>
> 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
> 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.
> 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»
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.
Thank you for your email to my BIP, I hope you got the answers you were
looking for :)
next prev parent reply other threads:[~2016-09-22 12:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 17:15 Tom
2016-09-20 21:31 ` Luke Dashjr
2016-09-21 9:32 ` Tom
2016-09-20 21:56 ` Peter Todd
2016-09-21 9:32 ` Tom
2016-09-22 18:26 ` Peter Todd
2016-09-22 18:47 ` Tom
2016-09-21 12:00 ` Andreas Schildbach
2016-09-21 12:58 ` Tom
[not found] ` <CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
2016-09-21 18:01 ` Gregory Maxwell
2016-09-22 8:56 ` Tom
2016-09-22 11:10 ` Christian Decker
2016-09-22 12:09 ` Tom [this message]
2016-09-23 11:42 ` Christian Decker
2016-09-23 13:17 ` Tom
2016-09-21 22:45 adiabat
2016-09-22 8:47 ` Tom
2016-09-22 18:27 ` Peter Todd
2016-09-22 18:37 ` Tom
2016-09-22 19:59 ` Jonas Schnelli
2016-09-22 20:07 ` Tom
2016-09-23 11:55 ` Christian Decker
2016-09-23 13:13 ` Tom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6286144.BZfBM3Z3un@garp \
--to=tomz@freedommail$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox