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:38:13Event JSON
{
"id": "8d6200cf3b208058a7dd7352e091a26288dbf583aa14474af8d7f925f4e9f9b9",
"pubkey": "fc38630711a8b1bf175abe9b428bbb6dec25a39bf3d75a91a411f204942572a4",
"created_at": 1686101893,
"kind": 1,
"tags": [
[
"e",
"f8aa9d5975dbd3062e3c6c30dcbe2bf4909da9f4f0e974b1d2c55be2b94a5b11",
"",
"root"
],
[
"e",
"9bc3b42023d23b1508df6d8ff2b24f6b71e9eea9ddf4c4afa32e0cb8d7588363",
"",
"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": "c107136c1e12103d6a550f15dc5ad21d6661adf63c25cd3140e7eaf3875992ccf813c0a2c3c40edd4902653fe1c5d5bfe6503ab6e45027c50cb3bec883ae8922"
}