Re: [bitcoin-dev] {sign|verify}message replacement

[Karl Johan Alm via bitcoin-dev]

On Fri, Mar 16, 2018 at 1:59 AM, Greg Sanders  wrote:
> Sorry if I missed the rationale earlier, but why not just do a transaction,
> with a FORKID specifically for this? Then a node can have a mempool
> acceptance test that returns true even if the signature is not valid as per
> Bitcoin consensus, but only due to the FORKID?
>
> This way basically any wallet can support this provided generic FORKID
> support.

You'd basically have to provide an entire transaction rather than just
the signature, so there's some overhead. (Copy-pasting may become
unwieldy quicker.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] {sign|verify}message replacement

[Greg Sanders via bitcoin-dev]

Sorry if I missed the rationale earlier, but why not just do a transaction,
with a FORKID specifically for this? Then a node can have a mempool
acceptance test that returns true even if the signature is not valid as per
Bitcoin consensus, but only due to the FORKID?

This way basically any wallet can support this provided generic FORKID
support.

On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr  wrote:
> > Not necessarily specific UTXOs (that would contradict fungibility, as
> well as
> > be impossible for hot/cold wallet separation), but just to prove funds
> are
> > available. The current sign message cannot be used to prove present
> possession
> > of funds, only that you receive funds.
>
> By saying "not necessarily specific UTXOs", are you saying it may be
> spent outputs? I'm a little confused I think.
>
> On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen  wrote:
> > In this general signing-a-script context, I think a verifier might want
> to
> > see the time conditions under which it may be spent. The proof container
> > could include an optional nLockTime which defaults to 0 and nSequence
> which
> > defaults to 0x...
>
> Good point!
>
> >> I think it would just use the default (SIGHASH_ALL?) for simplicity.
> >> Is there a good reason to tweak it?
> >
> > I took another look and there should definitely be a byte appended to the
> > end of the sig so that the encoding checks pass, but I think it might as
> > well be a 0x00 byte since it's not actually a sighash flag.
>
> I think the sighash flag affects the outcome of the actual
> verification, but I could be mistaken.
>
> -Kalle.
> ___
> 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] {sign|verify}message replacement

[Karl Johan Alm via bitcoin-dev]

On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr  wrote:
> Not necessarily specific UTXOs (that would contradict fungibility, as well as
> be impossible for hot/cold wallet separation), but just to prove funds are
> available. The current sign message cannot be used to prove present possession
> of funds, only that you receive funds.

By saying "not necessarily specific UTXOs", are you saying it may be
spent outputs? I'm a little confused I think.

On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen  wrote:
> In this general signing-a-script context, I think a verifier might want to
> see the time conditions under which it may be spent. The proof container
> could include an optional nLockTime which defaults to 0 and nSequence which
> defaults to 0x...

Good point!

>> I think it would just use the default (SIGHASH_ALL?) for simplicity.
>> Is there a good reason to tweak it?
>
> I took another look and there should definitely be a byte appended to the
> end of the sig so that the encoding checks pass, but I think it might as
> well be a 0x00 byte since it's not actually a sighash flag.

I think the sighash flag affects the outcome of the actual
verification, but I could be mistaken.

-Kalle.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] {sign|verify}message replacement

[Jim Posen via bitcoin-dev]

>
> Good question.. Since you don't really have the input(s), I think it's
> fine to always assume sufficient time/height on CLTV/CSV checks.
>

In this general signing-a-script context, I think a verifier might want to
see the time conditions under which it may be spent. The proof container
could include an optional nLockTime which defaults to 0 and nSequence which
defaults to 0x...


> I think it would just use the default (SIGHASH_ALL?) for simplicity.
> Is there a good reason to tweak it?
>

I took another look and there should definitely be a byte appended to the
end of the sig so that the encoding checks pass, but I think it might as
well be a 0x00 byte since it's not actually a sighash flag.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] version.relay behavior change

[Andrew Chow via bitcoin-dev]

I don't think the nodes that you are connecting to that have this
behavior are actually forked from Bitcoin Core. It seems more like fake
nodes - nodes that don't actually do any verification or follow the
protocol. Such fake nodes can set whatever user agent they want, common
ones being Bitcoin Core's user agents.

IMO your best solution would be to drop peers for protocol noncompliance.

Andrew


On 03/15/2018 05:17 AM, Eric Voskuil wrote:
> Thanks for the reply Andrew. I’ve reviewed the relevant Core sources
> and I do not see any problem. We have also synced against a Core node
> locally and not seen the problem.
>
> The reason I suspected it was Core is that it is very common and all
> of the User Agents are consistent (with an occasional exception for
> forked nodes). So there’s no easy way to determine what sort of nodes
> we are seeing. 
>
> We tend to cycle through many more connections during sync than a Core
> node, so may just be seeing it more frequently, but I assume Core
> would log this behavior as well. Even so, seeing that wouldn’t help
> much. I’m as certain as I can be at this point that we are setting the
> flag and version correctly (and that we do not set bip37 filters).
>
> This behavior started infrequently with 0.14.0 peers and has become
> more common over time. Just wondering at this point what fork would
> report as Core and be that common? We used to drop peers that did this
> (for protocol noncompliance), and I’m considering reinstating that
> behavior.
>
> e
>
> On Mar 9, 2018, at 16:33, Andrew Chow via bitcoin-dev
>  > wrote:
>
>> Looking through the code, I don't think that this behavior has
>> changed. Are you sure that you are actually connected to
>> Satoshi:0.15.0 nodes and not a node that has simply set their
>> user-agent to that (i.e. not a real Satoshi:0.15.0 node)?
>>
>> If what you are seeing is true, it is likely a bug and not an
>> intentional change. In that case, can you provide specific details on
>> how to reproduce?
>>
>> Andrew
>>
>>
>> On 03/09/2018 02:50 AM, Eric Voskuil via bitcoin-dev wrote:
>>> /Satoshi:0.15.0/ and later nodes appear to be no longer honoring the
>>> version.relay=false flag (BIP37). Could someone familiar with the change
>>> please explain the rational?
>>>
>>> Thanks,
>>>
>>> e
>>>
>>>
>>>
>>> ___
>>> 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] {sign|verify}message replacement

[Luke Dashjr via bitcoin-dev]

On Thursday 15 March 2018 7:36:48 AM Karl Johan Alm wrote:
> On Wed, Mar 14, 2018 at 12:36 PM, Luke Dashjr  wrote:
> > Ideally, it should support not only just "proof I receive at this
> > address", but also "proof of funds" (as a separate feature) since this
> > is a popular misuse of the current message signing (which doesn't
> > actually prove funds at all). To do this, it needs to be capable of
> > signing for multiple inputs.
> 
> Re-reading this, I think what you mean is it should be possible to
> create a proof for (a) specific UTXO(s), hence "inputs". That sounds
> pretty useful, yeah!

Not necessarily specific UTXOs (that would contradict fungibility, as well as 
be impossible for hot/cold wallet separation), but just to prove funds are 
available. The current sign message cannot be used to prove present possession 
of funds, only that you receive funds.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] {sign|verify}message replacement

[Damian Williamson via bitcoin-dev]

That is very helpful Luke. I would not have been concerned if it was necessary 
to sign multiple times for multiple utxo's on different addresses but, since it 
is a feature it may as well be best usable. Signing for multiple inputs 
verifying that you have the priv key for each in your wallet is certainly 
usable for this popular misuse.


>Ideally, it should support not only just "proof I receive at this address",
but also "proof of funds" (as a separate feature) since this is a popular
misuse of the current message signing (which doesn't actually prove funds at
all). To do this, it needs to be capable of signing for multiple inputs.


From: bitcoin-dev-boun...@lists.linuxfoundation.org 
 on behalf of Luke Dashjr via 
bitcoin-dev 
Sent: Wednesday, 14 March 2018 11:36:47 PM
To: Karl Johan Alm; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] {sign|verify}message replacement

I don't see a need for a new RPC interface, just a new signature format.

Ideally, it should support not only just "proof I receive at this address",
but also "proof of funds" (as a separate feature) since this is a popular
misuse of the current message signing (which doesn't actually prove funds at
all). To do this, it needs to be capable of signing for multiple inputs.

Preferably, it should also avoid disclosing the public key for existing or
future UTXOs. But I don't think it's possible to avoid this without something
MAST-like first. Perhaps it can be a MAST upgrade later on, but the new
signature scheme should probably be designed with it in mind.

Luke


On Wednesday 14 March 2018 8:09:20 AM Karl Johan Alm via bitcoin-dev wrote:
> Hello,
>
> I am considering writing a replacement for the message signing tools
> that are currently broken for all but the legacy 1xx addresses. The
> approach (suggested by Pieter Wuille) is to do a script based
> approach. This does not seem to require a lot of effort for
> implementing in Bitcoin Core*. Below is my proposal for this system:
>
> A new structure SignatureProof is added, which is a simple scriptSig &
> witnessProgram container that can be serialized. This is passed out
> from/into the signer/verifier.
>
> RPC commands:
>
> sign   [=false]
>
> Generates a signature proof for  using the same method that
> would be used to spend coins sent to .**
>
> verify[=false]
>
> Deserializes and executes the proof using a custom signature checker
> whose sighash is derived from . Returns true if the check
> succeeds, and false otherwise. The scriptPubKey is derived directly
> from .**
>
> Feedback welcome.
>
> -Kalle.
>
> (*) Looks like you can simply use VerifyScript with a new signature
> checker class. (h/t Nicolas Dorier)
> (**) If  is true,  is the sighash, otherwise
> sighash=sha256d(message).
> ___
> 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] version.relay behavior change

[Eric Voskuil via bitcoin-dev]

Thanks for the reply Andrew. I’ve reviewed the relevant Core sources and I do 
not see any problem. We have also synced against a Core node locally and not 
seen the problem.

The reason I suspected it was Core is that it is very common and all of the 
User Agents are consistent (with an occasional exception for forked nodes). So 
there’s no easy way to determine what sort of nodes we are seeing. 

We tend to cycle through many more connections during sync than a Core node, so 
may just be seeing it more frequently, but I assume Core would log this 
behavior as well. Even so, seeing that wouldn’t help much. I’m as certain as I 
can be at this point that we are setting the flag and version correctly (and 
that we do not set bip37 filters).

This behavior started infrequently with 0.14.0 peers and has become more common 
over time. Just wondering at this point what fork would report as Core and be 
that common? We used to drop peers that did this (for protocol noncompliance), 
and I’m considering reinstating that behavior.

e

> On Mar 9, 2018, at 16:33, Andrew Chow via bitcoin-dev 
>  wrote:
> 
> Looking through the code, I don't think that this behavior has changed. Are 
> you sure that you are actually connected to Satoshi:0.15.0 nodes and not a 
> node that has simply set their user-agent to that (i.e. not a real 
> Satoshi:0.15.0 node)?
> 
> If what you are seeing is true, it is likely a bug and not an intentional 
> change. In that case, can you provide specific details on how to reproduce?
> 
> Andrew
> 
>> On 03/09/2018 02:50 AM, Eric Voskuil via bitcoin-dev wrote:
>> /Satoshi:0.15.0/ and later nodes appear to be no longer honoring the
>> version.relay=false flag (BIP37). Could someone familiar with the change
>> please explain the rational?
>> 
>> Thanks,
>> 
>> e
>> 
>> 
>> 
>> ___
>> 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] {sign|verify}message replacement

[Jim Posen via bitcoin-dev]

I like this proposal, it seems sufficiently general.

How are scripts with OP_CLTV and OP_CSV handled by verifiers? Do they
always succeed? Or should an nLockTime and nSequence also be included in
the proof in a way that can be parsed out and displayed to verifiers?

I assume any signatures in the scriptSig/witness data would have no sighash
type?

On Wed, Mar 14, 2018 at 8:01 PM, Karl Johan Alm via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Mar 14, 2018 at 5:46 AM, Kalle Rosenbaum 
> wrote:
> > I can't really see from your proposal if you had thought of this: A soft
> > fork can make old nodes accept invalid message signatures as valid. For
> > example, a "signer" can use a witness version unknown to the verifier to
> > fool the verifier. Witness version is detectable (just reject unknown
> > witness versions)  but there may be more subtle changes. Segwit was not
> > "detectable" in that way, for example.
> >
> > This is the reason why I withdrew BIP120. If you have thought about the
> > above, I'd be very interested.
>
> I'm not sure I see the problem. The scriptPubKey is derived directly
> from the address in all cases, which means the unknown witness version
> would have to be committed to in the address itself.
>
> So yeah, I can make a P2SH address with a witness version > 0 and a to
> me unknown pubkey and then fool you into thinking I own it, but I
> don't really see why you'd ultimately care. In other words, if I can
> SPEND funds sent to that address today, I can prove that I can spend
> today, which is the purpose of the tool, I think.
>
> For the case where the witness version HAS been upgraded, the above
> still applies, but I'm not sure it's a big issue. And it doesn't
> really require an old node. I just need to set witness version >
> current witness version and the problem applies to all nodes.
>
> On Wed, Mar 14, 2018 at 8:36 AM, Luke Dashjr  wrote:
> > I don't see a need for a new RPC interface, just a new signature format.
>
> All right.
>
> > Ideally, it should support not only just "proof I receive at this
> address",
> > but also "proof of funds" (as a separate feature) since this is a popular
> > misuse of the current message signing (which doesn't actually prove
> funds at
> > all). To do this, it needs to be capable of signing for multiple inputs.
>
> I assume by inputs you mean addresses/keys. The address field could
> optionally be an array. That'd be enough?
>
> > Preferably, it should also avoid disclosing the public key for existing
> or
> > future UTXOs. But I don't think it's possible to avoid this without
> something
> > MAST-like first. Perhaps it can be a MAST upgrade later on, but the new
> > signature scheme should probably be designed with it in mind.
>
> I'd love to not have to reveal the public key, but I'm not sure how it
> would be done, even with MAST.
>
> On Wed, Mar 14, 2018 at 12:12 PM, Anthony Towns  wrote:
> > Wouldn't it be sufficient for old nodes to check for standardness of the
> spending script and report non-standard scripts as either invalid outright,
> or at least highly questionable? That should prevent confusion as long as
> soft forks are only making nonstandard behaviours invalid.
>
> That seems sensible to me. A warning would probably be useful, in case
> the verifier is running old software.
>
> -Kalle.
> ___
> 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] {sign|verify}message replacement

[Karl Johan Alm via bitcoin-dev]

On Wed, Mar 14, 2018 at 12:36 PM, Luke Dashjr  wrote:
> Ideally, it should support not only just "proof I receive at this address",
> but also "proof of funds" (as a separate feature) since this is a popular
> misuse of the current message signing (which doesn't actually prove funds at
> all). To do this, it needs to be capable of signing for multiple inputs.

Re-reading this, I think what you mean is it should be possible to
create a proof for (a) specific UTXO(s), hence "inputs". That sounds
pretty useful, yeah!

So you could provide a mix of addresses and inputs (as txid:vout) and
it would generate a proof that signs the message for each input
(taking scriptPubKey from address or from the UTXO data directly on
the blockchain).

-Kalle.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] {sign|verify}message replacement

[Karl Johan Alm via bitcoin-dev]

On Thu, Mar 15, 2018 at 6:43 AM, Jim Posen  wrote:
> How are scripts with OP_CLTV and OP_CSV handled by verifiers? Do they always
> succeed? Or should an nLockTime and nSequence also be included in the proof
> in a way that can be parsed out and displayed to verifiers?

Good question.. Since you don't really have the input(s), I think it's
fine to always assume sufficient time/height on CLTV/CSV checks.

> I assume any signatures in the scriptSig/witness data would have no sighash
> type?

I think it would just use the default (SIGHASH_ALL?) for simplicity.
Is there a good reason to tweak it?

-Kalle.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev