Less than Ideal Mapping to New Outputs

[p0stcapone]

Main Net Example Transaction: https://mempool.space/tx/eed97b6a306b7350784f3a573b46396b6cce404d9ffd67fa982ac757cd6588eb

Resulting location of the inscription: https://ordinals.com/inscription/6dcb3ed8eb96793b7c2917cdeda37197be78af928356167a385814ddcd45014bi0

As the taker constructs the new outputs, they map the first input as 1000 sats, second input as the inscription output and first output as 1000 + inscribedInputSize sats

The result is that the inscribed sat is at satIndex=1000 in the new output

This can result in downstream UX issues where the inscription is likely to be sent to the miner as a fee (not possible so long as the satIndex=0 and the inscribed UTXO is always the first input in the transaction that spends it)

[FelixWeis]

Greg proposed in the ordchat

 Inputs: [dummy500, dummy500, inscription, payment]
Outputs: [dummy1000,inscription,payment,change]

this requires additional dummy inputs but the inscription will stay at SatPoint txid:vout:0

Edit: As noted by satoshi0770 and rot13maxi, 500 should really be at least 546 because of bitcoin dust limit.

[satoshi0770]

Greg proposed in the ordchat

 Inputs: [dummy500, dummy500, inscription, payment]
Outputs: [dummy1000,inscription,payment,change]

this requires additional dummy inputs inputs but the inscription will stay at :0

need to consider the 546 sat dust limit.

We can :
Inputs: [dummy546, dummy546, inscription, payment]
Outputs: [dummy1092,inscription,payment,change]

Edit: upon further research, it seems like dust-limit on taproot might be smaller then 546. Unsure on the amount, and 500sat dummy might be possible.

[Psifour]

need to consider the 546 sat dust limit.

I believe the limit for taproot is 330 sats.

[orenyomtov]

Where is the dust limit defined/enforced?

Also: I plan to revamp the TX buying to not require using a dummy utxo as input, by including the payment input first

[rot13maxi]

Dust limit is defined here: https://github.com/bitcoin/bitcoin/blob/8b4dc94734a2472a201296376bfb18f982e6d92f/src/policy/policy.cpp#L26

[p0stcapone]

If I'm not mistaken, I believe the issue is ultimately less to do with dust limit, and more to do with index ordering of the inputs and outputs

Greg's example of using two "dummy" inputs which collapse into a single output would follow the requirements of sighashsingle anyonecanpay and assert the correct mapping of the outputs re: ord

[crypticmeta]

any updates on this?

[orenyomtov]

haven't got around to refactor the this yet

quoting my previous comment, this is my idea on how to solve it:

I plan to revamp the TX buying to not require using a dummy utxo as input, by including the payment input first

if somebody has the time for it, you're welcome to get at it, PRs welcome

[rayonx]

This should be the ideal output I believe

Example: https://mempool.space/signet/tx/2b064dc101e04c0467735bff5889f89cea2305d1daba2af14c8bb5fe458f8722

[p0stcapone]

#24

This would remove the necessity for any additional UTXOs in some (if not many) cases. It would eliminate the necessity of Dummy UTXOs to assert the index match requirements of sighashsingle.

With this dummy utxo elimination, the inscribed output is in some cases the last output in the resulting transaction. If the padding of this output would go below 2k sats (due to fees), we would pay for the fees using additional UTXOs from the taker. They may in some cases be required to provide additional UTXOs to facilitate this.

If the additional UTXOs provided can be used to increase the size of the inscribed output, they will be allocated for that purpose (up to 10k sats total value in the inscribed output)

IMO, the odds of any given taker needing to supply additional UTXOs can be pushed into rather rare edge cases by introducing HD support to the web client (or potentially even just accepting an array of addresses containing cardinal UTXOs from the signing device).

[rayonx]

always ahead of the curve @p0stcapone 🙌

closing my PR in favor of your change