theymos [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-24 🗒️ Summary of this message: The discussion ...
📅 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.
🗒️ 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.