On Sat, Feb 06, 2016 at 10:37:30AM -0500, Gavin Andresen via bitcoin-dev wrote:
> 2) People are committing to spinning up thousands of supports-2mb-nodes
> during the grace period.
Why wouldn't an attacker be able to counter-sybil-attack that effort?
Who are these people?
On Sat, Feb 06, 2016 a
Gavin,
I saw this in your blog post:
"Miners producing up-version blocks is a coordination mechanism. Other
coordination mechanisms are possible– there could be a centrally determined
“flag day” or “flag block” when everybody (or almost everybody) agrees that a
change will happen."
Can you de
On Sat, Feb 06, 2016 at 04:11:58PM -0500, Peter Todd via bitcoin-dev wrote:
> 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 wrote:
> >
> > >
> > > It would probably be a good idea to have a security considerations
Its mostly a problem for exchanges and miners. Those entities need to
be on the network 100% of the time because they are using the network
100% of the time. A normal wallet user isn't taking payments every few
minutes like the exchanges are. "Getting booted off the network" is
not something to wor
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 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
On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote:
> On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
wrote:
> > None of the reasons you list say anything about the fact that "being
> > lost" (kicked out of the network) is a problem for those node's u
On Saturday, February 06, 2016 3:37:30 PM Gavin Andresen wrote:
> I suspect there ARE a significant percentage of un-maintained full nodes--
Do you have evidence these are intentionally unmaintained, and not users who
have simply not had time to review and decide on upgrading?
> There is broad a
On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen wrote:
> Responding to "28 days is not long enough" :
>
Gavin,
Thank you for the emails. Bitcoin Core has been working with the Bitcoin
ecosystem on developing and now testing a new capacity increasing feature
called segregated witness (segwit). Seg
On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev wrote:
> None of the reasons you list say anything about the fact that "being lost"
> (kicked out of the network) is a problem for those node's users.
That's because its not.
If you have a node that is "old" your node will sto
On Sat, Feb 6, 2016 at 12:01 PM, Adam Back 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 o
On Feb 6, 2016 16:37, "Gavin Andresen" wrote:
>
> Responding to "28 days is not long enough" :
Any thoughts on the "95% better than 75%" and "grace period before miner
coordination instead of after" comments ?
> I suspect there ARE a significant percentage of un-maintained full
nodes-- probably
Hi Gavin
It would probably be a good idea to have a security considerations
section, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?
Do you have a rollback plan in the event the hard-fork triggers via
false voting as
Responding to "28 days is not long enough" :
I keep seeing this claim made with no evidence to back it up. As I said, I
surveyed several of the biggest infrastructure providers and the btcd lead
developer and they all agree "28 days is plenty of time."
For individuals... why would it take somebo
13 matches
Mail list logo
