On Sunday, February 22, 2015, Peter Todd <pete@petertodd.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo <elombrozo@gmail.com> wrote:
>In case it wasn't clear in my earlier post, there's of course a third
>possibility - namely, some outputs are kept but not all. Here, it is
>generally impossible to tell whether the motivation was fee
>replacement,
>output replacement, or both. My proposal is to always treat these
>instances
>as output replacement and punish the sender. The sender needs to make
>it
>unambiguously clear it's only a fee replacement by creating a new
>transaction that produces an output with the desired extra fee and then
>adding an input that spends it to the original transaction.
That's a really old idea - I proposed it about two years ago. The optimal way is to allow any txout to be replaced with one with an equal or greater nValue and same scriptPubKey, as well as additional txouts added. (obviously so long as none are removed)
That won't work because in general it is impossible to know which transaction is the original. Did we add outputs to transaction A? Or remove outputs from transaction B?
Alas, there's lots of situations where this restricts you from doing useful things, for instance collapsing multiple payments into one by repeated updating to reduce tx size. Equally the benefit is marginal at best given how insecure unconfirmed transactions are - breaking what is already broken isn't a negative.
I think you're unnecessarily complicating use cases.
As for 0-conf security, there are instances where 0-conf transactions make a lot of sense - i.e. paying for utilities, ISP, web hosting, or other such services which could be immediately shut off upon detection of a double-spend.
-----BEGIN PGP SIGNATURE-----
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O
AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3
YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr
GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn
pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ
NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl
NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs=
=1vbN
-----END PGP SIGNATURE-----