From: Mike Hearn <mike@plan99•net>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
Date: Fri, 26 Aug 2011 13:42:29 +0200 [thread overview]
Message-ID: <CANEZrP2FYjJXvB=kzu+wBcoGOyL=45QeDqLfyZONxYu-9M50Uw@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
> 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.
next prev parent reply other threads:[~2011-08-26 11:42 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 15:12 Gavin Andresen
2011-08-24 15:17 ` Rick Wesson
2011-08-24 15:45 ` Gregory Maxwell
2011-08-24 15:55 ` Rick Wesson
2011-08-24 16:05 ` Douglas Huff
2011-08-24 16:15 ` Luke-Jr
2011-08-24 16:46 ` Gregory Maxwell
2011-08-24 17:03 ` Luke-Jr
2011-08-24 17:07 ` Rick Wesson
2011-08-24 17:19 ` Gregory Maxwell
2011-08-24 17:40 ` Rick Wesson
2011-08-24 17:57 ` Gavin Andresen
2011-08-24 18:45 ` Jeff Garzik
2011-08-25 7:39 ` Michael Grønager
2011-08-25 17:18 ` Gavin Andresen
2011-08-26 10:50 ` Mike Hearn
2011-08-27 1:36 ` bgroff
2011-08-25 18:31 ` Gregory Maxwell
[not found] ` <20110825201026.GA21380@ulyssis.org>
2011-08-25 20:29 ` Gregory Maxwell
2011-08-25 21:06 ` Pieter Wuille
2011-08-24 17:03 ` theymos
2011-08-24 17:47 ` bgroff
2011-08-24 19:05 ` Christian Decker
2011-08-24 20:29 ` Gregory Maxwell
2011-08-24 22:27 ` Douglas Huff
2011-08-25 21:30 ` Christian Decker
2011-08-26 11:42 ` Mike Hearn [this message]
2011-08-26 19:44 ` Gavin Andresen
2011-08-27 1:15 ` bgroff
2011-08-24 16:18 Pieter Wuille
2011-08-24 16:26 ` Luke-Jr
2011-08-25 20:14 Pieter Wuille
2011-08-26 11:09 ` Mike Hearn
2011-08-26 21:30 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP2FYjJXvB=kzu+wBcoGOyL=45QeDqLfyZONxYu-9M50Uw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox