public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gavin Andresen <gavinandresen@gmail.com>
To: Adam Back <adam@cypherspace.org>
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 12:45:14 -0500	[thread overview]
Message-ID: <CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTGu1EtVxRYTxLBpE-0zWH59dnQa1zst9p9vdmbCckBjtQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

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 can write a blog post summarizing our slack discussion of SPV security
immediately after the first greater-than-1mb-block if you like).



> , 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/


>
> 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 talking about people spinning up pseudo-full-nodes that fake the
user-agent?

As I said, there are people who have said they will spin up thousands of
full nodes to help prevent possible Sybil attacks which would become
marginally easier to accomplish immediately after the first >1mb block was
produced and full nodes that hadn't upgraded were left behind.

Would Blockstream be willing to help out by running a dozen or two extra
full nodes?

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?


> 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.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 3386 bytes --]

  reply	other threads:[~2016-02-06 17:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes 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 [this message]
2016-02-06 21:11           ` Peter Todd
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=CABsx9T2AUwDdz3JowpQYeusDgCBwfNFCDz0Kfut9ffT6gSaGeQ@mail.gmail.com \
    --to=gavinandresen@gmail.com \
    --cc=adam@cypherspace.org \
    --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