From: Troy Benjegerdes <hozer@hozed.org>
To: Jeff Garzik <jgarzik@bitpay.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Date: Sun, 15 Feb 2015 15:25:12 -0600 [thread overview]
Message-ID: <20150215212512.GR14804@nl.grid.coop> (raw)
In-Reply-To: <CAJHLa0PkzG44JpuQoHVLUU8SR55LaJf5AwG=a7AjK2u7TAveOQ@mail.gmail.com>
On Thu, Feb 12, 2015 at 10:27:53AM -0500, Jeff Garzik wrote:
> Repeating past statements, it is acknowledged that Peter's scorched
> earth replace-by-fee proposal is aptly named, and would be widely
> anti-social on the current network.
>
> At a high level, we can see that this thread is contentious because
> this covers _what we want bitcoin to be_, and that is an opinion
> (versus engineering fact), and it varies from person to person.
I find Peter's proposal relatively mild. I'd prefer that instead of
exchanges going bankrupt, that there be direct blockchain support
for key revocation and 'burning' stolen coins, and an economic
ecosystem that supports insurance underwriters that pay out when
someone inevitably gets hacked. This would definitely be 'scorched
earth' at one level, but I think would make for a far more
transparent and friendly system.
> However, hope is the denial of reality...instead we should walk
> forward with our eyes open[1]. My interest in bitcoin originates from
> the science fiction concept of "credits"[2], a universal money that
> transcends national borders and even planets. That is what I hoped
> bitcoin would be. "universal payments" is both a laudable goal and a
> shopworn bitcoin marketing slogan.
>
> The fundamental engineering truths diverge from that misty goal:
> Bitcoin is a settlement system, by design.
Most money/payment systems include some method to reverse or undo
payments made in error. In these systems, the longer settlement times
you mention below are a feature, not a bug, and give more time for
a human to react to errors and system failures.
> The process of consensus "settles" upon a timeline of transactions,
> and this process -- by design -- is necessarily far from instant.
> Alt-coins that madly attempt 10-second block times etc. are simply a
> vain attempt to paper over this fundamental design attribute:
> consensus takes time.
>
> As such, the blockchain can never support All The Transactions, even
> if block size increases beyond 20MB. Further layers are -- by design
> -- necessary if we want to achieve the goal of a decentralized payment
> network capable of supporting full global traffic.
>
> Bitcoin payments are like IP packets -- one way, irreversible. For
> larger value transfers this attaches attendent risk of loss -- as
> we've seen in the field time & again. The world's citizens en masse
> will not speak to each other with bitcoin (IP packets), but rather
> with multiple layers (HTTP/TCP/IP) that enable safe and secure value
> transfer or added features such as instant transactions.
I see a world in which we have many blockchains, along with not-quite
blockchain things like ripple that approximate that vision you have
of 'credits'. But we cannot have one chain to rule them all, for there
are inherent engineering trade-offs that one chain can never resolve.
There appear to be some things we will never come to a consensus on,
such as transaction reversibility, or what the optimal money supply
algorithm is. However we might learn a great deal from sharing code
and ideas. So in that line, see my thoughts on reversibility [3][4]
> This opinion is not a conspiracy to "put the bankers back in charge"
> -- it is a simple acknowledgement of bitcoin's design. The consensus
> system settles on a timeline.
>
> Bitcoin transactions are, by definition, not instant.
> Zero confirmation transactions are, by definition, not secure.
>
> Proposals such as Oleg's are _necessary_ to fully build out the
> bitcoin system. Avoid short-sighted, short-term thinking that views
> the lowest layer (one-way value xfer) at the most optimal layer at
> which free persons will transact freely & instantly across planet
> Earth.
>
> It is foolish to think the entire world will connect directly to the
> P2P block network and broadcast all the morning coffees to all the
> miners. That's not how the system works. It is a settlement layer.
> We _must_ build decentralized layered solutions on top of bitcoin,
> rather than stuffing everything into bitcoin itself.
I'll say the same about not stuffing everthing on top of the same
blockchain. We might very well have coffee shops that take coffecoin.
But Bitcoin will never be able to scale out horizontally like altcoins
can.
>
> [1] http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot
> [2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html
[3] https://bitbucket.org/tmagik/catoshi/issue/24
[4] https://bitbucket.org/tmagik/catoshi/issue/27
>
> On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn <mike@plan99.net> wrote:
> > I know you will ignore this as usual, but the entire replace-by-fee folly is
> > based on your fundamental misunderstanding of miner incentives.
> >
> > Miners are not incentivised to earn the most money in the next block
> > possible. They are incentivised to maximise their return on investment.
> > Making Bitcoin much less useful reduces demand for the bitcoins they are
> > mining, reducing coinbase and fee income in future blocks. Quite possibly,
> > to the point where those miners are then making a loss.
> >
> > Your "scorched earth" plan is aptly named, as it's guaranteed to make
> > unconfirmed payments useless. If enough miners do it they will simply break
> > Bitcoin to the point where it's no longer an interesting payments system for
> > lots of people. Then miners who have equipment to pay off will be really
> > screwed, not to mention payment processors and all the investors in them.
> >
> > I'm sure you can confuse a few miners into thinking your ideas are a
> > super-duper way to maximise their income, and in the process might
> > facilitate a pile of payment fraud. But they aren't. This one is about as
> > sensible as your "let's never increase the block size" and "let's kill SPV
> > clients" crusades - badly thought out and bad for Bitcoin.
> >
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming. The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take a
> > look and join the conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
next prev parent reply other threads:[~2015-02-15 21:25 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd
2015-02-12 7:23 ` Tamas Blummer
2015-02-12 7:45 ` Peter Todd
2015-02-12 8:27 ` Tamas Blummer
2015-02-12 8:49 ` Peter Todd
2015-02-12 9:01 ` Tamas Blummer
2015-02-15 20:51 ` Troy Benjegerdes
2015-02-12 8:16 ` Alex Mizrahi
2015-02-12 11:58 ` Mike Hearn
2015-02-12 12:23 ` Natanael
2015-02-12 12:49 ` Mike Hearn
2015-02-12 13:02 ` Natanael
2015-02-12 13:44 ` Mike Hearn
2015-02-12 14:36 ` Natanael
2015-02-12 14:53 ` Mike Hearn
2015-02-12 15:20 ` Natanael
2015-02-12 15:30 ` Justus Ranvier
2015-02-12 13:36 ` Oleg Andreev
2015-02-12 12:52 ` Alex Mizrahi
2015-02-12 13:18 ` Mike Hearn
2015-02-12 13:45 ` Alex Mizrahi
2015-02-12 13:52 ` Mike Hearn
2015-02-12 14:04 ` Tamas Blummer
2015-02-12 14:16 ` Mike Hearn
2015-02-12 14:25 ` Tamas Blummer
2015-02-12 23:08 ` Tom Harding
2015-02-12 14:32 ` Alex Mizrahi
2015-02-12 15:15 ` Mike Hearn
2015-02-12 15:32 ` Natanael
2015-02-12 15:42 ` Mike Hearn
2015-02-12 15:54 ` Natanael
2015-02-12 16:57 ` Btc Drak
2015-02-12 17:24 ` Oleg Andreev
2015-02-12 18:11 ` Justus Ranvier
2015-02-12 18:37 ` Allen Piscitello
2015-02-12 19:15 ` Alan Reiner
2015-02-12 19:34 ` Justus Ranvier
2015-02-12 19:45 ` Peter Todd
2015-02-12 19:49 ` Justus Ranvier
2015-02-12 19:47 ` Allen Piscitello
2015-02-12 19:52 ` Justus Ranvier
2015-02-12 20:02 ` Natanael
2015-02-12 20:36 ` Allen Piscitello
2015-02-14 14:47 ` Ross Nicoll
2015-02-12 20:06 ` Peter Todd
2015-02-12 19:49 ` Gregory Maxwell
2015-02-12 20:18 ` Peter Todd
2015-02-13 11:34 ` Mike Hearn
2015-02-12 12:54 ` Tamas Blummer
2015-02-12 14:42 ` Alex Mizrahi
2015-02-12 15:27 ` Jeff Garzik
2015-02-15 21:25 ` Troy Benjegerdes [this message]
2015-02-15 21:40 ` Adam Gibson
2015-02-19 8:56 ` Troy Benjegerdes
2015-02-21 19:09 ` Jorge Timón
2015-02-21 20:30 ` Mark Friedenbach
2015-02-21 22:47 ` Jeff Garzik
2015-02-22 1:15 ` Peter Todd
2015-02-22 3:25 ` Jorge Timón
2015-02-22 4:06 ` Jeff Garzik
2015-02-22 11:41 ` Eric Lombrozo
2015-02-22 12:06 ` Eric Lombrozo
2015-02-22 13:41 ` Eric Lombrozo
2015-02-22 13:53 ` Peter Todd
2015-02-22 23:29 ` Eric Lombrozo
2015-02-24 1:11 ` Jeff Garzik
2015-03-01 17:59 ` Troy Benjegerdes
2015-03-01 19:05 ` Neil Fincham
2015-03-01 17:44 ` Troy Benjegerdes
2015-02-12 16:15 ` Lawrence Nahum
2015-02-12 18:14 ` Tom Harding
2015-02-12 21:40 ` Josh Lehan
2015-02-22 16:36 ` Tom Harding
2015-02-22 17:12 ` Peter Todd
2015-02-22 19:25 ` Tom Harding
2015-02-22 21:50 ` Peter Todd
2015-05-04 4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd
2015-05-05 2:23 ` Kevin Greene
2015-05-23 18:26 ` [Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet Peter Todd
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=20150215212512.GR14804@nl.grid.coop \
--to=hozer@hozed.org \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=jgarzik@bitpay.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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