Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-22 📝 Original message:I should note that my ...
📅 Original date posted:2015-02-22
📝 Original message:I should note that my proposal does require a change to the consensus
rules...but getting bitcoin to scale will require this no matter what.
- Eric Lombrozo
On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo at gmail.com> wrote:
> It seems to me we're confusing two completely different motivations for
> double-spending. One is the ability to replace a fee, the other is the
> ability to replace outputs.
>
> If the double-spend were to merely add or remove inputs (but keep at least
> one input in common, of course), it seems fairly safe to assume it's the
> former, a genuine fee replacement. Even allowing for things like coinjoin,
> none of the payees would really care either way.
>
> Conversely, if at least one of the inputs were kept but none of the
> outputs were, we can be confident it's the the latter.
>
> It is possible to build a wallet that always does the former when doing
> fee replacement by using another transaction to create an output with
> exactly the additional desired fee.
>
> If we can clearly distinguish these two cases then the fee replacement
> case can be handled by relaying both and letting miners pick one or the
> other while the output replacement case could be handled by rewarding
> everything to a miner (essentially all outputs are voided...made
> unredeemable...and all inputs are added to coinbase) if the miner includes
> the two conflicting transactions in the same block.
>
> Wouldn't this essentially solve the problem?
>
> - Eric Lombrozo
> On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik at bitpay.com> wrote:
>
>> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik at bitpay.com>
>> wrote:
>> >> This isn't some theoretical exercise. Like it or not many use
>> >> insecure 0-conf transactions for rapid payments. Deploying something
>> >> that makes 0-conf transactions unusable would have a wide, negative
>> >> impact on present day bitcoin payments, thus "scorched earth"
>>
>> > And maybe by maintaining first seen policies we're harming the system
>> > in the long term by encouraging people to widely deploy systems based
>> > on extremely weak assumptions.
>>
>> Lacking a coded, reviewed alternative, that's only a platitude.
>> Widely used 0-conf payments are where we're at today. Simply ceasing
>> the "maintaining [of] first seen policies" alone is simply not a
>> realistic option. The negative impact to today's userbase would be
>> huge.
>>
>> Instant payments need a security upgrade, yes.
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/2f4660b3/attachment.html>;
📝 Original message:I should note that my proposal does require a change to the consensus
rules...but getting bitcoin to scale will require this no matter what.
- Eric Lombrozo
On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo at gmail.com> wrote:
> It seems to me we're confusing two completely different motivations for
> double-spending. One is the ability to replace a fee, the other is the
> ability to replace outputs.
>
> If the double-spend were to merely add or remove inputs (but keep at least
> one input in common, of course), it seems fairly safe to assume it's the
> former, a genuine fee replacement. Even allowing for things like coinjoin,
> none of the payees would really care either way.
>
> Conversely, if at least one of the inputs were kept but none of the
> outputs were, we can be confident it's the the latter.
>
> It is possible to build a wallet that always does the former when doing
> fee replacement by using another transaction to create an output with
> exactly the additional desired fee.
>
> If we can clearly distinguish these two cases then the fee replacement
> case can be handled by relaying both and letting miners pick one or the
> other while the output replacement case could be handled by rewarding
> everything to a miner (essentially all outputs are voided...made
> unredeemable...and all inputs are added to coinbase) if the miner includes
> the two conflicting transactions in the same block.
>
> Wouldn't this essentially solve the problem?
>
> - Eric Lombrozo
> On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik at bitpay.com> wrote:
>
>> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik at bitpay.com>
>> wrote:
>> >> This isn't some theoretical exercise. Like it or not many use
>> >> insecure 0-conf transactions for rapid payments. Deploying something
>> >> that makes 0-conf transactions unusable would have a wide, negative
>> >> impact on present day bitcoin payments, thus "scorched earth"
>>
>> > And maybe by maintaining first seen policies we're harming the system
>> > in the long term by encouraging people to widely deploy systems based
>> > on extremely weak assumptions.
>>
>> Lacking a coded, reviewed alternative, that's only a platitude.
>> Widely used 0-conf payments are where we're at today. Simply ceasing
>> the "maintaining [of] first seen policies" alone is simply not a
>> realistic option. The negative impact to today's userbase would be
>> huge.
>>
>> Instant payments need a security upgrade, yes.
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/2f4660b3/attachment.html>;