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

Pieter, Thanks for the feedback. Comments below: On Mon, Mar 26, 2018 at 5:53 PM, Pieter Wuille wrote: > One solution is to include a version number in the signature, which > explicitly corresponds to a set of validation flags. When the version number > is something a

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

Hello, Thanks for starting a discussion about this idea. A few comments inline: On Wed, Mar 14, 2018 at 1:09 AM, Karl Johan Alm via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > I am considering writing a replacement for the message signing tools > that are currently

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

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

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

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

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

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

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

> > 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

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

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

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

ent: 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

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

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

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

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

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

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

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

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

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

[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*.