From: Tom <tomz@freedommail•ch>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Date: Thu, 22 Sep 2016 20:47:50 +0200 [thread overview]
Message-ID: <2619297.H12PQLatFI@kiwi> (raw)
In-Reply-To: <20160922182618.GA19147@fedora-21-dvm>
On Thursday, 22 September 2016 14:26:18 CEST Peter Todd wrote:
> > «The way towards that flexibility is to use a generic concept made
> > popular various decades ago with the XML format. The idea is that we
> > give each field a name and this means that new fields can be added or
> > optional fields can be omitted from individual transactions»
>
> That argument is not applicable to required fields:
The argument that optional fields can be omitted is not applicable to
required fields, you are correct. That should be rather obvious because
required fields are not optional fields.
> the code to get the
> fields from the extensible format is every bit as complex as the very
> simple code required to deserialize/serialize objects in the current
> system.
Probably a tiny bit more complex as the current format assumes a lot more.
You may have misread my email because there was no argument made towards
complexity. The argument was towards flexibility.
> In any case your BIP needs to give some explicit examples of hypothetical
> upgrades in the future, how they'd take advantage of this, and what the
> code to do so would look like.
Why?
> > > Also, if you're going to break compatibility with all existing
> > > software, it makes sense to use a format that extends the merkle
> > > tree down into the transaction inputs and outputs.
> >
> > Please argue your case.
>
> See my arguments re: segwit a few months ago, e.g. the hardware wallet
> txin proof use-case.
Please consider that I'm not going to search for something based on a vague
reference like that, if you want to convince me you could you at least
provide a URL?
You want me to see the value of your idea, I think you should at least
provide the argument. Isn't that fair?
Thanks for your email Peter, would love you to put a bit more time into
understanding flexible transactions and we can have a proper discussion
about it.
next prev parent reply other threads:[~2016-09-22 18:47 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 [this message]
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
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=2619297.H12PQLatFI@kiwi \
--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