Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

[Jeremy via bitcoin-dev]

At the end of the day I don't really care that much I just prefer something
that doesn't throw taproot in for another review cycle.

A side effect of this proposal is it would seem to make it not possible to
produce a signature for a transaction without having access to the inputs.
This is limiting for a number of cases where you don't care about that
data. There are a litany of use cases where you don't want to have
SIGHASH_ALL behavior, and having to sign the scriptpubkeys breaks that. So
at the very least it should respect other flags.

I also don't really understand the exact attack. So you submit a
transaction to the wallet asking them to sign input 10. They sign. They've
committed to the signature being bound to the specific COutpoint and input
index, so I don't see how they wouldn't be required to sign a second
signature with the other output too? Is there an attack you can describe
end-to-end relying on this behavior?

If you look at the TXID hash the vouts are one of the last fields
serialized. this makes it possible (at least, I think) to do a midstate
proof so that all you are providing is the hash midstate, and the relevant
transaction output,  the siblings after, and the locktime. So you get to
skip all the input data, the witness data, and most of the output data.

This sort of data can easily go into the proprietary use (maybe becoming
well defined if there's a standardization push) area in PSBT, so that
hardware devices can get easy access to it. All they have to do to verify
is to finalize the hash against that buffer and match to the correct input.


As an alternative proposal, I think you can just make a separate BIP for
some new sigash flags that can be reviewed separately from taproot. There's
a lot of value in investing in figuring out more granular controls over
what the signature hash is you sign, which may have some exciting
contracting implications!
--
@JeremyRubin 



On Fri, May 1, 2020 at 5:26 AM Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> For what it's worth this measure had been discussed as a lightweight way
> of informing offline signers if inputs were segwit or not for malleability
> analysis reasons. So there's at least a couple direct use-cases it seems.
>
> On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> While I'm not entirely convinced yet that accertaining non-ownership of
>> an input is a robust method of solving the problem here, I also see little
>> reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
>> already indirectly covered through the outpoints, so it is just a matter of
>> optimization.  Furthermore in the consensus code, the ScriptPubKeys are
>> part of the UTXO data set, and it is already being retrieved as part of the
>> transaction checking process, so it is readily available.
>>
>> I'm not sure how much my opinion on the topic matters, but I did include
>> this kind of functionality in my design for Simplicity on Elements, and I
>> have been leaning towards adding this kind of functionality in my Bitcoin
>> demo application of Simplicity.
>>
>> Regarding specifics, I personally think it would be better to keep the
>> hashes of the ScriptPubKeys separate from the hashes of the input values.
>> This way anyone only interested in input values does not need to wade
>> through what are, in principle, arbitrarily long ScriptPubKeys in order to
>> check the input values (which each fixed size).  To that end, I would also
>> (and independently) propose separating the hashing of the output values
>> from the output ScriptPubKeys in `sha_outputs` so again, applications
>> interested only in summing the values of the outputs (for instance to
>> compute fees) do not have to wade through those arbitrarily long
>> ScriptPubKeys in the outputs.
>>
>> On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi everyone,
>>>
>>> In the current draft of BIP-0341 [1] the signature message commits to
>>> the scriptPubKey of the output being spent by the input. I propose that the
>>> signature message should commit to the scriptPubKeys of *all* transaction
>>> inputs.
>>>
>>> In certain applications like CoinJoin, a wallet has to deal with
>>> transactions containing external inputs. To calculate the actual amount
>>> that the user is spending, the wallet needs to reliably determine for each
>>> input whether it belongs to the wallet or not. Without such a mechanism an
>>> adversary can fool the wallet into displaying incorrect information about
>>> the amount being spent, which can result in theft of user funds [2].
>>>
>>> In order to ascertain non-ownership of an input which is claimed to be
>>> external, the wallet needs the scriptPubKey of the previous output spent by
>>> this input. It must acquire the full 

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

[Greg Sanders via bitcoin-dev]

For what it's worth this measure had been discussed as a lightweight way of
informing offline signers if inputs were segwit or not for malleability
analysis reasons. So there's at least a couple direct use-cases it seems.

On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> While I'm not entirely convinced yet that accertaining non-ownership of an
> input is a robust method of solving the problem here, I also see little
> reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
> already indirectly covered through the outpoints, so it is just a matter of
> optimization.  Furthermore in the consensus code, the ScriptPubKeys are
> part of the UTXO data set, and it is already being retrieved as part of the
> transaction checking process, so it is readily available.
>
> I'm not sure how much my opinion on the topic matters, but I did include
> this kind of functionality in my design for Simplicity on Elements, and I
> have been leaning towards adding this kind of functionality in my Bitcoin
> demo application of Simplicity.
>
> Regarding specifics, I personally think it would be better to keep the
> hashes of the ScriptPubKeys separate from the hashes of the input values.
> This way anyone only interested in input values does not need to wade
> through what are, in principle, arbitrarily long ScriptPubKeys in order to
> check the input values (which each fixed size).  To that end, I would also
> (and independently) propose separating the hashing of the output values
> from the output ScriptPubKeys in `sha_outputs` so again, applications
> interested only in summing the values of the outputs (for instance to
> compute fees) do not have to wade through those arbitrarily long
> ScriptPubKeys in the outputs.
>
> On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>> In the current draft of BIP-0341 [1] the signature message commits to the
>> scriptPubKey of the output being spent by the input. I propose that the
>> signature message should commit to the scriptPubKeys of *all* transaction
>> inputs.
>>
>> In certain applications like CoinJoin, a wallet has to deal with
>> transactions containing external inputs. To calculate the actual amount
>> that the user is spending, the wallet needs to reliably determine for each
>> input whether it belongs to the wallet or not. Without such a mechanism an
>> adversary can fool the wallet into displaying incorrect information about
>> the amount being spent, which can result in theft of user funds [2].
>>
>> In order to ascertain non-ownership of an input which is claimed to be
>> external, the wallet needs the scriptPubKey of the previous output spent by
>> this input. It must acquire the full transaction being spent and verify its
>> hash against that which is given in the outpoint. This is an obstacle in
>> the implementation of lightweight air-gapped wallets and hardware wallets
>> in general. If the signature message would commit to the scriptPubKeys of
>> all transaction inputs, then the wallet would only need to acquire the
>> scriptPubKey of the output being spent without having to acquire and verify
>> the hash of the entire previous transaction. If an attacker would provide
>> an incorrect scriptPubKey, then that would cause the wallet to generate an
>> invalid signature message.
>>
>> Note that committing only to the scriptPubKey of the output being spent
>> is insufficient for this application, because the scriptPubKeys which are
>> needed to ascertain non-ownership of external inputs are precisely the ones
>> that would not be included in any of the signature messages produced by the
>> wallet.
>>
>> The obvious way to implement this is to add another hash to the signature
>> message:
>> sha_scriptPubKeys (32): the SHA256 of the serialization of all
>> scriptPubKeys of the previous outputs spent by this transaction.
>>
>> Cheers,
>> Andrew Kozlik
>>
>> [1]
>> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

[Russell O'Connor via bitcoin-dev]

While I'm not entirely convinced yet that accertaining non-ownership of an
input is a robust method of solving the problem here, I also see little
reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
already indirectly covered through the outpoints, so it is just a matter of
optimization.  Furthermore in the consensus code, the ScriptPubKeys are
part of the UTXO data set, and it is already being retrieved as part of the
transaction checking process, so it is readily available.

I'm not sure how much my opinion on the topic matters, but I did include
this kind of functionality in my design for Simplicity on Elements, and I
have been leaning towards adding this kind of functionality in my Bitcoin
demo application of Simplicity.

Regarding specifics, I personally think it would be better to keep the
hashes of the ScriptPubKeys separate from the hashes of the input values.
This way anyone only interested in input values does not need to wade
through what are, in principle, arbitrarily long ScriptPubKeys in order to
check the input values (which each fixed size).  To that end, I would also
(and independently) propose separating the hashing of the output values
from the output ScriptPubKeys in `sha_outputs` so again, applications
interested only in summing the values of the outputs (for instance to
compute fees) do not have to wade through those arbitrarily long
ScriptPubKeys in the outputs.

On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everyone,
>
> In the current draft of BIP-0341 [1] the signature message commits to the
> scriptPubKey of the output being spent by the input. I propose that the
> signature message should commit to the scriptPubKeys of *all* transaction
> inputs.
>
> In certain applications like CoinJoin, a wallet has to deal with
> transactions containing external inputs. To calculate the actual amount
> that the user is spending, the wallet needs to reliably determine for each
> input whether it belongs to the wallet or not. Without such a mechanism an
> adversary can fool the wallet into displaying incorrect information about
> the amount being spent, which can result in theft of user funds [2].
>
> In order to ascertain non-ownership of an input which is claimed to be
> external, the wallet needs the scriptPubKey of the previous output spent by
> this input. It must acquire the full transaction being spent and verify its
> hash against that which is given in the outpoint. This is an obstacle in
> the implementation of lightweight air-gapped wallets and hardware wallets
> in general. If the signature message would commit to the scriptPubKeys of
> all transaction inputs, then the wallet would only need to acquire the
> scriptPubKey of the output being spent without having to acquire and verify
> the hash of the entire previous transaction. If an attacker would provide
> an incorrect scriptPubKey, then that would cause the wallet to generate an
> invalid signature message.
>
> Note that committing only to the scriptPubKey of the output being spent is
> insufficient for this application, because the scriptPubKeys which are
> needed to ascertain non-ownership of external inputs are precisely the ones
> that would not be included in any of the signature messages produced by the
> wallet.
>
> The obvious way to implement this is to add another hash to the signature
> message:
> sha_scriptPubKeys (32): the SHA256 of the serialization of all
> scriptPubKeys of the previous outputs spent by this transaction.
>
> Cheers,
> Andrew Kozlik
>
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

[Andrew Kozlik via bitcoin-dev]

Hi Jeremy,

What you are saying is correct and I am not disputing that there is
sufficient cryptographic commitment in the signature message. As I tried to
explain, my proposal is about avoiding the need for the metadata protocol
you speak of. Avoiding such a protocol has been a design goal in both
BIP-143 [1, 2] and BIP-341 [3, 4], because having to acquire each of the
transactions being spent in their entirety places a significant burden on
offline signing devices.

Cheers,
Andrew

[1]
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#motivation
[2] https://bitcointalk.org/index.php?topic=181734.0
[3]
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-16
[4]
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-17

On Fri, May 1, 2020 at 8:56 AM Jeremy  wrote:

> Hi Andrew,
>
> If you use SIGHASH_ALL it shall sign the COutPoints of all inputs which
> commit to the scriptPubKeys of the txn.
>
> Thus the 341 hash doesn't need to sign any additional data.
>
> As a metadata protocol you can provide all input transactions to check the
> scriptPubKeys.
>
> Best,
>
> Jeremy
> --
> @JeremyRubin 
>
>
> On Thu, Apr 30, 2020 at 1:22 AM Andrew Kozlik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>> In the current draft of BIP-0341 [1] the signature message commits to the
>> scriptPubKey of the output being spent by the input. I propose that the
>> signature message should commit to the scriptPubKeys of *all* transaction
>> inputs.
>>
>> In certain applications like CoinJoin, a wallet has to deal with
>> transactions containing external inputs. To calculate the actual amount
>> that the user is spending, the wallet needs to reliably determine for each
>> input whether it belongs to the wallet or not. Without such a mechanism an
>> adversary can fool the wallet into displaying incorrect information about
>> the amount being spent, which can result in theft of user funds [2].
>>
>> In order to ascertain non-ownership of an input which is claimed to be
>> external, the wallet needs the scriptPubKey of the previous output spent by
>> this input. It must acquire the full transaction being spent and verify its
>> hash against that which is given in the outpoint. This is an obstacle in
>> the implementation of lightweight air-gapped wallets and hardware wallets
>> in general. If the signature message would commit to the scriptPubKeys of
>> all transaction inputs, then the wallet would only need to acquire the
>> scriptPubKey of the output being spent without having to acquire and verify
>> the hash of the entire previous transaction. If an attacker would provide
>> an incorrect scriptPubKey, then that would cause the wallet to generate an
>> invalid signature message.
>>
>> Note that committing only to the scriptPubKey of the output being spent
>> is insufficient for this application, because the scriptPubKeys which are
>> needed to ascertain non-ownership of external inputs are precisely the ones
>> that would not be included in any of the signature messages produced by the
>> wallet.
>>
>> The obvious way to implement this is to add another hash to the signature
>> message:
>> sha_scriptPubKeys (32): the SHA256 of the serialization of all
>> scriptPubKeys of the previous outputs spent by this transaction.
>>
>> Cheers,
>> Andrew Kozlik
>>
>> [1]
>> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures

[ZmnSCPxj via bitcoin-dev]

Good morning CB,

> > This "as long as the inputs that should be separate are not co-spent" is 
> > precisely what mixdepths protect against, which is why I think some kind of 
> > mixdepth facility will still matter in CoinSwap.
> > Still, you have convinced me that, for the purpose of multi-transaction 
> > CoinSwap where you do not merge any of your coins, it is immaterial if the 
> > sub-transactions come from the same mixdepth or not.
> > And if you have to merge your coins (for instance, if you are a maker and 
> > your customer wants to get a UTXO that is larger than any you have on hand, 
> > you have to merge your coins), you just have to ensure they are in the same 
> > mixdepth.
> > Of course, you could be proposing some other construct --- perhaps you have 
> > some relational entry which says "you cannot merge coin A and coin B" which 
> > allows you to merge A C D or B C E, but not A B?
> > (I imagine this would make coin selection even harder, but I am not a 
> > mathematician and there may be some trivial solution to this.)
> > Now --- if you have two coins that cannot be merged in the same onchain tx, 
> > what happens when you swap them in a multi-tx CoinSwap with somebody else?
> > That somebody else does not know that information.
> > Instead, that somebody else must always assume that any coins it got from 
> > the same CoinSwap operation must not be safely mergeable (though they can 
> > still be used in the same swap together).
> > Coins received via receive addresses would also not be mergeable with any 
> > other coins, except coins to the same address (because coins in the same 
> > address already leak that they are owned by the same owner).
>
> Yes I guess you're right. This part about mixdepths requires further
> thought.
>
> CoinSwap can be combined with some kind of CoinJoin (most likely
> something similar to PayJoin or CoinJoinXT). That should help with the
> reasoning about co-spending inputs and mixdepths, because other inputs
> that are not owned by the taker will often be co-spent anyway.
>
> Regarding coins which mustn't be co-spent being coinswapped to somebody
> else, ideally that coinswap maker will receive coins from unrelated
> takers too, so will merge their coins along with those as well. Also the
> fact that a coinswap happened means there are two transactions between
> the taker's-inputs-which-mustnt-be-merged and them actually being merged.

One of those transactions (the second one) will be a 1-input 1-output tx (it 
moves the coin from bilateral control to unilateral control of Bob), which 
chain analysis already knows to be a self-transfer.
The first transaction will also usually be a 1-input 1-output tx as well (it 
moves the coin from unilateral of Alice to bilateral control) if you did not do 
any splitting or merging before providing the coin into the swap (for example 
if this comes from the taker, and the taker knows all the coins it wants to 
swap cannot be safely merged together).

If chain analysis keeps the heuristic "1-input 1-output is a self-payment 
because srsly who has an exact amount for a payment Bitcoin is volatile lol", 
then the resulting coins still are not safe to merge, because chain analysis 
will "pass through" the swap operation and if the two coins are later merged 
then they still end up *correctly* concluding the original coins were owned by 
the same owner.

Using a PayJoin construction for the second tx would help, but if the receiving 
end does not have a spare UTXO it can merge with (e.g. all its liquidity got 
tied up in the swap) then there might not be an opportunity to PayJoin.

There is also little that can be done about the first transaction, in case it 
ends up being a 1-input 1-output.

Suppose Alice the taker has a 1 BTC output and a 1 BTC output *and no other 
coins*, both of which it cannot safely merge, and it has to pay 1.2 BTC to 
Carol.
Alice then has to CoinSwap them to Bob the maker, requesting a 1.2 BTC output 
going to Carol and the rest in whatever loose change Bob has.
Alice then has to use two 1-input 1-output txes for each of its 1 BTC outputs 
(because it cannot merge them together) to put them into bilateral control.
Then Bob claims them from bilateral control with 1-input 1-output txes as well 
(it cannot merge them together, because that might break Alice privacy, and Bob 
might not have any other spare coins it can merge with the incoming funds).

Now, even if Bob PayJoins the second tx for both 1 BTC outputs, it still cannot 
merge the resulting joined coins together, because the "spent-together" 
analysis would still tie those coins as being owned by the same owner, it is 
simply that the surveillor will think the owner owns more coins than it 
actually does, but the two 1 BTC TXOs that Alice used to own are still analyzed 
as being owned by the same owner if they are ever merged.

What Alice could do, to "merge" its 1BTC coins together, would be to swap only 
one of the 1BTC coins first, for 

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

[Jeremy via bitcoin-dev]

Hi Andrew,

If you use SIGHASH_ALL it shall sign the COutPoints of all inputs which
commit to the scriptPubKeys of the txn.

Thus the 341 hash doesn't need to sign any additional data.

As a metadata protocol you can provide all input transactions to check the
scriptPubKeys.

Best,

Jeremy
--
@JeremyRubin 


On Thu, Apr 30, 2020 at 1:22 AM Andrew Kozlik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everyone,
>
> In the current draft of BIP-0341 [1] the signature message commits to the
> scriptPubKey of the output being spent by the input. I propose that the
> signature message should commit to the scriptPubKeys of *all* transaction
> inputs.
>
> In certain applications like CoinJoin, a wallet has to deal with
> transactions containing external inputs. To calculate the actual amount
> that the user is spending, the wallet needs to reliably determine for each
> input whether it belongs to the wallet or not. Without such a mechanism an
> adversary can fool the wallet into displaying incorrect information about
> the amount being spent, which can result in theft of user funds [2].
>
> In order to ascertain non-ownership of an input which is claimed to be
> external, the wallet needs the scriptPubKey of the previous output spent by
> this input. It must acquire the full transaction being spent and verify its
> hash against that which is given in the outpoint. This is an obstacle in
> the implementation of lightweight air-gapped wallets and hardware wallets
> in general. If the signature message would commit to the scriptPubKeys of
> all transaction inputs, then the wallet would only need to acquire the
> scriptPubKey of the output being spent without having to acquire and verify
> the hash of the entire previous transaction. If an attacker would provide
> an incorrect scriptPubKey, then that would cause the wallet to generate an
> invalid signature message.
>
> Note that committing only to the scriptPubKey of the output being spent is
> insufficient for this application, because the scriptPubKeys which are
> needed to ascertain non-ownership of external inputs are precisely the ones
> that would not be included in any of the signature messages produced by the
> wallet.
>
> The obvious way to implement this is to add another hash to the signature
> message:
> sha_scriptPubKeys (32): the SHA256 of the serialization of all
> scriptPubKeys of the previous outputs spent by this transaction.
>
> Cheers,
> Andrew Kozlik
>
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev