Jason Dreyzehner [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-21 📝 Original message:You might be interested in ...
📅 Original date posted:2017-12-21
📝 Original message:You might be interested in this proposal, which is very similar. The repo
contains a very basic implementation in typescript:
https://github.com/bitauth/bitauth2017/blob/master/bips/0-bitauth.mediawiki
https://github.com/bitauth/bitauth2017/
On Tue, Dec 19, 2017 at 4:59 PM Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> For what it’s worth, I think it would be quite easy to do better than the
> implied solution of rejiggering the message signing system to support
> non-P2PKH scripts. Instead, have the signature be an actual bitcoin
> transaction with inputs that have the script being signed. Use the salted
> hash of the message being signed as the FORKID as if this were a spin-off
> with replay protection. This accomplishes three things:
>
> (1) This enables signing by any infrastructure out there — including
> hardware wallets and 2FA signing services — that have enabled support for
> FORKID signing, which is a wide swath of the ecosystem because of Bitcoin
> Cash and Bitcoin Gold.
>
> (2) It generalizes the message signing to allow multi-party signing setups
> as complicated (via sighash, etc.) as those bitcoin transactions allow,
> using existing and future tools based on Partially Signed Bitcoin
> Transactions; and
>
> (3) It unifies a single approach for message signing, proof of reserve
> (where the inputs are actual UTXOs), and off-chain colored coins.
>
> There’s the issue of size efficiency, but for the single-party message
> signing application that can be handled by a BIP that specifies a template
> for constructing the pseudo-transaction and its inputs from a raw script.
>
> Mark
>
> > On Dec 19, 2017, at 1:36 PM, Pavol Rusnak via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> >> I know there are posts, and an issue opened against it, but is there
> >> anyone writing a BIP for Sign / Verify message against a SegWit address?
> >
> > Dan, are you still planning to write this BIP?
> >
> > --
> > Best Regards / S pozdravom,
> >
> > Pavol "stick" Rusnak
> > CTO, SatoshiLabs
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/d296ba4f/attachment.html>;
📝 Original message:You might be interested in this proposal, which is very similar. The repo
contains a very basic implementation in typescript:
https://github.com/bitauth/bitauth2017/blob/master/bips/0-bitauth.mediawiki
https://github.com/bitauth/bitauth2017/
On Tue, Dec 19, 2017 at 4:59 PM Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> For what it’s worth, I think it would be quite easy to do better than the
> implied solution of rejiggering the message signing system to support
> non-P2PKH scripts. Instead, have the signature be an actual bitcoin
> transaction with inputs that have the script being signed. Use the salted
> hash of the message being signed as the FORKID as if this were a spin-off
> with replay protection. This accomplishes three things:
>
> (1) This enables signing by any infrastructure out there — including
> hardware wallets and 2FA signing services — that have enabled support for
> FORKID signing, which is a wide swath of the ecosystem because of Bitcoin
> Cash and Bitcoin Gold.
>
> (2) It generalizes the message signing to allow multi-party signing setups
> as complicated (via sighash, etc.) as those bitcoin transactions allow,
> using existing and future tools based on Partially Signed Bitcoin
> Transactions; and
>
> (3) It unifies a single approach for message signing, proof of reserve
> (where the inputs are actual UTXOs), and off-chain colored coins.
>
> There’s the issue of size efficiency, but for the single-party message
> signing application that can be handled by a BIP that specifies a template
> for constructing the pseudo-transaction and its inputs from a raw script.
>
> Mark
>
> > On Dec 19, 2017, at 1:36 PM, Pavol Rusnak via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On 08/12/17 19:25, Dan Bryant via bitcoin-dev wrote:
> >> I know there are posts, and an issue opened against it, but is there
> >> anyone writing a BIP for Sign / Verify message against a SegWit address?
> >
> > Dan, are you still planning to write this BIP?
> >
> > --
> > Best Regards / S pozdravom,
> >
> > Pavol "stick" Rusnak
> > CTO, SatoshiLabs
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171221/d296ba4f/attachment.html>;