š
Original date posted:2015-06-06
š Original message:Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
assurance contracts among other things. Sometimes the ordering is set by
the signing logic itself...
On Jun 5, 2015 9:43 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote:
> Title: Canonical Input and Output Ordering
> Author: Rusty Russell <rusty at rustcorp.com.au>
> Discussions-To: "Bitcoin Dev" <bitcoin-development at lists.sourceforge.net>
> Status: Draft
> Type: Standards Track
> Created: 2015-06-06
>
> Abstract
>
> This BIP provides a canonical ordering of inputs and outputs when
> creating transactions.
>
> Motivation
>
> Most bitcoin wallet implementations randomize the outputs of
> transactions they create to avoid trivial linkage analysis (especially
> change outputs), however implementations have made mistakes in this area
> in the past.
>
> Using a canonical ordering has the same effect, but is simpler, more
> obvious if incorrect, and can eventually be enforced by IsStandard() and
> even a soft-fork to enforce it.
>
> Specification
>
> Inputs should be ordered like so:
> index (lower value first)
> txid (little endian order, lower byte first)
>
> Outputs should be ordered like so:
> amount (lower value first)
> script (starting from first byte, lower byte first, shorter wins)
>
> Rationale
>
> Any single wallet is already free to implement this, but if other
> wallets do not it would reduce privacy by making those transactions
> stand out. Thus a BIP is appropriate, especially if this were to
> become an IsStandard() rule once widely adopted.
>
> Because integers are fast to compare, they're sorted first, before the
> lexographical ordering.
>
> The other input fields do not influence the sort order, as any valid
> transactions cannot have two inputs with the same index and txid.
>
> Reference Implementation
>
> https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150605/12c1d6ed/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3ā¦48d0u
2023-06-07 15:36:41
in reply to nevent1qā¦6m99
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 15:36:41Event JSON
{
"id": "689c00471629956759cc83e098c8d6ae37d4e319662a3a41afe06f088ccf19f1",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686152201,
"kind": 1,
"tags": [
[
"e",
"981f41da2a008fa33b1384e8dd3f0d4a96b7f3bed5c463f00f9032a495226e9c",
"",
"root"
],
[
"e",
"6ca3847839c92b6b6bef4c955aba8c1e913a8bc6acd4989351c8f2a44e8b05eb",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "š
Original date posted:2015-06-06\nš Original message:Rusty, this doesn't play well with SIGHASH_SINGLE which is used in\nassurance contracts among other things. Sometimes the ordering is set by\nthe signing logic itself...\nOn Jun 5, 2015 9:43 PM, \"Rusty Russell\" \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Title: Canonical Input and Output Ordering\n\u003e Author: Rusty Russell \u003crusty at rustcorp.com.au\u003e\n\u003e Discussions-To: \"Bitcoin Dev\" \u003cbitcoin-development at lists.sourceforge.net\u003e\n\u003e Status: Draft\n\u003e Type: Standards Track\n\u003e Created: 2015-06-06\n\u003e\n\u003e Abstract\n\u003e\n\u003e This BIP provides a canonical ordering of inputs and outputs when\n\u003e creating transactions.\n\u003e\n\u003e Motivation\n\u003e\n\u003e Most bitcoin wallet implementations randomize the outputs of\n\u003e transactions they create to avoid trivial linkage analysis (especially\n\u003e change outputs), however implementations have made mistakes in this area\n\u003e in the past.\n\u003e\n\u003e Using a canonical ordering has the same effect, but is simpler, more\n\u003e obvious if incorrect, and can eventually be enforced by IsStandard() and\n\u003e even a soft-fork to enforce it.\n\u003e\n\u003e Specification\n\u003e\n\u003e Inputs should be ordered like so:\n\u003e index (lower value first)\n\u003e txid (little endian order, lower byte first)\n\u003e\n\u003e Outputs should be ordered like so:\n\u003e amount (lower value first)\n\u003e script (starting from first byte, lower byte first, shorter wins)\n\u003e\n\u003e Rationale\n\u003e\n\u003e Any single wallet is already free to implement this, but if other\n\u003e wallets do not it would reduce privacy by making those transactions\n\u003e stand out. Thus a BIP is appropriate, especially if this were to\n\u003e become an IsStandard() rule once widely adopted.\n\u003e\n\u003e Because integers are fast to compare, they're sorted first, before the\n\u003e lexographical ordering.\n\u003e\n\u003e The other input fields do not influence the sort order, as any valid\n\u003e transactions cannot have two inputs with the same index and txid.\n\u003e\n\u003e Reference Implementation\n\u003e\n\u003e https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150605/12c1d6ed/attachment.html\u003e",
"sig": "f8b1411936aa6e11c2f07b2b177eb48655cef9016b2ef96aa178cec9abc4e9f40ba5f6d800182a5a700ab5d35096d2b0000b5e92724d3285a2290cb45272a2a8"
}