public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Kristov Atlas <kristovatlas.lists@gmail•com>
To: Stephen <stephencalebmorse@gmail•com>
Cc: Bitcoin development mailing list
	<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Date: Sat, 6 Jun 2015 20:06:56 -0400	[thread overview]
Message-ID: <CAGH37SLCc-aEG0t0H7fsUZOv_h+Fiw4xoonmfwNaFWBin_7HcQ@mail.gmail.com> (raw)
In-Reply-To: <CAGH37SL3TA7BXd3Y+4F1Fd5N3ZW+LRLvkfppPsPn61ZVbZJOnQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2676 bytes --]

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.

https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki

I'm satisfied with this adjustment, as it is unlikely that any software
that wants to verify compliance with the BIP will not have access to the
scriptSig of each input.

-Kristov

On Sat, Jun 6, 2015 at 2:24 AM, Kristov Atlas <kristovatlas.lists@gmail•com>
wrote:

> Hey Stephen,
>
> Thanks for your feedback
>
> On Fri, Jun 5, 2015 at 11:20 PM, Stephen <stephencalebmorse@gmail•com>
> wrote:
>
>>  - I think your explanation of sorting could be significantly shortened
>> and clarified by simply saying that the TXIDs of inputs should be compared
>> as uint256 integers.
>>
>
> I considered defining the comparison of txids in terms of integers;
> however, I am concerned that this definition may be ambiguous when applied
> to a variety of languages and platforms without a similar amount of
> explanation as currently exists. For example, if a web wallet uses an API
> to receive transaction information, this is traditionally expressed in
> terms tx id strings rather than 256-bit integers. My intent is that wallets
> can implement the algorithm however they wish, but should ensure that their
> output is compliant with the BIP definition. IMHO the algorithm stated in
> the BIP should target test cases rather than implementation, and should
> leave as little room for ambiguity as possible.
>

[-- Attachment #2: Type: text/html, Size: 3472 bytes --]

  reply	other threads:[~2015-06-07  0:07 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 [this message]
2015-06-07  2:35       ` Peter Todd
2015-06-08 22:53         ` Kristov Atlas
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=CAGH37SLCc-aEG0t0H7fsUZOv_h+Fiw4xoonmfwNaFWBin_7HcQ@mail.gmail.com \
    --to=kristovatlas.lists@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=stephencalebmorse@gmail$(echo .)com \
    /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