public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jl2012@xbt.hk
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Date: Thu, 23 Jul 2015 05:39:20 +0000	[thread overview]
Message-ID: <20150723053920.Horde.NFnYiomFYphgmxoOpN4phA3@server47.web-hosting.com> (raw)
In-Reply-To: <B4B9D029-06BB-4049-966F-A5F9F34C68F4@petertodd.org>


Quoting Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sorry, but I think you need to re-read my first message. What you've  
> written below has nothing to do with what I actually said re: how  
> you're BIP102 and associated pull-req doesn't measure miner consensus.
>
>

I think I have already answered this with my previous mail. If there  
is consensus among major exchanges and merchants, the preference of  
miners are not particularly relevant. A checkpoint could be  
implemented in a decentralized way to make sure miners of the original  
chain won't be able to overtake the new chain.

Bitcoin has no intrinsic value. Bitcoin has value because people are  
willing to exchange it with something really valuable (e.g. a pizza;  
or USD which could buy a pizza). If most bitcoin-accepting business  
agree to follow BIP102 and ONLY BIP102, then BIP102 is THE Bitcoin,  
and the original chain is just a dSHA256 alt-coin which one can't even  
merge mine with BIP102. Switching to BIP102 is the only economically  
viable choice for miners.

Having said that, a miner voting may still be useful. It is just to  
make sure enough miners are ready for the change, instead of measuring  
their consensus. For example, the new rule will be implemented 1) 1  
week after 70% of miners are ready; or 2) on 1 Feb 2016, whichever  
happens first.

For SPV wallets, they have to strengthen their security model after  
the BIP66 fork, anyway. They should be able to identify potential  
consensus fork in the network and stop accepting incoming txs when it  
is in doubt. My "version 0 flag block" proposal could be a good  
generic way to indicate a hardfork to SPV wallets. (see my previous  
email on this topic)



  reply	other threads:[~2015-07-23  5:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
2015-07-17 16:11 ` Andrew
2015-07-17 16:12 ` Tier Nolan
2015-07-17 16:14   ` Tier Nolan
2015-07-17 17:57 ` Ross Nicoll
2015-07-17 19:06   ` Chris Wardell
2015-07-17 19:13     ` Ross Nicoll
2015-07-19 22:51   ` Ross Nicoll
2015-07-21  9:26     ` Jorge Timón
2015-07-21 13:04       ` Peter Todd
2015-07-21 13:58         ` Peter Todd
2015-07-22 15:51           ` Tom Harding
2015-07-22 17:02           ` Sriram Karra
2015-07-22 17:40             ` Sriram Karra
2015-07-22 17:43           ` Jeff Garzik
2015-07-22 22:30             ` Peter Todd
2015-07-23  5:39               ` jl2012 [this message]
2015-07-22 17:00         ` jl2012
2015-07-21 22:05       ` Ross Nicoll
2015-07-23 11:24         ` Jorge Timón
2015-07-17 20:29 ` Luke Dashjr
2015-07-17 21:13   ` Angel Leon
2015-07-17 22:25   ` Tier Nolan
2015-07-18  9:22     ` Jorge Timón
2015-07-18  9:24       ` Jorge Timón
2015-07-24  8:52   ` Thomas Zander
2015-07-24  9:43     ` Slurms MacKenzie
2015-07-18  4:32 ` Venzen Khaosan
2015-07-17 22:40 Raystonn

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=20150723053920.Horde.NFnYiomFYphgmxoOpN4phA3@server47.web-hosting.com \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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