From: Kristov Atlas <kristovatlas.lists@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin development mailing list
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Date: Mon, 8 Jun 2015 18:53:54 -0400 [thread overview]
Message-ID: <CAGH37SLyG-g54-gGU5ZrmQsiogOqWNW1iiayHii1nWiWh+Nk=w@mail.gmail.com> (raw)
In-Reply-To: <20150607023523.GB1570@savin.petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 3110 bytes --]
Hey Peter, thanks for your experienced feedback.
On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd <pete@petertodd•org> wrote:
> Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized
> protocols; you haven't taken into account the needs of those protocols.
> For BIP's it's better to stick to the use-cases where the need is clear
> and there exists running code that to speculate too much on future uses.
> With signature hashing in particular it's not yet clear at all what
> future OP_CHECKSIG's will look like, let alone the various ways people
> will use sighash for smart contract type stuff.
>
> You'd be better off presenting the BIP in terms of a generic statement
> that "except when otherwise prevented by advanced signature hashing
> requirements, wallet software must emit transactions sorted according to
> the following" You can then specify the two common cases in detail:
>
> 1) SIGHASH_ALL: input and output order signed, so sort appropriately
>
> 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit
> transactions sorted, recognising that the actual mined order may be
> changed.
>
That makes sense. I updated the language as follows -- your thoughts? Keep
in mind this BIP is informational, and so people are free to ignore it.
"Applicability: This BIP applies to all transactions of signature hash type
SIGHASH_ALL. Additionally, software compliant with this BIP that allows
later parties to update the transaction (e.g. using signature hash types
SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit
lexicographically sorted inputs and outputs, although they may later be
modified. Transactions that have index dependencies between transactions or
within the same transaction are covered under the section of this BIP
entitled “Handling Input/Output Dependencies.”"
> As for IsStandard() rules - let alone soft forks - better to leave
> discussion of them out for now. In particular, for the soft-fork case
> mandating certain transaction orders will very likely cause problems in
> the future for future OP_CHECKSIG upgrades. For SIGHASH_ANYONECANPAY, it
> might be appropriate for nodes to enforce a certain ordering, but that
> can be a separate BIP. (actually implementing that in Bitcoin Core would
> be annoying and ugly right now; without replace-by-fee ANYONECANPAY has
> a silly DoS attack (adding low-fee inputs) so I can't recommend wallets
> use it in the general case yet)
>
> "and a sequence number currently set to 0xFFFFFFFF." <- Actually, this
> will be changed in Bitcoin Core as of v0.11.0, which implements
> anti-fee-sniping w/ nLockTime.(1) (I need to write up a full BIP
> describing it)
>
Thanks for the heads-up; removed.
> Do you have a patch implementing deterministic tx ordering for Bitcoin
> Core yet?
>
I'm not a frequent C programmer, so I'd prefer to let someone else take
care of it, as a frequent committer of code would do a faster and more
stylistically consistent job of it. If no one else will, however, I will.
-Kristov
[-- Attachment #2: Type: text/html, Size: 4199 bytes --]
next prev parent reply other threads:[~2015-06-08 22:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-06 0:12 Kristov Atlas
2015-06-06 3:20 ` Stephen
2015-06-06 6:24 ` Kristov Atlas
2015-06-07 0:06 ` Kristov Atlas
2015-06-07 2:35 ` Peter Todd
2015-06-08 22:53 ` Kristov Atlas [this message]
2015-06-08 22:55 ` Kristov Atlas
2015-06-09 20:14 ` Peter Todd
2015-06-10 23:36 ` Kristov Atlas
2015-06-12 21:36 ` Kristov Atlas
2015-06-14 16:29 ` Kristov Atlas
2015-06-15 21:42 ` Rusty Russell
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='CAGH37SLyG-g54-gGU5ZrmQsiogOqWNW1iiayHii1nWiWh+Nk=w@mail.gmail.com' \
--to=kristovatlas.lists@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)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