📅 Original date posted:2011-08-24
🗒️ Summary of this message: The discussion is about enabling new 'standard' multisignature transactions to prevent wallets from getting lost or stolen, but there is concern about taking too long to agree on the details.
📝 Original message:On Wed, 24 Aug 2011 11:12 -0400, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> To organize this discussion: first, does everybody agree?
Yes. The feature will be very good.
> I still think it is a good idea to enable a set of new 'standard'
> multisignature transactions, so they get relayed and included into
> blocks. I don't want to let "the perfect become the enemy of the
> good" -- does anybody disagree?
Please do enable any transactions that seem to be a possible solution.
Even if this client doesn't ever implement any of them, alternative
clients can try them.
> My biggest worry is we'll say "Sure, it'll only take a couple days to
> agree on how to do it right" and six months from now there is still
> no consensus on exactly which digest function should be used, or
> whether or not there should be a new opcode for arbitrary boolean
> expressions involving keypairs. And people's wallets continue to get
> lost or stolen.
I agree that something should be done with what we have now. It *will*
take months to properly figure out how to add chain-forking features for
this. If we want to consider all of the unrelated feature proposals, it
might take years of discussion...
However, as I said in the forum thread, I think it would be better for
people using this protection to receive at a normal address and then
create new transactions at their end. Then no one has to handle huge
addresses, and the sender will never have to pay abnormal fees or deal
with incompatibilities. There will be a short period of time when the
recipient's money is unprotected, but I think this is worth it. A better
scheme can be made later after chain-forking features are figured out.
theymos [ARCHIVE] /
npub10v…mper0
2023-06-07 02:18:35
in reply to nevent1q…0lj3
Author Public Key
npub10vt6y7m6shn8hfuj83zjlwcga4fky38kv73qz6xlcvtj4q7fjt0sqmper0Published at
2023-06-07 02:18:35Event JSON
{
"id": "4a74007bd5f8213f3c356430f33eb062507cfd22f36818fe119182d2a6c08b26",
"pubkey": "7b17a27b7a85e67ba7923c452fbb08ed536244f667a20168dfc3172a83c992df",
"created_at": 1686104315,
"kind": 1,
"tags": [
[
"e",
"391ebcb8eb3f9b5884cfbf66f4a99b12c015cc93baa9452c114d68f52d1168ec",
"",
"root"
],
[
"e",
"4d184b87b1422d46ddac1c331a3ca742950b366cbffb5c68eba306c13f22afc8",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2011-08-24\n🗒️ Summary of this message: The discussion is about enabling new 'standard' multisignature transactions to prevent wallets from getting lost or stolen, but there is concern about taking too long to agree on the details.\n📝 Original message:On Wed, 24 Aug 2011 11:12 -0400, \"Gavin Andresen\" \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e To organize this discussion: first, does everybody agree?\n\nYes. The feature will be very good.\n\n\u003e I still think it is a good idea to enable a set of new 'standard'\n\u003e multisignature transactions, so they get relayed and included into\n\u003e blocks. I don't want to let \"the perfect become the enemy of the\n\u003e good\" -- does anybody disagree?\n\nPlease do enable any transactions that seem to be a possible solution.\nEven if this client doesn't ever implement any of them, alternative\nclients can try them.\n\n\u003e My biggest worry is we'll say \"Sure, it'll only take a couple days to\n\u003e agree on how to do it right\" and six months from now there is still\n\u003e no consensus on exactly which digest function should be used, or\n\u003e whether or not there should be a new opcode for arbitrary boolean\n\u003e expressions involving keypairs. And people's wallets continue to get\n\u003e lost or stolen.\n\nI agree that something should be done with what we have now. It *will*\ntake months to properly figure out how to add chain-forking features for\nthis. If we want to consider all of the unrelated feature proposals, it\nmight take years of discussion...\n\nHowever, as I said in the forum thread, I think it would be better for\npeople using this protection to receive at a normal address and then\ncreate new transactions at their end. Then no one has to handle huge\naddresses, and the sender will never have to pay abnormal fees or deal\nwith incompatibilities. There will be a short period of time when the\nrecipient's money is unprotected, but I think this is worth it. A better\nscheme can be made later after chain-forking features are figured out.",
"sig": "cd7f77af8d80ff38f93915400096bf3f2f075bc7f020d375b3ffd0ce3fb9002af0fa12398e3cb59de5a9bbf6e1294055d9f18cc9bcf0160a9ce18661c0e7254a"
}