Re: [bitcoin-dev] {sign|verify}message replacement
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
Re: [bitcoin-dev] {sign|verify}message replacement
On 14 March 2018 5:46:55 AM GMT-04:00, Kalle Rosenbaum via bitcoin-dev wrote: >Thank you. > >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. > >/Kalle > >Sent from my Sinclair ZX81 > >Den 14 mars 2018 16:10 skrev "Karl Johan Alm via bitcoin-dev" < >bitcoin-dev@lists.linuxfoundation.org>: > >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 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. Cheers, aj -- Sent from my phone. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] {sign|verify}message replacement
Thank you. 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. /Kalle Sent from my Sinclair ZX81 Den 14 mars 2018 16:10 skrev "Karl Johan Alm via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: 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
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] {sign|verify}message replacement
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
