Re: [bitcoin-dev] Hardfork bit BIP

[Anthony Towns via bitcoin-dev]

On Sun, Feb 07, 2016 at 03:20:27PM -0500, Gavin via bitcoin-dev wrote:
> > On Feb 7, 2016, at 2:27 PM,   wrote:
> > Normal version number only suggests softforks, which is usually not a 
> > concern for SPV clients.
> Soft forks affect the security of low-confirmation (zero or one) transactions 
> sent to SPV wallets even more than hard forks,

This isn't true for soft-forks that only forbid transactions that would
already be rejected for forwarding and mining due to being non-standard.

> and because many users and businesses choose convenience over airtight 
> security I would argue transaction validation rule changes are a VERY big 
> concern for lightweight clients.

I agree on that point; but ensuring soft-forks only affect non-standard
transactions already addresses that concern in every way I've been able
to discover.

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork bit BIP

[Gavin via bitcoin-dev]

> On Feb 7, 2016, at 2:27 PM,   wrote:
> 
> Normal version number only suggests softforks, which is usually not a concern 
> for SPV clients.

Soft forks affect the security of low-confirmation (zero or one) transactions 
sent to SPV wallets even more than hard forks, and because many users and 
businesses choose convenience over airtight security I would argue transaction 
validation rule changes are a VERY big concern for lightweight clients.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Chris Priest via bitcoin-dev]

Segwit requires work from exchanges, wallets and services in order for
adoption to happen. This is because segwit changes the rules regarding
the Transaction data structure. A blocksize increase does not change
the Transaction rules at all. The blocksize increase is a change to
the Block structure. Most wallets these days are Block agnostic.

Essentially, if a client has been built using a library that abstracts
away the block, then that client's *code* does not need to be updated
to handle this blocksize limit change. An example is any service using
the Bitcore javascript library. Any wallet built using Bitcore does
not need any changes to handle a blocksize upgrade. I have one project
that is live that was built using Bitcore. Before, during, and after
the fork, I do not need to lift a finger *codewise* to keep my project
still working. Same goes for projects that are built using
pybitcointools, as well as probably a few other libraries.

A wallet using Bitcore also has to work in tandem with a blockchan
api. Bitcore itself does not provide any blockchain data, you have to
get that somewhere else, such as a Node API. That API has to be based
on a Node that is following the upgraded chain. My wallet for instance
is built on top of Bitpay Insight. If bitpay doesn't upgrade their
Node to follow the 2MB chain, then I must either...

1) Change my wallet to use my own Bitpay Insight. (Insight is open
source, so you can host you own using any Node client you want)
2) Switch to another API, such as Toshi or Bockr.io, or
Blokchain.Info, or ... (there are dozens to choose from)

A blockchain service such as a blockexplorer does need to be upgraded
to handle a blocksize hardfork. The only work required is updating
their node software so that the MAX_BLOCKSIZE parameter is set to 2MB.
This can be done by either changing the source code themselves, or by
installing an alternate client such as XT, Classic, or Unlimited.

On 2/6/16, Adam Back via bitcoin-dev
 wrote:
> 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 seemed to be prevalent during XT?  (Or rollback just
> as contingency if something unforseen goes wrong).
>
> How do you plan to monitor and manage security through the hard-fork?
>
> Adam
>
> On 6 February 2016 at 16:37, Gavin Andresen via bitcoin-dev
>  wrote:
>> 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 somebody longer than 28 days to
>> either
>> download and restart their bitcoind, or to patch and then re-run (the
>> patch
>> can be a one-line change MAX_BLOCK_SIZE from 100 to 200)?
>>
>> For the Bitcoin Core project:  I'm well aware of how long it takes to
>> roll
>> out new binaries, and 28 days is plenty of time.
>>
>> I suspect there ARE a significant percentage of un-maintained full
>> nodes--
>> probably 30 to 40%. Losing those nodes will not be a problem, for three
>> reasons:
>> 1) The network could shrink by 60% and it would still have plenty of open
>> connection slots
>> 2) People are committing to spinning up thousands of supports-2mb-nodes
>> during the grace period.
>> 3) We could wait a year and pick up maybe 10 or 20% more.
>>
>> I strongly disagree with the statement that there is no cost to a longer
>> grace period. There is broad agreement that a capacity increase is needed
>> NOW.
>>
>> To bring it back to bitcoin-dev territory:  are there any TECHNICAL
>> arguments why an upgrade would take a business or individual longer than
>> 28
>> days?
>>
>>
>> Responding to Luke's message:
>>
>>> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
>>>  wrote:
>>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>>> > wrote:
>>> >> Blog post on a couple of the constants chosen:
>>> >>   http://gavinandresen.ninja/seventyfive-twentyeight
>>> >
>>> > Can you put this in the BIP's Rationale section (which appears to be
>>> > mis-named
>>> > "Discussion" in the current draft)?
>>
>>
>> I'll rename the section and expand it a little. I think standards
>> documents
>> like BIPs should be concise, though (written for implementors), so I'm
>> not
>> going to recreate the entire blog post there.
>>
>>>
>>> >
>>> >> Signature operations in un-executed branches of a Script are not
>>> >> counted
>>> >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature
>>> >> for a
>>> >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the
>>> >> top
>>> >> of the execution stack, it is counted as one signature operation

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Corey Haddad via bitcoin-dev]

We don't have any evidence of how fast nodes will upgrade when faced with
an impending hard fork, but it seems like a very safe assumption that the
upgrade pace will be significantly faster.  The hard fork case it is:
"upgrade or be kicked off the network".  In the previous cases it has been,
"here's the latest and greatest, give it a go!".  Also, there will be
alerts sent out warning people of the situation, prompting them to take
action.

It is unclear if this will translate into more or less than 6x the adoption
speed of previous instances, but the idea that it would be faster is
solid.  28 days is aggressive, but again, it is only 28 days from when the
fork triggers.  Compatible software is already available for anyone who
wants to prepare.

It is also of significance that this proposed fork, and this debate, has
been going on for many, many months.  If someone proposed a forking concept
today, wrote the BIP tomorrow, deployed it next week, miners adopted it
instantly, and 28 days later it was the flag day, those 28 days would be in
a different context.  There is no surprise here.

On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
> it Gavin --
>
> ~
> "We can look at the adoption of the last major Bitcoin core release to
> guess how long it might take people to upgrade. 0.11.0 was released on 12
> July, 2015. Twenty eight days later, about 38% of full nodes were running
> that release. Three months later, about 50% of the network was running
> that release, and six months later about 66% of the network was running
> some flavor of 0.11."
>
> On what grounds do you think it is reasonable to assume that this update
> will roll out 6x faster than previous data suggested, as oppose to your own
> observation of 66% adoption in 6 month. or do you believe 38% node
> upgrade-coverage (in 28 days ) on the network for a hard fork is good
> enough?
>
> There are no harm in choosing a longer grace period but picking one short
> as 28 days you risk on alienating the nodes who do not upgrade with the
> aggressive upgrade timeline you proposed.
> ~~
>
> When Gavin writes "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 somebody longer than 28 days to
> either download and restart their bitcoind, or to patch and then re-run
> (the patch can be a one-line change MAX_BLOCK_SIZE from 100 to
> 200)?"
>
> ~~
>
> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
> propositional a priori logic, but empirical evidence that. As for why
> people take longer, who knows, we simply know from passed experience that
> it in fact does take longer.
>
> It's extremely frustrating to read Gavin's comments, it's hard to believe
> he is engaging in earnest discussion.
>
> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>> wrote:
>> > > > If you have a node that is "old" your node will stop getting new
>> > > > blocks. The node will essentially just say "x-hours behind" with "x"
>> > > > getting larger every hour. Funds don't get confirmed. etc.
>> > >
>> > > Until someone decides to attack you. Then you'll get 6, 10, maybe more
>> > > blocks confirming a large 1 BTC payment. If you're just a normal
>> end
>> > > user (or perhaps an automated system), you'll figure that payment is
>> good
>> > > and irreversibly hand over the title to the house.
>> >
>> > There will be approximately zero percentage of hash power left on the
>> > weaker branch of the fork, based on past soft-fork adoption by miners
>> (they
>> > upgrade VERY quickly from 75% to over 95%).
>>
>> I'm assuming there are literally ZERO miners left on the weaker branch.
>> The attacker in this scenario simply rents hashing for a few days in
>> advance
>> to build his fake chain, then broadcasts the blocks to the unsuspecting
>> merchant at ~10 block intervals so it looks like everything is working
>> normal
>> again. There are lots of mining rental services out there, and miners
>> quite
>> often do not care to avoid selling hashrate to the highest bidder
>> regardless
>> of what they're mining. 10 blocks worth costs a little more than 250 BTC -
>> soon, that will be 125 BTC.
>>
>> Luke
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mail

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Steven Pine via bitcoin-dev]

I agree that it seems like a safe assumption that adoption would be faster,
whether it is "very safe" and "significantly faster", whether it will be 6
times faster, all of those assumptions seems significantly less safe and
robust to me.

The nature of the bitcoin protocol, that it is a decentralized census based
protocol involving currency, suggests to me that roll out schedules ought
to be conservative with a minimum of assumptions. In light of the most
recent protocol upgrade, 6 months for this hard fork seems to me to be the
most conservative time frame with the fewest assumptions.

As for why it needs to be so fast, ie what are the dangers of it being as
slow as 6 months?

Gavin writes:

"I strongly disagree with the statement that there is no cost to a longer
grace period. There is broad agreement that a capacity increase is needed
NOW."

~~
"Broad agreement", that really seems to be another assumption, the fact
that the debate has been as long and acrimonious as it has been suggests
that there isn't broad agreement. Also, resorting to "SHOUTING" doesn't win
any favors when it comes to engaging in reasonable discussion om the
technical merits of a proposal.



On Sun, Feb 7, 2016 at 5:04 PM, Corey Haddad  wrote:

> We don't have any evidence of how fast nodes will upgrade when faced with
> an impending hard fork, but it seems like a very safe assumption that the
> upgrade pace will be significantly faster.  The hard fork case it is:
> "upgrade or be kicked off the network".  In the previous cases it has been,
> "here's the latest and greatest, give it a go!".  Also, there will be
> alerts sent out warning people of the situation, prompting them to take
> action.
>
> It is unclear if this will translate into more or less than 6x the
> adoption speed of previous instances, but the idea that it would be faster
> is solid.  28 days is aggressive, but again, it is only 28 days from when
> the fork triggers.  Compatible software is already available for anyone who
> wants to prepare.
>
> It is also of significance that this proposed fork, and this debate, has
> been going on for many, many months.  If someone proposed a forking concept
> today, wrote the BIP tomorrow, deployed it next week, miners adopted it
> instantly, and 28 days later it was the flag day, those 28 days would be in
> a different context.  There is no surprise here.
>
> On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Is it me or did Gavin ignore Yifu's direct questions? In case you missed
>> it Gavin --
>>
>> ~
>> "We can look at the adoption of the last major Bitcoin core release to
>> guess how long it might take people to upgrade. 0.11.0 was released on 12
>> July, 2015. Twenty eight days later, about 38% of full nodes were
>> running that release. Three months later, about 50% of the network was
>> running that release, and six months later about 66% of the network was
>> running some flavor of 0.11."
>>
>> On what grounds do you think it is reasonable to assume that this update
>> will roll out 6x faster than previous data suggested, as oppose to your own
>> observation of 66% adoption in 6 month. or do you believe 38% node
>> upgrade-coverage (in 28 days ) on the network for a hard fork is good
>> enough?
>>
>> There are no harm in choosing a longer grace period but picking one short
>> as 28 days you risk on alienating the nodes who do not upgrade with the
>> aggressive upgrade timeline you proposed.
>> ~~
>>
>> When Gavin writes "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 somebody longer than 28 days to
>> either download and restart their bitcoind, or to patch and then re-run
>> (the patch can be a one-line change MAX_BLOCK_SIZE from 100 to
>> 200)?"
>>
>> ~~
>>
>> Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
>> propositional a priori logic, but empirical evidence that. As for why
>> people take longer, who knows, we simply know from passed experience that
>> it in fact does take longer.
>>
>> It's extremely frustrating to read Gavin's comments, it's hard to believe
>> he is engaging in earnest discussion.
>>
>> On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
>>> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
>>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
>>> wrote:
>>> > > > If you have a node that is "old" your node will stop getting new
>>> > > > blocks. The node will essentially just say "x-hours behind" with
>>> "x"
>>> > > > getting l

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Steven Pine via bitcoin-dev]

Is it me or did Gavin ignore Yifu's direct questions? In case you missed it
Gavin --

~
"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."

On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage (in 28 days ) on the network for a hard fork is good
enough?

There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.
~~

When Gavin writes "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 somebody longer than 28 days to either
download and restart their bitcoind, or to patch and then re-run (the patch
can be a one-line change MAX_BLOCK_SIZE from 100 to 200)?"

~~

Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't
propositional a priori logic, but empirical evidence that. As for why
people take longer, who knows, we simply know from passed experience that
it in fact does take longer.

It's extremely frustrating to read Gavin's comments, it's hard to believe
he is engaging in earnest discussion.

On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
> > On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
> wrote:
> > > > If you have a node that is "old" your node will stop getting new
> > > > blocks. The node will essentially just say "x-hours behind" with "x"
> > > > getting larger every hour. Funds don't get confirmed. etc.
> > >
> > > Until someone decides to attack you. Then you'll get 6, 10, maybe more
> > > blocks confirming a large 1 BTC payment. If you're just a normal
> end
> > > user (or perhaps an automated system), you'll figure that payment is
> good
> > > and irreversibly hand over the title to the house.
> >
> > There will be approximately zero percentage of hash power left on the
> > weaker branch of the fork, based on past soft-fork adoption by miners
> (they
> > upgrade VERY quickly from 75% to over 95%).
>
> I'm assuming there are literally ZERO miners left on the weaker branch.
> The attacker in this scenario simply rents hashing for a few days in
> advance
> to build his fake chain, then broadcasts the blocks to the unsuspecting
> merchant at ~10 block intervals so it looks like everything is working
> normal
> again. There are lots of mining rental services out there, and miners quite
> often do not care to avoid selling hashrate to the highest bidder
> regardless
> of what they're mining. 10 blocks worth costs a little more than 250 BTC -
> soon, that will be 125 BTC.
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Steven Pine
(510) 517-7075
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Luke Dashjr via bitcoin-dev]

On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev 
wrote:
> > > If you have a node that is "old" your node will stop getting new
> > > blocks. The node will essentially just say "x-hours behind" with "x"
> > > getting larger every hour. Funds don't get confirmed. etc.
> > 
> > Until someone decides to attack you. Then you'll get 6, 10, maybe more
> > blocks confirming a large 1 BTC payment. If you're just a normal end
> > user (or perhaps an automated system), you'll figure that payment is good
> > and irreversibly hand over the title to the house.
> 
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (they
> upgrade VERY quickly from 75% to over 95%).

I'm assuming there are literally ZERO miners left on the weaker branch.
The attacker in this scenario simply rents hashing for a few days in advance 
to build his fake chain, then broadcasts the blocks to the unsuspecting 
merchant at ~10 block intervals so it looks like everything is working normal 
again. There are lots of mining rental services out there, and miners quite 
often do not care to avoid selling hashrate to the highest bidder regardless 
of what they're mining. 10 blocks worth costs a little more than 250 BTC - 
soon, that will be 125 BTC.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Tier Nolan via bitcoin-dev]

On Sun, Feb 7, 2016 at 7:03 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would expect that custodians who fail to produce coins on both sides
> of a fork in response to depositor requests will find themselves in
> serious legal trouble.
>

If the exchange uses an UTXO from before the fork to pay their clients,
then they are guaranteed to count as paying on all forks.  The exchange
doesn't need to specifically pay out for each fork.

As long as the exchange doesn't accidently double spend an output, even
change addresses are valid.

It is handling post-fork deposits where the problem can occur.  If they
only receive coins on one fork, then that should cause the client to be
credited with funds on both forks.

The easiest thing would be to refuse to accept deposits for a while
before/after the fork happens.
 This email has been sent from a
virus-free computer protected by Avast.
www.avast.com 
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Trevin Hofmann via bitcoin-dev]

Patrick,

I would say that a company's terms of service should include their position
on this issue. It does not seem reasonable that they all are required to
provide access to coins on every single fork. Are custodial wallet users
also entitled to Clam, Zcash, and Decred, and others?

Regardless, I think this thread should be about the technical merits of the
BIP. Discussion of hard forks would be better held elsewhere.

On Sun, Feb 7, 2016 at 1:03 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would expect that custodians who fail to produce coins on both sides
> of a fork in response to depositor requests will find themselves in
> serious legal trouble.
>
> Especially if the price moves against either fork.
>
> On 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:
> >
> > On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev
> >  > > wrote:
> >
> >> They *must* be able to send their customers both coins as separate
> >> withdrawals.
> >>
> > Supporting the obsolete chain is unnecessary. Such support has not
> > been offered in any cryptocurrency hard fork before, as far as I know.
> > I do not see why it should start now.
> >>
> >> If not, that amounts to theft of their customers funds.
> >>
> > If they announce their planned behavior before the fork, I do not see
> > any ethical or legal issues.
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork bit BIP

[jl2012--- via bitcoin-dev]

From: Gavin Andresen [mailto:gavinandre...@gmail.com] 
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell 
Cc: jl2012 ; Bitcoin Dev 
Subject: Re: [bitcoin-dev] Hardfork bit BIP

>It is always possible I'm being dense, but I still don't understand how this 
>proposal makes a chain-forking situation better for anybody.

>If there are SPV clients that don't pay attention to versions in block 
>headers, then setting the block version negative doesn't directly help them, 
>they will ignore it in any case.

It is unfortunate SPV clients are not following that. However, they SHOULD 
follow that. It becomes a self fulfilling prophecy if we decide not to do that 
if SPV are not following that.

>If the worry is full nodes that are not upgraded, then a block with a negative 
>version number will, indeed, fork them off the the chain, in exactly the same 
>way a block with new hard-forking consensus rules would. And with the same 
>consequences (if there is any hashpower not paying attention, then a worthless 
>minority chain might continue on with the old rules).

It will distinguish between a planned hardfork and an accidental hardfork, and 
full nodes may react differently. Particularly, a planned unknown hardfork is a 
strong indication that the original chain has become economic minority and the 
non-upgraded full node should stop accepting incoming tx immediately.

>If the worry is not-upgraded SPV clients connecting to the old, not-upgraded 
>full nodes, I don't see how this proposed BIP helps.

Same for not-upgraded full nodes following not-upgraded full nodes. Anyway, the 
header with enough PoW should still be propagated.

>I think a much better idea than this proposed BIP would be a BIP that 
>recommends that SPV clients to pay attention to block version numbers in the 
>headers that they download, and warn if there is a soft OR hard fork that they 
>don't know about.

Normal version number only suggests softforks, which is usually not a concern 
for SPV clients. An unknown hardfork is a completely different story as the 
values of the forks are completely unknown.

>It is also a very good idea for SPV clients to pay attention to timestamps in 
>the block headers that the receive, and to warn if blocks were generated 
>either much slower or faster than statistically likely. Doing that (as Bitcoin 
>Core already does) will mitigate Sybil attacks in general.

Yes, they should.

-- 
--
Gavin Andresen


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Patrick Strateman via bitcoin-dev]

I would expect that custodians who fail to produce coins on both sides
of a fork in response to depositor requests will find themselves in
serious legal trouble.

Especially if the price moves against either fork.

On 02/07/2016 10:55 AM, Jonathan Toomim via bitcoin-dev wrote:
>
> On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev
>  > wrote:
>
>> They *must* be able to send their customers both coins as separate
>> withdrawals.
>>
> Supporting the obsolete chain is unnecessary. Such support has not
> been offered in any cryptocurrency hard fork before, as far as I know.
> I do not see why it should start now.
>>
>> If not, that amounts to theft of their customers funds.
>>
> If they announce their planned behavior before the fork, I do not see
> any ethical or legal issues. 
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Jonathan Toomim via bitcoin-dev]

On Feb 6, 2016, at 9:21 PM, Jannes Faber via bitcoin-dev 
 wrote:

> They *must* be able to send their customers both coins as separate 
> withdrawals.
> 
Supporting the obsolete chain is unnecessary. Such support has not been offered 
in any cryptocurrency hard fork before, as far as I know. I do not see why it 
should start now.
> If not, that amounts to theft of their customers funds.
> 
If they announce their planned behavior before the fork, I do not see any 
ethical or legal issues.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Jonathan Toomim via bitcoin-dev]

On Feb 7, 2016, at 9:24 AM, jl2...@xbt.hk wrote:

> You are making a very naïve assumption that miners are just looking for 
> profit for the next second. Instead, they would try to optimize their short 
> term and long term ROI. It is also well known that some miners would mine at 
> a loss, even not for ideological reasons, if they believe that their action 
> is beneficial to the network and will provide long term ROI. It happened 
> after the last halving in 2012. Without any immediate price appreciation, the 
> hashing rate decreased by only less than 10%
> 


In 2012, revenue dropped by about 50% instantaneously. That does not mean that 
profitability became negative.

The difficulty at the time of the halving was about 3M. The exchange rate was 
about $12. A common miner at the time was the Radeon 6970, which performed 
about 350 Mh/s on 200 W for about 1.75 Mh/J. A computer with 4 6970s would use 
about 1 kW of power, once AC/DC losses and CPU overhead are taken into account. 
This 1 kW rig would have earned about $0.22/kWh before the halving, and 
$0.11/kWh after the halving. Since it's not hard to find electricity cheaper 
than $0.11/kWh, the hashrate didn't drop much.

It's a common misconception that the mining hashrate increases until an 
equilibrium is reached, and nobody is making a profit any longer. However, this 
is not true. The hashrate stops increasing when the expected operating profit 
over a reasonable time frame is no longer greater than the hardware cost, not 
when the operating profit approaches zero. For example, an S7 right now costs a 
little over $1000. If I don't expect to earn more than $1000 in operating 
profit over the next year or two with an S7, then I won't buy one.

Right now, an S7 earns about $190/month and costs about $60/month to operate, 
for a profit of $120/month. After the halving, revenue would drop to $95/month 
(or less, depending on difficulty and exchange rate), leaving profit at about 
$35/month. The $120/month profit is good enough motivation to buy hardware now, 
and the $35/month would be good enough motivation to keep running hardware 
after the halving.

I know in advance when the halvings are coming. There's going to be one in 
about 5 months, for example. I'm going to stop buying miners before the halving 
even if they're very profitable for a month because I don't want to be stuck 
with hardware that won't reach 100% return on investment (ROI).




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Pre-BIP Growth Soft-hardfork

[jl2012--- via bitcoin-dev]

This looks very interesting. The first time implementing it might be more
painful but that will make subsequent hardforks a lot easier.

Do you think it's good to include the median timestamp of the past 11 blocks
after the block height in coinbase? That would make it easier to use it as
activation threshold of consensus rule changes.

For the witness commitment, it will also be treated as a merge mined
commitment?

It is also good to emphasize that it is the responsibility of miners, not
devs, to ensure that the hardfork is accepted by the supermajority of the
economy.


-Original Message-
From: bitcoin-dev-boun...@lists.linuxfoundation.org
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Luke
Dashjr via bitcoin-dev
Sent: Sunday, 7 February, 2016 17:53
To: Bitcoin Dev 
Subject: [bitcoin-dev] Pre-BIP Growth Soft-hardfork

Here's a draft BIP I wrote almost a year ago. I'm going to look into
revising and completing it soon, and would welcome any suggestions for doing
so.

This hardfork BIP aims to accomplish a few important things:
- Finally deploying proper merge-mining as Satoshi suggested before he left.
- Expanding the nonce space miners can scan in-chip, avoiding expensive
  calculations on the host controller as blocks get larger.
- Provide a way to safely deploy hardforks without risking leaving old nodes
  vulnerable to attack.

https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[jl2012--- via bitcoin-dev]

You are making a very naïve assumption that miners are just looking for
profit for the next second. Instead, they would try to optimize their short
term and long term ROI. It is also well known that some miners would mine at
a loss, even not for ideological reasons, if they believe that their action
is beneficial to the network and will provide long term ROI. It happened
after the last halving in 2012. Without any immediate price appreciation,
the hashing rate decreased by only less than 10%

 

http://bitcoin.sipa.be/speed-ever.png

 

 

From: bitcoin-dev-boun...@lists.linuxfoundation.org
[mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Jonathan
Toomim via bitcoin-dev
Sent: Monday, 8 February, 2016 01:11
To: Anthony Towns 
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes

 

 

On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:





The stated reasoning for 75% versus 95% is "because it gives "veto power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.

 

Keep in mind that within a single difficulty adjustment period, the
difficulty of mining a block on either chain will be identical. Even if the
value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch is
100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate on
the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for the
first adjustment period) is to mine on the 2 MB branch, because the miner
would earn 1% more on that branch.

 

So you're assuming that 25% of the hashrate chooses to remain on the
minority version during the grace period, and that 20% chooses to switch
back to the minority side. The fork happens. One branch has 1 MB blocks
every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. The
first branch cannot handle the pre-fork transaction volume, as it only has
45% of the capacity that it had pre-fork. The second one can, as it has 111%
of the pre-fork capacity. This makes the 1 MB branch much less usable than
the 2 MB branch, which in turn causes the market value of newly minted coins
on that branch to fall, which in turn causes miners to switch to the more
profitable 2MB branch. This exacerbates the usability difference, which
exacerbates the price difference, etc. Having two competing chains with
equal hashrate using the same PoW function and nearly equal features is not
a stable state. Positive feedback loops exist to make the vast majority of
the users and the hashrate join one side.

 

Basically, any miners who stick to the minority branch are going to lose a
lot of money.

 

 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Gavin Andresen via bitcoin-dev]

As I feared, request on feedback for this specific BIP has devolved into a
general debate about the merits of soft-forks versus hard-forks (versus
semi-hard Kosher Free Range forks...).

I've replied to several people privately off-list to not waste people's
time rehashing arguments that have been argued to death in the past.

I do want to briefly address all of the concerns that stem from "what if a
significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of
the chain."

Proof of work cannot be spoofed. If there is very little (a few percent) of
hashpower mining a minority chain, confirmations on that chain take orders
of magnitude longer.  I wrote about why the incentives are extremely strong
for only the stronger branch to survive here:
 http://gavinandresen.ninja/minority-branches

... the debate about whether or not that is correct doesn't belong here in
bitcoin-dev, in my humble opinion.

All of the security concerns I have seen flow from an assumption that
significant hashpower continues on the weaker branch. The BIP that is under
discussion assumes that analysis is correct. I have not seen any evidence
that it is not correct; all experience with previous forks (of both Bitcoin
and altcoins) is that the stronger branch survives and the weaker branch
very quickly dies.


As for the argument that creating and testing a patch for Core would take
longer than 28 days:

The glib answer is "people should just run Classic, then."

A less glib answer is it would be trivial to create a patch for Core that
accepted a more proof-of-work chain with larger blocks, but refused to mine
larger blocks.

That would be a trivial patch that would require very little testing
(extensive testing of 8 and 20mb blocks has already been done), and perhaps
would be the best compromise until we can agree on a permanent solution
that eliminates the arbitrary, contentious limits.

-- 
--
Gavin Andresen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Jonathan Toomim via bitcoin-dev]

On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev 
 wrote:

> The stated reasoning for 75% versus 95% is "because it gives "veto power"
> to a single big solo miner or mining pool". But if a 20% miner wants to
> "veto" the upgrade, with a 75% threshold, they could instead simply use
> their hashpower to vote for an upgrade, but then not mine anything on
> the new chain. At that point there'd be as little as 55% mining the new
> 2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
> minute blocks versus 22 minute blocks, which doesn't seem like much of
> a difference in practice, and at that point hashpower could plausibly
> end up switching almost entirely back to the original consensus rules
> prior to the grace period ending.


Keep in mind that within a single difficulty adjustment period, the difficulty 
of mining a block on either chain will be identical. Even if the value of a 1MB 
branch coin is $100 and the hashrate on the 1 MB branch is 100 PH/s, and the 
value of a 2 MB branch coin is $101 and the hashrate on the 2 MB branch is 1000 
PH/s, the rational thing for a miner to do (for the first adjustment period) is 
to mine on the 2 MB branch, because the miner would earn 1% more on that branch.

So you're assuming that 25% of the hashrate chooses to remain on the minority 
version during the grace period, and that 20% chooses to switch back to the 
minority side. The fork happens. One branch has 1 MB blocks every 22 minutes, 
and the other branch has 2 MB blocks every 18 minutes. The first branch cannot 
handle the pre-fork transaction volume, as it only has 45% of the capacity that 
it had pre-fork. The second one can, as it has 111% of the pre-fork capacity. 
This makes the 1 MB branch much less usable than the 2 MB branch, which in turn 
causes the market value of newly minted coins on that branch to fall, which in 
turn causes miners to switch to the more profitable 2MB branch. This 
exacerbates the usability difference, which exacerbates the price difference, 
etc. Having two competing chains with equal hashrate using the same PoW 
function and nearly equal features is not a stable state. Positive feedback 
loops exist to make the vast majority of the users and the hashrate join one 
side.

Basically, any miners who stick to the minority branch are going to lose a lot 
of money.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Peter Todd via bitcoin-dev]

On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote:
> And the back and forth discussion over your BIP has been in large part a
> charade.  People asking why you aren't picking 95% know very well why you
> aren't, but lets have an honest discussion of what the risks and in your

Eh, lets not put words into people's mouths. I personally don't
understand why Gavin is using 75% in the manner that he is, given there
are many better alternatives, even if you don't think you can get ~100%
hashing power support.

> mind potential benefits of 75% are.   Important debate about parameters of
> your BIP get lost because we're sniping at each other about known
> disagreements.  For instance, I strongly believe 28 days is far too short.

Note that the grace period adds a significant amount of complexity to
the implementation; a much simpler alternative is to just use a hashing
power activated change with a very high threshold - 99% or so - with a
minimum activation date some point reasonably far into the future.

Also the way the grace period is implemented means that if support
*drops* after 75% is reached, the hardfork still activates (I haven't
actually tested this, so I may be misunderstanding the code). Obviously,
this is a dangerous situation, and an easy way for miners to "poison the
well" and disruptively force the fork to be rescheduled without actually
attacking the coin (nothing wrong with changing your mind! and pool
distribution may change anyway).

Again, a simple high % miner consensus fork with a reasonable minimum
activation time avoids all these problems, with far less code
complexity.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
0711a9829e87ba8ea548f1793950893043a5dc56893dc1dc


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Making a 2MB blocksize hardfork safer

[Anthony Towns via bitcoin-dev]

Hello world,

The core roadmap calls for having patches at the ready for
implementing hardforking blocksize increases [0]. However, at least
to my understanding, is that the deployment of segregated witness has
a significant impact on what a hardforking blocksize increase should
look like -- with segwit, the increase in the blocksize may have to
be traded off against decreasing the witness discount; without segwit,
alternative changes might need to be made to provide some of the other
benefits of segwit without segwit (in particular, additional limits to
prevent hashing massive amounts of data when checking sigs or to reduce
worst-case UTXO growth).

I don't personally have any real concerns that segregated witness will be
too complicated to implement and release by April, and given how quickly
CLTV rolled out, my guess is it will be usable prior to the block reward
halving. I'm also not terribly worried about fees rising significantly,
or that there will be a "fee event" [1] or "market disruption" -- fees
don't seem to be rising even with the spam attacks we've seen, and all
the problems with transactions not confirming that I've been able to see
so far seem to be due either to people trying to do free transactions,
fees not being calculated based on transaction size, or not checking
for dust outputs, all of which are things that can be dealt with by
individual wallets. [2]

But those are guesses and opinions, and I think it makes sense to have
a backup plan if everything goes horribly wrong -- someone discovers
a problem with segwit that requires major rearchitecturing to fix and
won't happen until 2017, eg.

To me, Gavin's BIP [3] and the Bitcoin Classic approach don't seem like
a good backup plan; but I don't see why they couldn't be *made* into a
good plan. In particular, if segwit turns out too hard to actually deploy
safely, I think Gavin's patchset -- an increase to ~2MB, coupled with
accurate counting and limiting of sighash bytes, and pretty much nothing
else -- is about the right set of *technical* things to do as a backup plan.

So the following are my suggestions for making Gavin's BIP workable
procedurally/politically as a backup plan. But that said, I don't know
if this is even remotely acceptable politically; I'm just following
bitcoin as a hobby and I don't have any backchannel contacts in mining
or bitcoin startups or anything.

1. Level of supermajority
=

First, it was reported that the Chinese miners came up with a 2MB
blocksize plan in late January [4], with the following summarised plan:

]  If:
]1: Blocks are full
]2: Core proposal is <2MB
]3: Classic proposal have not gained consensus
]  Then:
]Under the 90% hash power condition, switch from a 1MB limit to a
]2MB limit to deal with the block size problem.

The summary also expresses concerns about segwit deployment; that it
makes significant changes, and that any issues with reliability may have
major impact. Those seem like valid concerns to me; though if they are
not addressed directly, then I expect miners will simply not enable the
segwit soft-fork until they are.

I think the only change to make this match Gavin's code for Bitcoin
Classic then is to require 90% hashpower support rather than 75%. I think
that can be easily done by a soft-forking change where miners reject any
block with a Classic vote (ie a version of 0x1000) if the block height
is cleanly divisible by 6 [5]. As this is a soft-forking change, and one
that's only relevant until either Classic activates or the 2MB hardfork
attempt is permanently aborted on 2018-01-01, it seems like it could
easily be deployed prior to either segwit or Classic voting beginning.

2. Activation Time
==

The activation time for Gavin's BIP is very short -- 1000 blocks for
voting could be as short as 6 days, followed by 28 days grace period.
I haven't seen any indication that there is an immediate crisis, or
that there will be one in the next few months; and the fact that the
BIP does not expire for two years seems to indicate it's not a short
term issue. Allowing three to six months before attempting to activate
the hardfork seems like it would still provide plenty of opportunity to
address the issue quickly, and would also mean there was time to see if
the segwit rollout worked as planned.

That also could be enforced by a soft-fork: eg having a rule that until
the median time past is 2015-05-27, any block voting for the 2MB hardfork
will be rejected, would ensure the hard fork was not activated until
1st of July. A slightly more complicated rule, eg only rejecting the
blocks if the last three decimal digits of its height was 500 or greater,
would allow support to be measured in the leadup to possible activation,
without any risk of activation happening early.

3. Upgrade encouragement


I think there's three ways the 2MB hardfork could go: (a) not ever being
activated at all, similar to XT; (b) 

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Anthony Towns via bitcoin-dev]

On Sun, Feb 07, 2016 at 09:16:02AM -0500, Gavin Andresen via bitcoin-dev wrote:
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (they
> upgrade VERY quickly from 75% to over 95%).

The stated reasoning for 75% versus 95% is "because it gives "veto power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.

With a non-consensus fork, I think you need to expect people involved to
potentially act in ways that aren't very gentlemanly, and guard against
it if you want the fork to be anything other than a huge mess.

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Alex Morcos via bitcoin-dev]

I apologize if this discussion should be moved to -discuss, I'll let the
moderators decide, I've copied both.

And Gavin, I apologize for picking on you here, because certainly this
carelessness in how people represent "facts" applies to both sides, but
much of this discussion really infuriates me.
I believe it is completely irresponsible for you to state:
"There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners"
Sure, the rest of the technical community is capable of evaluating that for
themselves, but your statements are considered authoritative by much larger
audience.  In truth, no one has any idea what would happen if the proposed
Classic hard fork activated with 75% right now.  There is some chance you
are right, but there is a very legitimate possibility that a concerted
effort would arise to maintain a minority fork or perhaps if miners don't
see nearly a complete switch over, many of them might themselves reverse
the fork if they think it would be easier to achieve consensus that way.
We as a community have never been in such a situation before and it
behooves us to speak honestly and directly about the uncertainty of the
situation.

And the back and forth discussion over your BIP has been in large part a
charade.  People asking why you aren't picking 95% know very well why you
aren't, but lets have an honest discussion of what the risks and in your
mind potential benefits of 75% are.   Important debate about parameters of
your BIP get lost because we're sniping at each other about known
disagreements.  For instance, I strongly believe 28 days is far too short.
I think its extremely unlikely that those who are opposed to a contentious
hard fork will do the development work to prepare for it as that may only
make it more likely to happen.  Thus if you did achieve activation with
75%, its almost impossible to imagine that if Bitcoin Core decided to come
along (as opposed to pursuing a minority fork) that they'd have the time to
develop and test the patch and roll it out to wide adoption.   If the goal
of your attempt is that any minority that disagreed will "choose" to follow
the majority branch, then you'd be much more likely to achieve that by
giving them time to decide that's what they wanted and roll out the
software to do so.




On Sun, Feb 7, 2016 at 9:16 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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 users.
>> >
>> > That's because its not.
>> >
>> > If you have a node that is "old" your node will stop getting new blocks.
>> > The node will essentially just say "x-hours behind" with "x" getting
>> larger
>> > every hour. Funds don't get confirmed. etc.
>>
>> Until someone decides to attack you. Then you'll get 6, 10, maybe more
>> blocks
>> confirming a large 1 BTC payment. If you're just a normal end user (or
>> perhaps an automated system), you'll figure that payment is good and
>> irreversibly hand over the title to the house.
>>
>
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (they
> upgrade VERY quickly from 75% to over 95%).
>
> So it will take a week to get 6 confirmations.
>
> If you are a full node, you are warned that your software is obsolete and
> you must upgrade.
>
> If you are a lightweight node, it SHOULD tell you something is wrong, but
> even if it doesn't, given that people running lightweight nodes run them so
> they don't have to be connected to the network 24/7, it is very likely
> during that week you disconnect and reconnect to the network several times.
> And every time you do that you increase your chances that you will connect
> to full nodes on the majority branch of the chain, where you will be told
> about the double-spend.
>
> All of that is assuming that there is no OTHER mitigation done. DNS seeds
> should avoid reporting nodes that look like they are in the middle of
> initial block download (that are at a block height significantly behind the
> rest of the network), for example.
>
> --
> --
> Gavin Andresen
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Jannes Faber via bitcoin-dev]

On 6 Feb 2016 4:41 p.m., "Gavin Andresen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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."

28 days doesn't sound like enough for exchanges and others holding 3rd
party coins. They will have to start untangling the Bitcoins from
classiccoins immediately, while pausing all withdrawals. They *must* be
able to send their customers both coins as separate withdrawals. If not,
that amounts to theft of their customers funds.

(Note that the above describes the honest exchanges. Imagine the dishonest
ones that simply steal the classiccoins from their customers and sell them
for their own profit.)

The only other option is guaranteeing customers both coins in one
transaction, which they can't.

Surely you can't expect small entities to start putting in massive man
hours into this even before the hard fork has been triggered? Or even big
entities to have all that implemented and tested within *20* working days?

--
Jannes
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Gavin Andresen via bitcoin-dev]

On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 users.
> >
> > That's because its not.
> >
> > If you have a node that is "old" your node will stop getting new blocks.
> > The node will essentially just say "x-hours behind" with "x" getting
> larger
> > every hour. Funds don't get confirmed. etc.
>
> Until someone decides to attack you. Then you'll get 6, 10, maybe more
> blocks
> confirming a large 1 BTC payment. If you're just a normal end user (or
> perhaps an automated system), you'll figure that payment is good and
> irreversibly hand over the title to the house.
>

There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners (they
upgrade VERY quickly from 75% to over 95%).

So it will take a week to get 6 confirmations.

If you are a full node, you are warned that your software is obsolete and
you must upgrade.

If you are a lightweight node, it SHOULD tell you something is wrong, but
even if it doesn't, given that people running lightweight nodes run them so
they don't have to be connected to the network 24/7, it is very likely
during that week you disconnect and reconnect to the network several times.
And every time you do that you increase your chances that you will connect
to full nodes on the majority branch of the chain, where you will be told
about the double-spend.

All of that is assuming that there is no OTHER mitigation done. DNS seeds
should avoid reporting nodes that look like they are in the middle of
initial block download (that are at a block height significantly behind the
rest of the network), for example.

-- 
--
Gavin Andresen
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Pre-BIP Growth Soft-hardfork

[Tier Nolan via bitcoin-dev]

This is a specific implementation of the "nuclear option" soft fork (or
"firm-fork").

The problem with any hard-fork (like) change is that there is an incentive
to add as much as possible and then the process gets bogged down.

Since the POW is based on the header 1, you could make header 3
expandable.  This would allow adding new fields later.

This could be used for other block commitments.  This would save having to
make the merkle tree a sum tree immediately.  At a later time, the sum-tree
root could be added. (I think you also need to commit the path to the first
entry in the sum-tree, in order to get compact proofs).  There could be
separate sum-trees for each counter (sigops, block size, tx count, sighash?)

Having a dedicated hard fork and soft fork counter is a good idea.  There
should also be a field for parallel soft forks.  Incrementing the soft fork
counter could set the bitfield soft forks back to zero.  Ideally, each soft
fork would have a yes and no bit.  If > 50% vote No, then it fails adoption.

The effect of this change is that nodes react to hard forks by stalling the
chain.  The hard fork counter means that the new rules could be that nodes
should do that going forward for all new hard forks.

- soft fork (bitfield or count) => warn user that a soft fork has happened
- hard fork count increase => warn user that update is required and don't
process any more blocks

This means that header3 should be kept as simple as possible.

   - 2 bytes: hardfork block version
   - 2 bytes: softfork block version
   - 4 bytes: softfork bitfields
   - 32 byte: hash(header4)

Header4 and everything else in the block could be changed when a hard fork
happens.  The merged mining rules and header3 would be fixed.

I think confirmation counts should be based on even numbers, i.e. 3800 of
4000, but that is an aesthetic issue and doesn't really matter.

A section on recommendations for the different client types would be useful.

If 1000 of the last 2000 blocks are votes for a hard fork, then warn the
user that a hard fork is being considered

If 4000 of the last 4463 blocks are votes for a hard fork, then warn the
user that a hard fork is likely to occur within the next few days

If a hard fork happens:

- shut down transaction processing
- inform the user that a hard fork has happened

Non-upgraded miners could blacklist the hard forking block and keep mining
on their own chain.  Their chain would never reach the threshold to trigger
the hard fork.  It would max out at 4323 blocks of the last 4463.

Ironically, if users did this, it would defeat some of the benefit of using
the hard fork field.

Users should definitely be given the option of accepting or rejecting the
hard fork.  Otherwise, miners can hard-fork at will, which isn't desirable.
 This email has been sent from a
virus-free computer protected by Avast.
www.avast.com 
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[Anthony Towns via bitcoin-dev]

On Fri, Feb 05, 2016 at 03:51:08PM -0500, Gavin Andresen via bitcoin-dev wrote:
> Constructive feedback welcome; [...]
> Summary:
>   Increase block size limit to 2,000,000 bytes.
>   With accurate sigop counting, but existing sigop limit (20,000)
>   And a new, high limit on signature hashing

To me, it seems absurd to have a hardfork but not take the opportunity
to combine these limits into a single weighted sum.

I'd suggest:

   0.5*blocksize + 50*accurate_sigops + 0.001*sighash < 2,000,000

That provides worst case blocksize of 4MB, worst case sigops of 40,000
and worst case sighash bytes of 2GB. Given the separate limit on sighash
bytes and the improvements from libsecp256k1 I think 40k sigops should
be fine, but I'm happy to be corrected.

For a regular transaction, of say 380 bytes with 2 sigops and hashing
about 800 bytes, that uses up about 291 units of the limit, meaning
that if a block was full of transactions of that form, the limit would
be 6872 tx or 2.6MB per block (along with 13.7k sigops and ~5.5MB hashed
for signatures).  Those weightings could probably be improved by doing
some detailed analysis and measurements, but I think they're pretty
reasonable for round figures.

The main advantage is that it would prevent blocks being cheaply filled
up due to hitting one of the secondary limits but only paying for the
contribution to the primary limit (presumably block size), which avoids
denial of service spam attacks.

I think having the limit take UTXO increase (or decrease) into effect
would be helpful too; but I don't have a specific suggestion. If it's
just a matter of making the limit stronger (eg adding "0.25*max(0,change
in UTXO bytes)" to the formula on the left, but not changing the limit on
the right), that would be a soft-forking change that could be introduced
later, and maybe that's fine.

If there was time to actually iterate on this proposal, rather than an
apparent aim to get it out the door in the next month or two, I think it
would be good to also design it so that the parameters of the weighted
sum could be adjusted by a soft-fork in future rather than requiring a
hard fork every time a limit's reached, or a weighting can be relaxed.
But I don't think that's feasible to design within a few weeks, so I
think it's off the table given the activation goal.

Cheers,
aj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Pre-BIP Growth Soft-hardfork

[Luke Dashjr via bitcoin-dev]

Here's a draft BIP I wrote almost a year ago. I'm going to look into revising 
and completing it soon, and would welcome any suggestions for doing so.

This hardfork BIP aims to accomplish a few important things:
- Finally deploying proper merge-mining as Satoshi suggested before he left.
- Expanding the nonce space miners can scan in-chip, avoiding expensive
  calculations on the host controller as blocks get larger.
- Provide a way to safely deploy hardforks without risking leaving old nodes
  vulnerable to attack.

https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev