On Sat, Jun 06, 2015 at 08:06:56PM -0400, Kristov Atlas wrote: In general I think this is a good idea, and should be implemented; we've had a depressing number of wallets fail to implement randomization properly, if at all.
> I've updated the draft BIP in two ways: > -Making it clear that sorting is algorithmically agnostic, but should > conform to the output of the example algorithms written in python > -The BIP now handles schemes that create an input/output dependency, such > as SIGHASH_SINGLE: > > Handling Input/Output Dependencies > > Some uncommon forms of transactions create an ordering dependency between > inputs and outputs of a transaction. Wallets forming these transactions > should first sort inputs according to the methodology outlined in section > “Transaction Inputs” of this BIP. Then, they should fix the output indices > that depend on the input order, and sort the remaining outputs around them. > If there are no outputs that do not depend on input order, then all outputs > will simply be ordered based on the expected scheme. The following are the > known cases of input/output dependency that must be handled specially: > > * SIGHASH_SINGLE hash type. [5] Clients seeking to verify LI01 compliance > for a transaction must inspect the last byte of the scriptSig of each input > to determine the signature hash type. In the case of SIGHASH_SINGLE (0x03) > for input “n”, the verifier should expect that output “n” will be fixed > when considering output ordering. 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. 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) Do you have a patch implementing deterministic tx ordering for Bitcoin Core yet? 1) https://github.com/bitcoin/bitcoin/pull/2340 -- 'peter'[:-1]@petertodd.org 0000000000000000079693d8d175b476081a04af9c1d00ea2dbe0efb011bd79e
signature.asc
Description: Digital signature
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
