<div dir="ltr"><div>Update: BIP 79 has been implemented in the latest release of Electrum, v2.3.2: <br><br><a href="https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES">https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES</a><br><br></div>-Kristov<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 5:36 PM, Kristov Atlas <span dir="ltr"><<a href="mailto:kristovatlas.lists@gmail.com" target="_blank">kristovatlas.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Since everyone's busy, I went ahead and made a pull request to add this as an informational BIP 79 to the bips directory.<br><br><a href="https://github.com/bitcoin/bips/pull/157" target="_blank">https://github.com/bitcoin/bips/pull/157</a><br><br></div>Regards,<br></div>Kristov<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:<br>
<br>
Two other things:<br>
<div><div><br>
<br>
<br>
> On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd <<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>> wrote:<br>
><br>
> > Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized<br>
> > protocols; you haven't taken into account the needs of those protocols.<br>
> > For BIP's it's better to stick to the use-cases where the need is clear<br>
> > and there exists running code that to speculate too much on future uses.<br>
> > With signature hashing in particular it's not yet clear at all what<br>
> > future OP_CHECKSIG's will look like, let alone the various ways people<br>
> > will use sighash for smart contract type stuff.<br>
> ><br>
> > You'd be better off presenting the BIP in terms of a generic statement<br>
> > that "except when otherwise prevented by advanced signature hashing<br>
> > requirements, wallet software must emit transactions sorted according to<br>
> > the following" You can then specify the two common cases in detail:<br>
> ><br>
> > 1) SIGHASH_ALL: input and output order signed, so sort appropriately<br>
> ><br>
> > 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit<br>
> > transactions sorted, recognising that the actual mined order may be<br>
> > changed.<br>
> ><br>
><br>
> That makes sense. I updated the language as follows -- your thoughts? Keep<br>
> in mind this BIP is informational, and so people are free to ignore it.<br>
><br>
> "Applicability: This BIP applies to all transactions of signature hash type<br>
> SIGHASH_ALL. Additionally, software compliant with this BIP that allows<br>
> later parties to update the transaction (e.g. using signature hash types<br>
> SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit<br>
> lexicographically sorted inputs and outputs, although they may later be<br>
> modified. Transactions that have index dependencies between transactions or<br>
> within the same transaction are covered under the section of this BIP<br>
> entitled “Handling Input/Output Dependencies.”"<br>
<br>
</div></div>I'd keep it even simpler than that, and just say for now that such<br>
use-cases are out of the scope of this BIP, however those standards<br>
should come up with some kind of deterministic standard that meets the<br>
needs of the protocol. Again, there's a bunch of possible use-cases here<br>
and we just can't predict them; focus on the fact that the *spirit* of<br>
what this BIP is about is applicable and future standards should be<br>
developed.<br>
<br>
So I'd change the "Applicability" section to:<br>
<br>
This BIP applies to all transactions where the order of inputs and<br>
outputs does not matter. This is true for the vast majority of<br>
transactions as they simply move funds from one place to another.<br>
<br>
Currently this generally refers to transactions where SIGHASH_ALL is<br>
used, in which case the signatures commit to the exact order of input<br>
and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE<br>
has been used (e.g. crowdfunds) the order of inputs and/or outputs may<br>
not be signed, however compliant software should still emit transactions<br>
with sorted inputs and outputs, even though they may later be modified<br>
by others.<br>
<br>
In the event that future protocol upgrades introduce new signature hash<br>
types, compliant software should apply the lexographic ordering<br>
principle analogously.<br>
<br>
While out of scope of this BIP, protocols that do require a specified<br>
order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should<br>
consider the goals of this BIP and how best to adapt them to the<br>
specifics needs of those protocols.<br>
<br>
<br>
Then remove the "handling input/output deps" section.<br>
<span><br>
> > Do you have a patch implementing deterministic tx ordering for Bitcoin<br>
> > Core yet?<br>
> ><br>
><br>
> I'm not a frequent C programmer, so I'd prefer to let someone else take<br>
> care of it, as a frequent committer of code would do a faster and more<br>
> stylistically consistent job of it. If no one else will, however, I will.<br>
<br>
<br>
<br>
</span>re: the actual ordering algorithm, having txids be sorted by with the<br>
hex-based algorithm is odd. I'd simply say they're sorted as<br>
little-endian byte arrays, or in other words, with the bytearr_cmp()<br>
function, but with the order of bytes reversed. You also should say that<br>
we're doing that to make the user see them in visually sorted order to<br>
match expectations because txids are displayed as little-endian.<br>
<br>
For outputs, don't say "locking script", say "scriptPubKey". Secondly,<br>
scriptPubKeys are not in little-endian representation - they have no<br>
endianness to them. With output amount, there's no need to say that<br>
they're unsigned or little-endian satoshies, just say they're sorted<br>
largest/smallest amount first.<br>
<br>
"For the sake of efficiency, amounts will be considered first for<br>
sorting, since they contain fewer bytes of information (7 bytes)<br>
compared to a standard P2PKH locking script (800 bytes)." <- where the<br>
heck did you get these numbers from? Amounts are 8 bytes, and P2PKH<br>
scriptPubKeys are 25 bytes.<br>
<br>
<br>
"Backwards Compatibility" <- I'd just remove this whole section; we're<br>
unlikely to make this an IsStandard() rule anytime soon.<br>
<span><font color="#888888"><br>
--<br>
'peter'[:-1]@<a href="http://petertodd.org" rel="noreferrer" target="_blank">petertodd.org</a><br>
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>