James MacWhyte [ARCHIVE] on Nostr: ๐ Original date posted:2018-10-08 ๐ Original message:Hello! A URI is useful as ...
๐
Original date posted:2018-10-08
๐ Original message:Hello!
A URI is useful as a standard for one-way communication, but on-chain
multisig requires many steps. multiple parties need to provide signatures,
and one party needs to aggregate all the signatures and publish the
transaction. This URI scheme would allow one to pass along a raw
transaction in one direction, but once the signer has signed the
transaction, what are they supposed to do with it? You might be thinking
you could include a callback URL, like BIP72 does, so the signer can pass
the signed transaction back to the organizer. However, BIP72 was created as
a backwards-compatible extension to BIP70, which was designed for one-way
communication. Since there is no way to be backwards compatible here, there
is no need to limit yourself to the URI system. Instead of creating a new
URI and using it for something it is not suited for, it would be better (in
my opinion) to find a different method that is better suited for two-way
communication.
On Thu, Oct 4, 2018 at 3:52 PM ใใฎใใกใ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi.
>
> I have an idea that subject.
>
> There are already BIP 21.
> But Multisig request URI is non exist.
>
> My idea is below:
>
> bitcoin-sigreq://{{rawtx}}?{{param}}
>
> rawtx: raw transaction (encoded by base64)
> param:
> - pubkey={{public key for sign key pair}}
> - hd_wallet_position={{path for HD wallet position}}
>
> This URI scheme is used for multisig request from website to user's local
> wallet.
>
> How do you think ?
> _______________________________________________
> 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/20181008/2520c954/attachment.html>;
๐ Original message:Hello!
A URI is useful as a standard for one-way communication, but on-chain
multisig requires many steps. multiple parties need to provide signatures,
and one party needs to aggregate all the signatures and publish the
transaction. This URI scheme would allow one to pass along a raw
transaction in one direction, but once the signer has signed the
transaction, what are they supposed to do with it? You might be thinking
you could include a callback URL, like BIP72 does, so the signer can pass
the signed transaction back to the organizer. However, BIP72 was created as
a backwards-compatible extension to BIP70, which was designed for one-way
communication. Since there is no way to be backwards compatible here, there
is no need to limit yourself to the URI system. Instead of creating a new
URI and using it for something it is not suited for, it would be better (in
my opinion) to find a different method that is better suited for two-way
communication.
On Thu, Oct 4, 2018 at 3:52 PM ใใฎใใกใ via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi.
>
> I have an idea that subject.
>
> There are already BIP 21.
> But Multisig request URI is non exist.
>
> My idea is below:
>
> bitcoin-sigreq://{{rawtx}}?{{param}}
>
> rawtx: raw transaction (encoded by base64)
> param:
> - pubkey={{public key for sign key pair}}
> - hd_wallet_position={{path for HD wallet position}}
>
> This URI scheme is used for multisig request from website to user's local
> wallet.
>
> How do you think ?
> _______________________________________________
> 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/20181008/2520c954/attachment.html>;