Hi all,
On Tuesday, May 5, 2020 3:20 AM, Jonas Nick via bitcoin-dev
wrote:
> This is a reasonable suggestion. Committing to every spent scriptPubKey and
> therefore every element of the TxOut instead of just the amount makes sense
> conceptually. And it would be a small diff (~4 lines + rationa
This is a reasonable suggestion. Committing to every spent scriptPubKey and
therefore every element of the TxOut instead of just the amount makes sense
conceptually. And it would be a small diff (~4 lines + rationale) compared to
the current bip-taproot version.
As far aas I understand, coinjoin w
>
> 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
>
On Sat, May 2, 2020 at 10:26 AM Anthony Towns wrote:
>
> except that we'd arguably still be missing:
>
> is this a coinbase output? (Coin.fCoinBase)
> what was the height of the coin? (Coin.nHeight)
>
> Maybe committing to the coinbase flag would have some use, but committing
> to the hei
On Fri, May 01, 2020 at 08:23:07AM -0400, Russell O'Connor wrote:
> Regarding specifics, I personally think it would be better to keep the
> hashes of the ScriptPubKeys separate from the hashes of the input values.
I think Andrew's original suggestion achieves this:
>> The obvious way to implemen
> If you didn't verify the output scriptPubKeys, you would *only* be able
> to care about fees since you couldn't verify where any of the funds went?
> And you'd only be able to say fees are "at least x", since they could be
> more if one of the scriptPubKeys turned out to be OP_TRUE eg. That might
On Wed, Apr 29, 2020 at 04:57:46PM +0200, Andrew Kozlik via bitcoin-dev wrote:
> 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.
A wallet can easily check whether a scriptPubKey conta
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 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@
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
op
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
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
--
@Jere
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 d
13 matches
Mail list logo
