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 10:56:31 +0200 [thread overview]
Message-ID: <1988067.b5KirJFSKj@garp> (raw)
In-Reply-To: <CAAS2fgT5izjzUVyd3-9sQEHx8rk8pEJWxT6-eDteuUkZdRokAg@mail.gmail.com>
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.
> 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.
> 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.
> For clearly variable length elements
> ('bytearray') no mention is made of their length encoding. etc.
Also in the external CMF spec.
> Without information like this, I don't see how someone could
> realistically begin reviewing this proposal.
I agree, that would be bad. Luckily that you just missed the link :)
Here it is;
https://github.com/bitcoinclassic/documentation/blob/master/spec/compactmessageformat.md
> The motivation seems unclear to me as well: The scheme is described as
> 'flexible' but it appears to remove flexibility from the existing
> system. The "schema" appears to be hardcoded and never communicated.
Being hardcoded and never communicated is what the current format does to. How
does that "remove flexibility".
Also read my reply to Peter Todd on why this is flexible.
> If the goal is to simply have {snip}
It is not.
Thanks for asking, I understand that the CMF spec is useful to see as well.
Hopefully you can now review it properly since I linked to it above.
Cheers!
next prev parent reply other threads:[~2016-09-22 8:56 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 [this message]
2016-09-22 11:10 ` Christian Decker
2016-09-22 12:09 ` Tom
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=1988067.b5KirJFSKj@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