Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-26 🗒️ Summary of this message: Multi-signature ...
📅 Original date posted:2011-08-26
🗒️ Summary of this message: Multi-signature transactions are the fastest path to secure Bitcoin wallets. New address types may not matter to payers, and software can simplify key management. Eventually, senders may not have to attach transaction fees, and receivers can add fees as they see fit. Whitelisting basic CHECKMULTISIG forms is uncontroversial, and Bitcoin addresses need to contain an endpoint for second-factor verification to prevent malware attacks.
📝 Original message:> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
Agreed.
That said I'm not sure it makes sense for payers to care about the
details of how somebody is protecting their wallets (which is what new
address types means). It's possible for a users software to notice
inbound payments to a regular Bitcoin address and then immediately
respend them to multi-signed outputs. This way key management can be
simpler as you don't need to integrate it with your shopping cart
software or anything like that - you can just do the usual thing of
pre-generating a few hundred thousand addresses, fill up your cart
implementation and go. When a payment is received, your wallet
software can keep an eye on how much unlocked balance it has and start
locking value once it goes over a pre-set amount, or use any other
policy the user might have.
This fits with my belief that we'll eventually move away from senders
attaching tx fees, instead receivers will respend the fee-less
transaction adding whatever fee they believe is appropriate (eg, maybe
it's very low in the case of a buyer with good reputation, or higher
for unknown buyers). It doesn't make a whole lot of sense for buyers
to have to attach more fees just because the merchant is using complex
wallet policies.
Whitelisting the basic CHECKMULTISIG form (assuming it can be made to
work) seems uncontroversial, why not do it today? The forms designed
to make fancier addresses be embeddable inside QRcodes, can come later
if people feel it's necessary. I'm still not convinced it is.
Once malware can't just email wallets to the attacker, or steal the
keys when the user decrypts due to a second factor, the next easiest
attack is to that malware can rewrite addresses on-screen as it sees
fit, forwarding small payments so the user doesn't notice then
stealing a big one. To solve that, Bitcoin addresses need to contain
not only a pubkey[hash] but some kind of endpoint the second factor
can use to verify ownership of the key. It can be discussed later, I
don't think there are many possible designs here so it shouldn't be
too controversial.
Published at
2023-06-07 02:18:55Event JSON
{
"id": "27ef96180f3732885b29ef459c3dec6b0a92a62db0c2bbb7425504632d11f811",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686104335,
"kind": 1,
"tags": [
[
"e",
"391ebcb8eb3f9b5884cfbf66f4a99b12c015cc93baa9452c114d68f52d1168ec",
"",
"root"
],
[
"e",
"4740aead68c9e76001923c2c34e9a1233f6e41544db9e4ad97ff5d0a0ab85929",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2011-08-26\n🗒️ Summary of this message: Multi-signature transactions are the fastest path to secure Bitcoin wallets. New address types may not matter to payers, and software can simplify key management. Eventually, senders may not have to attach transaction fees, and receivers can add fees as they see fit. Whitelisting basic CHECKMULTISIG forms is uncontroversial, and Bitcoin addresses need to contain an endpoint for second-factor verification to prevent malware attacks.\n📝 Original message:\u003e It seems to me the fastest path to very secure, very-hard-to-lose\n\u003e bitcoin wallets is multi-signature transactions.\n\nAgreed.\n\nThat said I'm not sure it makes sense for payers to care about the\ndetails of how somebody is protecting their wallets (which is what new\naddress types means). It's possible for a users software to notice\ninbound payments to a regular Bitcoin address and then immediately\nrespend them to multi-signed outputs. This way key management can be\nsimpler as you don't need to integrate it with your shopping cart\nsoftware or anything like that - you can just do the usual thing of\npre-generating a few hundred thousand addresses, fill up your cart\nimplementation and go. When a payment is received, your wallet\nsoftware can keep an eye on how much unlocked balance it has and start\nlocking value once it goes over a pre-set amount, or use any other\npolicy the user might have.\n\nThis fits with my belief that we'll eventually move away from senders\nattaching tx fees, instead receivers will respend the fee-less\ntransaction adding whatever fee they believe is appropriate (eg, maybe\nit's very low in the case of a buyer with good reputation, or higher\nfor unknown buyers). It doesn't make a whole lot of sense for buyers\nto have to attach more fees just because the merchant is using complex\nwallet policies.\n\nWhitelisting the basic CHECKMULTISIG form (assuming it can be made to\nwork) seems uncontroversial, why not do it today? The forms designed\nto make fancier addresses be embeddable inside QRcodes, can come later\nif people feel it's necessary. I'm still not convinced it is.\n\nOnce malware can't just email wallets to the attacker, or steal the\nkeys when the user decrypts due to a second factor, the next easiest\nattack is to that malware can rewrite addresses on-screen as it sees\nfit, forwarding small payments so the user doesn't notice then\nstealing a big one. To solve that, Bitcoin addresses need to contain\nnot only a pubkey[hash] but some kind of endpoint the second factor\ncan use to verify ownership of the key. It can be discussed later, I\ndon't think there are many possible designs here so it shouldn't be\ntoo controversial.",
"sig": "95e572ab1c5fcba1f5a62c6f4b5894c8f9935f9e8babcff8e2bcbb03dd0d9a28a41e68e30c4135015411f73c3cc0a2d1f7e3faf05d423a924df749b115eb1d87"
}