From: Peter Todd <pete@petertodd•org>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
Date: Sat, 6 Feb 2016 16:11:58 -0500 [thread overview]
Message-ID: <20160206211158.GA14053@muck> (raw)
In-Reply-To: <CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]
On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wrote:
> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace•org> wrote:
>
> >
> > It would probably be a good idea to have a security considerations
> > section
>
>
> Containing what? I'm not aware of any security considerations that are any
> different from any other consensus rules change.
I covered the security considerations unique to hard-forks on my blog:
https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
> > , also, is there a list of which exchange, library, wallet,
> > pool, stats server, hardware etc you have tested this change against?
> >
>
> That testing is happening by the exchange, library, wallet, etc providers
> themselves. There is a list on the Classic home page:
>
> https://bitcoinclassic.com/
How do we know any of this testing is actually being performed? I don't
currently know of any concrete testing actually done.
> > Do you have a rollback plan in the event the hard-fork triggers via
> > false voting as seemed to be prevalent during XT? (Or rollback just
> > as contingency if something unforseen goes wrong).
> >
>
> The only voting in this BIP is done by the miners, and that cannot be faked.
Are you unaware of Not Bitcoin XT?
https://bitcointalk.org/index.php?topic=1154520.0
> I can't imagine any even-remotely-likely sequence of events that would
> require a rollback, can you be more specific about what you are imagining?
> Miners suddenly getting cold feet?
See above.
Also, as the two coins are separate currencies and can easily trade
against each other in a 75%/25% split, it would be easy for the price to
diverge and hashing power to move.
In fact, I've been asked multiple times now by exchanges and other
players in this ecosystem for technical advice on how to split coins
across the chains effectively (easily done with nLockTime). Notably, the
exchanges who have asked me this - who hold customer funds on their
behalf - have informed me that their legal advice was that the
post-hard-fork coins are legally speaking separate currencies, and
customers must be given the opportunity to transact in them separately
if they choose too. Obviously, with a 75%/25% split, while block times
on the other chain will be slower, the chain is still quite useful and
nearly as secure as the main chain against 51% attack; why I personally
have suggested a 99% threshold:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012309.html
(remember that the threshold can always be soft-forked down)
It's also notable that millions of dollars of Bitcoin are voting agsast
the fork on the proof-of-stake voting site Bitcoinocracy.com While
obviously not comprehensive, the fact that a relatively obscure site
like it can achieve participation like that, even without an easy to use
user friendly interface.
> > How do you plan to monitor and manage security through the hard-fork?
> >
>
> I don't plan to monitor or manage anything; the Bitcoin network is
> self-monitoring and self-managing. Services like statoshi.info will do the
> monitoring, and miners and people and businesses will manage the network,
> as they do every day.
Please provide details on exactly how that's going to happen.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2016-02-06 21:12 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 20:51 Gavin Andresen
2016-02-05 22:36 ` Yifu Guo
2016-02-07 17:09 ` Gavin Andresen
2016-02-05 23:04 ` Btc Drak
2016-02-06 0:12 ` Luke Dashjr
2016-02-06 3:14 ` Jorge Timón
2016-02-06 15:37 ` Gavin Andresen
2016-02-06 17:01 ` Adam Back
2016-02-06 17:45 ` Gavin Andresen
2016-02-06 21:11 ` Peter Todd [this message]
2016-02-06 21:24 ` Peter Todd
2016-02-09 5:11 ` Samson Mow
2016-02-06 21:28 ` David Thomson
2016-02-07 18:49 ` Chris Priest
2016-02-06 17:09 ` Jorge Timón
2016-02-06 17:25 ` Tom Zander
2016-02-06 20:22 ` Chris Priest
2016-02-06 20:46 ` Luke Dashjr
2016-02-07 14:16 ` Gavin Andresen
2016-02-07 15:06 ` Alex Morcos
2016-02-07 16:54 ` Peter Todd
2016-02-07 15:19 ` Anthony Towns
2016-02-07 17:10 ` Jonathan Toomim
2016-02-07 17:24 ` jl2012
2016-02-07 17:56 ` Jonathan Toomim
2016-02-07 21:01 ` Luke Dashjr
2016-02-07 21:33 ` Steven Pine
2016-02-07 22:04 ` Corey Haddad
2016-02-07 22:25 ` Steven Pine
2016-02-06 20:36 ` Luke Dashjr
2016-02-06 22:22 ` Peter Todd
2016-02-07 5:21 ` Jannes Faber
2016-02-07 18:55 ` Jonathan Toomim
2016-02-07 19:03 ` Patrick Strateman
2016-02-07 19:19 ` Trevin Hofmann
2016-02-07 20:29 ` Tier Nolan
2016-02-09 13:59 ` Yifu Guo
2016-02-09 16:54 ` Gavin Andresen
2016-02-10 6:14 ` David Vorick
2016-02-10 6:36 ` Patrick Shirkey
2016-02-10 12:58 ` Tier Nolan
2016-02-07 11:37 ` Anthony Towns
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=20160206211158.GA14053@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--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