bgroff at lavabit.com [ARCHIVE] on Nostr: 📅 Original date posted:2011-06-22 🗒️ Summary of this message: Proposal for a ...
📅 Original date posted:2011-06-22
🗒️ Summary of this message: Proposal for a new type of bitcoin address that requires m of n signatures to spend. A use-case scenario for a 2-of-3 multisign address is presented.
📝 Original message:Gavin wrote:
> It would be spiffy to publish a new type of bitcoin address that is an
> "m of n address", that anybody could pay into, but would require m of
> n signatures to spend. Publishing a really really long address with
> all n public keys would work.
Here's a strawman use-case for a browser centric flow for a 2-of-3 scenario.
Funding:
* User is on Merchant site on the checkout page
* User selects a transaction Observer (I'm trying to get away from using
the word escrow, because the funds are not held by the third party)
* Merchant redirects to the Observer, passing in the Merchant's payout
address
* The User enters User's address
* Observer presents multisign address
"2,merchant-addr,user-addr,observer-addr" and terms and conditions - i.e.
under what circumstances the Observer will sign
* User copy/pastes the multisign address to their bitcoin client and sends
funds
* After some blocks go by, merchant ships
Redemption:
* Merchant reminds User to release funds
* User creates a partial tx paying out to merchant-addr and emails or
copy-pastes to Merchant
* Merchant signs and publishes the tx
Funding requires two pastes and redemption requires one. A browser
plug-in would reduce the User effort to a couple of confirmatory clicks -
"do you want to send X BTC to Merchant Y with Observer Z?" and "do you
want to release X BTC to Merchant Y?".
--
Bobby Groff
Published at
2023-06-07 01:21:03Event JSON
{
"id": "31fae924e03eb88b65d93eedafe9f9c76912300e42194e15a932e69a6f7ce8ec",
"pubkey": "fc38630711a8b1bf175abe9b428bbb6dec25a39bf3d75a91a411f204942572a4",
"created_at": 1686100863,
"kind": 1,
"tags": [
[
"e",
"612f4757c0c09c2f3ac4514e7e313d4f65cedff61756b948c8a32794951343ac",
"",
"root"
],
[
"e",
"1bc459f0d0c80a768084d882c01f1092c847afb5e08ae8e7b4c5f5935a878fde",
"",
"reply"
],
[
"p",
"fc38630711a8b1bf175abe9b428bbb6dec25a39bf3d75a91a411f204942572a4"
]
],
"content": "📅 Original date posted:2011-06-22\n🗒️ Summary of this message: Proposal for a new type of bitcoin address that requires m of n signatures to spend. A use-case scenario for a 2-of-3 multisign address is presented.\n📝 Original message:Gavin wrote:\n\n\u003e It would be spiffy to publish a new type of bitcoin address that is an\n\u003e \"m of n address\", that anybody could pay into, but would require m of\n\u003e n signatures to spend. Publishing a really really long address with\n\u003e all n public keys would work.\n\nHere's a strawman use-case for a browser centric flow for a 2-of-3 scenario.\n\nFunding:\n\n* User is on Merchant site on the checkout page\n* User selects a transaction Observer (I'm trying to get away from using\nthe word escrow, because the funds are not held by the third party)\n* Merchant redirects to the Observer, passing in the Merchant's payout\naddress\n* The User enters User's address\n* Observer presents multisign address\n\"2,merchant-addr,user-addr,observer-addr\" and terms and conditions - i.e.\nunder what circumstances the Observer will sign\n* User copy/pastes the multisign address to their bitcoin client and sends\nfunds\n* After some blocks go by, merchant ships\n\nRedemption:\n\n* Merchant reminds User to release funds\n* User creates a partial tx paying out to merchant-addr and emails or\ncopy-pastes to Merchant\n* Merchant signs and publishes the tx\n\nFunding requires two pastes and redemption requires one. A browser\nplug-in would reduce the User effort to a couple of confirmatory clicks -\n\"do you want to send X BTC to Merchant Y with Observer Z?\" and \"do you\nwant to release X BTC to Merchant Y?\".\n\n--\nBobby Groff",
"sig": "2dba75f01213cb817fdec4df8f5a39ad6eeefcd6d6e18d5848bd2586adeeb8dd905ac705d9739d883d42581df688d4c7f5d2e13d039af6ec1d2cc8925e7a0b47"
}