📅 Original date posted:2011-06-22
🗒️ Summary of this message: A new type of bitcoin payment address is proposed for an "m of n address" that requires m of n signatures to spend, making it easier to fund an escrow.
📝 Original message:...
>> I think all of these could use a new type of bitcoin payment address;
>> it might make sense for THAT to be generic, maybe containing:
>> version byte
>> m
>> n
>> hash of xor of all n public keys
>> checksum
>
> I don't understand what this is for. For triggering such a transaction
> via the UI, I think establishing a higher level protocol would be
> needed. It's a separate step.
You're right, it doesn't make sense. The use case I would like to work is:
I setup an escrow that requires m of n signatures to release funds,
securely getting public keys from the other n-1 parties.
Now we all need to fund the escrow. Or maybe other people can fund the
escrow (it just takes m of n of us to decide when/how/where to spend
the funds).
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.
It would be great if the "higher level protocol" for pay-to-escrow was
just get a bitcoin address via https (or other secure mechanism), like
we do now for pay-to-single-party. Where the person you're paying has
their own mechanisms for generating or fetching/authenticating the
public keys, and knows which bitcoin addresses they've published.
All of which makes me wonder if the straightforward "n PUBKEYS m
CHECKMULTISIG" transaction type is the right thing to do.
Following the pattern of our standard DUP HASH160 etc. transaction
type, maybe 2 of 2 and 2 of three should be:
2DUP ADD HASH160 ...hash(pubkey1+2)... EQUALVERIFY 2 2 ROLL CHECKMULTISIGVERIFY
3DUP ADD ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL
CHECKMULTISIGVERIFY
Spending those transactions would mean putting the m signatures and
the n public keys in the TxIn, but sending funds you'd only need the
hash of the sum of the public keys.
--
--
Gavin Andresen
http://clearcoin.com/
Gavin Andresen [ARCHIVE] /
npub1s4…d44kw
2023-06-07 01:20:50
in reply to nevent1q…4xhr
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 01:20:50Event JSON
{
"id": "9f41610cb22ad61d878de99ecb4e9f74375bf6bc567068548886c92fab9c9b6b",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686100850,
"kind": 1,
"tags": [
[
"e",
"612f4757c0c09c2f3ac4514e7e313d4f65cedff61756b948c8a32794951343ac",
"",
"root"
],
[
"e",
"be87ce040bfd413090cc17d651dc16184e1ec5af3c9d7088b075f0410ae99495",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2011-06-22\n🗒️ Summary of this message: A new type of bitcoin payment address is proposed for an \"m of n address\" that requires m of n signatures to spend, making it easier to fund an escrow.\n📝 Original message:...\n\u003e\u003e I think all of these could use a new type of bitcoin payment address;\n\u003e\u003e it might make sense for THAT to be generic, maybe containing:\n\u003e\u003e version byte\n\u003e\u003e m\n\u003e\u003e n\n\u003e\u003e hash of xor of all n public keys\n\u003e\u003e checksum\n\u003e\n\u003e I don't understand what this is for. For triggering such a transaction\n\u003e via the UI, I think establishing a higher level protocol would be\n\u003e needed. It's a separate step.\n\nYou're right, it doesn't make sense. The use case I would like to work is:\n\nI setup an escrow that requires m of n signatures to release funds,\nsecurely getting public keys from the other n-1 parties.\n\nNow we all need to fund the escrow. Or maybe other people can fund the\nescrow (it just takes m of n of us to decide when/how/where to spend\nthe funds).\n\nIt would be spiffy to publish a new type of bitcoin address that is an\n\"m of n address\", that anybody could pay into, but would require m of\nn signatures to spend. Publishing a really really long address with\nall n public keys would work.\n\nIt would be great if the \"higher level protocol\" for pay-to-escrow was\njust get a bitcoin address via https (or other secure mechanism), like\nwe do now for pay-to-single-party. Where the person you're paying has\ntheir own mechanisms for generating or fetching/authenticating the\npublic keys, and knows which bitcoin addresses they've published.\n\nAll of which makes me wonder if the straightforward \"n PUBKEYS m\nCHECKMULTISIG\" transaction type is the right thing to do.\nFollowing the pattern of our standard DUP HASH160 etc. transaction\ntype, maybe 2 of 2 and 2 of three should be:\n\n2DUP ADD HASH160 ...hash(pubkey1+2)... EQUALVERIFY 2 2 ROLL CHECKMULTISIGVERIFY\n3DUP ADD ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL\nCHECKMULTISIGVERIFY\n\nSpending those transactions would mean putting the m signatures and\nthe n public keys in the TxIn, but sending funds you'd only need the\nhash of the sum of the public keys.\n\n-- \n--\nGavin Andresen\nhttp://clearcoin.com/",
"sig": "c152b5414a987596b42857707730d64a4172870b6e2498260f6d9f05080c230717e4c5308ace99c5e03370cad2375664eeba0f19d11ec36b1e8db35c7350e865"
}