[bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Sergio Demian Lerner]

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

What would you do?

a. Double the block size
b. Reduce the block rate to a half (average 5 minute blocks)

Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay network has shown that block
propagation is not an issue for such as small change. Mining centralization
won't radically change for a 2x adjustment.

So what would be best for Bitcoin?

I suspect some (if not most of you) would choose b. Because reducing the
block interval saves us real time. Waiting 30 minutes for a 3-block
confirmation is... such a long time! Time that we value. Time that
sometimes we waste waiting. Time that makes a difference for us. Doubling
the block size does not change the user perception of Bitcoin in any way.

Then why most discussions go around doubling the block size?

Each change require less than 20 lines of code (*) in the reference code,
and minimum change in other wallets.

Currently there is no idle mining hardware for hire, so the security of six
10-minute block confirmation is equivalent to the security of six 5-minute
block confirmations, as described in Satoshi's paper (if there were 51%
spare mining hardware for hire, then obviously hiring that hardware for 30
minutes would cost less than hiring it for 1 hour).

Why we discuss a 2x block size increase and not a 1/2 block interval
reduction? Aren't we Bitcoin users after all?

Best regards,
 Sergio.

(*) b requires increasing the transaction version number, to support the
old nLockTime rate.

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Mark Friedenbach]

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

Because halving the block interval comes with costs to SPV proofs (which
double the number of headers) and mining centralization (doubles the
selfish mining effect of latency) for the questionable benefit of a block
expectation time that is still measured in minutes, not seconds.

Doubling the block size is safer than halving the block interval, for the
same effect in aggregate transactions per second.

On Fri, Aug 7, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What would you do?
>
> a. Double the block size
> b. Reduce the block rate to a half (average 5 minute blocks)
>
> Suppose this is a one time hard fork. There no drastic technical problems
> with any of them: "SPV" mining and the relay network has shown that block
> propagation is not an issue for such as small change. Mining centralization
> won't radically change for a 2x adjustment.
>
> So what would be best for Bitcoin?
>
> I suspect some (if not most of you) would choose b. Because reducing the
> block interval saves us real time. Waiting 30 minutes for a 3-block
> confirmation is... such a long time! Time that we value. Time that
> sometimes we waste waiting. Time that makes a difference for us. Doubling
> the block size does not change the user perception of Bitcoin in any way.
>
> Then why most discussions go around doubling the block size?
>
> Each change require less than 20 lines of code (*) in the reference code,
> and minimum change in other wallets.
>
> Currently there is no idle mining hardware for hire, so the security of
> six 10-minute block confirmation is equivalent to the security of six
> 5-minute block confirmations, as described in Satoshi's paper (if there
> were 51% spare mining hardware for hire, then obviously hiring that
> hardware for 30 minutes would cost less than hiring it for 1 hour).
>
> Why we discuss a 2x block size increase and not a 1/2 block interval
> reduction? Aren't we Bitcoin users after all?
>
> Best regards,
>  Sergio.
>
> (*) b requires increasing the transaction version number, to support the
> old nLockTime rate.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Sergio Demian Lerner]

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

Mark,
It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.

Obviously this is not a technical response to the technical issues you
argue. But "minutes" is a time scale we humans use to measure time very
often.

:)




On Fri, Aug 7, 2015 at 6:27 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> Because halving the block interval comes with costs to SPV proofs (which
> double the number of headers) and mining centralization (doubles the
> selfish mining effect of latency) for the questionable benefit of a block
> expectation time that is still measured in minutes, not seconds.
>
> Doubling the block size is safer than halving the block interval, for the
> same effect in aggregate transactions per second.
>
> On Fri, Aug 7, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> What would you do?
>>
>> a. Double the block size
>> b. Reduce the block rate to a half (average 5 minute blocks)
>>
>> Suppose this is a one time hard fork. There no drastic technical problems
>> with any of them: "SPV" mining and the relay network has shown that block
>> propagation is not an issue for such as small change. Mining centralization
>> won't radically change for a 2x adjustment.
>>
>> So what would be best for Bitcoin?
>>
>> I suspect some (if not most of you) would choose b. Because reducing the
>> block interval saves us real time. Waiting 30 minutes for a 3-block
>> confirmation is... such a long time! Time that we value. Time that
>> sometimes we waste waiting. Time that makes a difference for us. Doubling
>> the block size does not change the user perception of Bitcoin in any way.
>>
>> Then why most discussions go around doubling the block size?
>>
>> Each change require less than 20 lines of code (*) in the reference code,
>> and minimum change in other wallets.
>>
>> Currently there is no idle mining hardware for hire, so the security of
>> six 10-minute block confirmation is equivalent to the security of six
>> 5-minute block confirmations, as described in Satoshi's paper (if there
>> were 51% spare mining hardware for hire, then obviously hiring that
>> hardware for 30 minutes would cost less than hiring it for 1 hour).
>>
>> Why we discuss a 2x block size increase and not a 1/2 block interval
>> reduction? Aren't we Bitcoin users after all?
>>
>> Best regards,
>>  Sergio.
>>
>> (*) b requires increasing the transaction version number, to support the
>> old nLockTime rate.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Natanael]

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

Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> Mark,
> It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.
>
> Obviously this is not a technical response to the technical issues you
argue. But "minutes" is a time scale we humans use to measure time very
often.

But what's more likely to matter is seconds. What you need then is some
variant of multisignature notaries (Greenaddress.it, lightning network),
where the combination of economic incentives and legal liability gives you
the assurance of doublespend protection from the time of publication of the
transaction to the first block confirmation.

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Mark Friedenbach]

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

Actually I gave a cached answer earlier which on further review may need
updating. (Bad Mark!)

I presume by "what's more likely to matter is seconds" you are referencing
point of sale. As you mention yourself, lightning network or green address
style payment escrow obviates the need for short inter-block times.

But with lightning there is a danger of channels being exhausted in the
time between blocks, causing the need for new channels to be established.
So lightning does in fact benefit from moderately shorter inter-block
times, although how much of an issue this will be is anyone's guess now.

Still the first two points about larger SPV proofs and selfish mining still
hold true, which sets the bar particularly high for justifying more
frequent blocks.

On Fri, Aug 7, 2015 at 3:46 PM, Natanael <natanael.l@gmail.com> wrote:

> Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
> >
> > Mark,
> > It took you 3 minutes to respond to my e-mail. And I responded to you 4
> minutes later. If you had responded to me in 10 minutes, I would be of out
> the office and we wouldn't have this dialogue. So 5 minutes is a lot of
> time.
> >
> > Obviously this is not a technical response to the technical issues you
> argue. But "minutes" is a time scale we humans use to measure time very
> often.
>
> But what's more likely to matter is seconds. What you need then is some
> variant of multisignature notaries (Greenaddress.it, lightning network),
> where the combination of economic incentives and legal liability gives you
> the assurance of doublespend protection from the time of publication of the
> transaction to the first block confirmation.
>

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Sergio Demian Lerner]

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

In some rare occasions in everyday life, what matters is seconds. Like when
paying for parking in the car while some other cars are behind you in the
line. You don't want them to get upset.

I takes me tens of minutes to shop. But once you choose your merchandise
and your payment starts processing, if the payment system allows several
payments to be pending simultaneously and you're not blocking the next
person to pay, then I don't care waiting some minutes for confirmation. But
saving 10 minutes of confirmation is a lot.

I ague that our time is mostly measured in minutes (but I don't have any
sociological, cultural, genetic or anthropological evidence). It takes
minutes to read an e-mail, minutes to correct a bug, minutes to have lunch,
minutes to drive to the office, minutes to talk to your kids. A payment
taking 1 minute is much better than a payment taking 10. If I could choose
a single thing to change to Bitcoin, I would lower the payment time, even
within the minute scale.

Sergio



On Fri, Aug 7, 2015 at 7:46 PM, Natanael <natanael.l@gmail.com> wrote:

> Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
> >
> > Mark,
> > It took you 3 minutes to respond to my e-mail. And I responded to you 4
> minutes later. If you had responded to me in 10 minutes, I would be of out
> the office and we wouldn't have this dialogue. So 5 minutes is a lot of
> time.
> >
> > Obviously this is not a technical response to the technical issues you
> argue. But "minutes" is a time scale we humans use to measure time very
> often.
>
> But what's more likely to matter is seconds. What you need then is some
> variant of multisignature notaries (Greenaddress.it, lightning network),
> where the combination of economic incentives and legal liability gives you
> the assurance of doublespend protection from the time of publication of the
> transaction to the first block confirmation.
>

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Mark Friedenbach]

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

Then I would suggest working on payment channel networks. No decrease of
the interblock time will ever compete with the approximately instant time
it takes to validate a microchannel payment.

On Fri, Aug 7, 2015 at 4:08 PM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:

> In some rare occasions in everyday life, what matters is seconds. Like
> when paying for parking in the car while some other cars are behind you in
> the line. You don't want them to get upset.
>
> I takes me tens of minutes to shop. But once you choose your merchandise
> and your payment starts processing, if the payment system allows several
> payments to be pending simultaneously and you're not blocking the next
> person to pay, then I don't care waiting some minutes for confirmation. But
> saving 10 minutes of confirmation is a lot.
>
> I ague that our time is mostly measured in minutes (but I don't have any
> sociological, cultural, genetic or anthropological evidence). It takes
> minutes to read an e-mail, minutes to correct a bug, minutes to have lunch,
> minutes to drive to the office, minutes to talk to your kids. A payment
> taking 1 minute is much better than a payment taking 10. If I could choose
> a single thing to change to Bitcoin, I would lower the payment time, even
> within the minute scale.
>
> Sergio
>
>
>
> On Fri, Aug 7, 2015 at 7:46 PM, Natanael <natanael.l@gmail.com> wrote:
>
>> Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org>:
>> >
>> > Mark,
>> > It took you 3 minutes to respond to my e-mail. And I responded to you 4
>> minutes later. If you had responded to me in 10 minutes, I would be of out
>> the office and we wouldn't have this dialogue. So 5 minutes is a lot of
>> time.
>> >
>> > Obviously this is not a technical response to the technical issues you
>> argue. But "minutes" is a time scale we humans use to measure time very
>> often.
>>
>> But what's more likely to matter is seconds. What you need then is some
>> variant of multisignature notaries (Greenaddress.it, lightning network),
>> where the combination of economic incentives and legal liability gives you
>> the assurance of doublespend protection from the time of publication of the
>> transaction to the first block confirmation.
>>
>
>

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Michael Ruddy]

Sergio, you raise an interesting question.

I had seen your message to the list related to this idea before [1],
so I went back to research what the viewpoints and conclusions were,
if any.

I didn't find anything too conclusive, but I did find some persuasive
points by Dave Hudson [2] [3] [4] [5] that seem to also favor
increasing the target block creation rate (decreasing the target time
interval between blocks).

Considering that increasing the target block creation rate could
reduce the effect of (but not solve [6]) the fundamental mismatch
between transaction creation and the Poisson process of block
discovery [7] and could reduce miner variance (possibly an aid to
miner decentralization), I think I'd go with option B to answer your
question.

I wonder why this does not seem to ever gain more traction when you
bring it up? The idea does not seem crazy.

[1]: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07663.html
[2]: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07665.html
[3]: https://twitter.com/hashingitcom/status/595615823340908545
[4]: https://twitter.com/hashingitcom/status/605443289379143680
[5]: http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
[6]: https://twitter.com/jgarzik/status/595611423151030272
[7]: http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Pieter Wuille]

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

On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> b. Reduce the block rate to a half (average 5 minute blocks)
>
> Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay network has shown that block
propagation is not an issue for such as small change. Mining centralization
won't radically change for a 2x adjustment.

I don't understand this. All problems that result from propagation delay
are literally doubled by doing so. Centralization pressure results from the
ratio between propagation time and interblock time. Efficient propagation
algorithms like the relay network make this presumably grow sublinear with
larger blocks, but changing the interblock time affects it exactly
proportionally.

All problems that result from propagation delay are literally doubled by
doing this. Doubling the block size has a smaller effect. You may argue
that these centralization effects are small, but reducing the interblock
time has a stronger effect on them than the block size.

Also, you seem to consider SPV mining a good thing? It requires trust
between miners that know eachother, and fundamentally breaks the security
assumption of SPV clients... and if the propagation/interblock ratio was
lower, SPV mining would have less effect. I'd say it is exactly a result of
the centralization pressure we're trying to avoid.

-- 
Pieter

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Sergio Demian Lerner]

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

On Mon, Aug 10, 2015 at 6:01 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > b. Reduce the block rate to a half (average 5 minute blocks)
> >
> > Suppose this is a one time hard fork. There no drastic technical
> problems with any of them: "SPV" mining and the relay network has shown
> that block propagation is not an issue for such as small change. Mining
> centralization won't radically change for a 2x adjustment.
>
> I don't understand this. All problems that result from propagation delay
> are literally doubled by doing so. Centralization pressure results from the
> ratio between propagation time and interblock time. Efficient propagation
> algorithms like the relay network make this presumably grow sublinear with
> larger blocks, but changing the interblock time affects it exactly
> proportionally.
>
What I'm saying is that this ratio may have improved 20x since miners began
using the TheBlueMatt relay network, so deteriorating the ratio 2x does not
put miners in a unknown future, but in an future which is far better than
the state they were a year ago.

But SPV mining has improved the ratio another 2x (because headers can be
pushed even faster, fit in a single network packet, and can do without
inv/getdata round-trips because they basically "pay" for the bandwidth
usage by its own proof of work).
With a better wire protocol you can "propagate" a 10 MB block faster that
the time it takes currently to propagate an empty block.
So 10x deterioration of the ratio would be still something acceptable.

All problems that result from propagation delay are literally doubled by
> doing this. Doubling the block size has a smaller effect. You may argue
> that these centralization effects are small, but reducing the interblock
> time has a stronger effect on them than the block size.
>
> Also, you seem to consider SPV mining a good thing?
>
I'm not saying it's a good thing. I'm saying that it's impossible to avoid.
It's a real incentive. It must exists so Bitcoin is incentive compatible.
We can talk for hours and hours and we won't prevent miners from doing it.
I predicted it back in 2013, without even being a miner myself. It's here
to stay. Forever. It's a pity Greg chose that awful name of "SPV" mining
instead some cool name like "Instant" mining that we could market as
Bitcoin latest feature :)

Do you consider the TheBlueMatt relay network a "good thing". NO! It's a
very bad centralization thing, but it is unavoidable. I would like the
relay network to be embedded on the standard network protocol, using local
route optimizations to reduce latency for block propagation (there is one
old paper on this, and it says that with local prioritization you can have
a lower bound to get a propagation latency of at most two times the optimal
value (possibly generated by the minimum spanning tree)).

It requires trust between miners that know eachother, and fundamentally
> breaks the security assumption of SPV clients...
>
No is does not. The incentive follows directly from the cheating cost (the
subsidy). Even if I don't know you, I know you wouldn't waste 25 BTC to try
to cheat me for 25 BTC with a probability of 1/100, that's for sure. On
average, you loose 24.75 BTC per cheat attempt.

"SPV" mining is safe as long as it is done for a certain bounded period of
time and bounded number of blocks (e.g: 30 seconds from that last validated
block, and no more than 1 non-validated block). SPV clients that accept a
transaction with 1 confirmation are already in danger of orphaning, and
long invalid "SPV" mining chain forks (as occurred last month) should never
had occurred if limits were in-place.

SPV mining incentive will stay until there is no subsidy, as many other
incentives. SPV mining also must be there to prevent malicious actors from
DoS-ing the relay network. If it's there, then the DoS incentive disappears.

Let's code "instant" mining into Bitcoin Core, and do it right.

Also as Michael Rudy points out, higher block rate means lower variance,
and that's good for miners. Last, as I already said, having a lower average
block interval strengthens Bitcoin value proposition, so miners would be
delighted that their bitcoins are more worthy.

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

Re: [bitcoin-dev] If you had a single chance to double the transactions/second Bitcoin allows...

[Pieter Wuille]

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

On Aug 11, 2015 12:11 AM, "Sergio Demian Lerner" <sergio.d.lerner@gmail.com>
wrote:
> What I'm saying is that this ratio may have improved 20x since miners
began using the TheBlueMatt relay network, so deteriorating the ratio 2x
does not put miners in a unknown future, but in an future which is far
better than the state they were a year ago.

It's still worse than doubling the block size, which was your main argument.

> But SPV mining has improved the ratio another 2x (because headers can be
pushed even faster, fit in a single network packet, and can do without
inv/getdata round-trips because they basically "pay" for the bandwidth
usage by its own proof of work).
> With a better wire protocol you can "propagate" a 10 MB block faster that
the time it takes currently to propagate an empty block.
> So 10x deterioration of the ratio would be still something acceptable.

So yes, better relay protocols (whether you consider "SPV mining" a form of
that or not) reduce the effect of the block size. That does not give any
benefit for reduced interblock times.

Your argument seems to be "centralization pressure is not bad now, because
it already improved a lot... so we can make it worse again by reducing
interblock time"? I disagree that it is not bad, and shorter blocks have
other downsides which were already mentioned.

>> Also, you seem to consider SPV mining a good thing?
>
> I'm not saying it's a good thing. I'm saying that it's impossible to
avoid. It's a real incentive. It must exists so Bitcoin is incentive
compatible. We can talk for hours and hours and we won't prevent miners
from doing it. I predicted it back in 2013, without even being a miner
myself. It's here to stay. Forever. It's a pity Greg chose that awful name
of "SPV" mining instead some cool name like "Instant" mining that we could
market as Bitcoin latest feature :)

>> It requires trust between miners that know eachother, and fundamentally
breaks the security assumption of SPV clients...
>
> No is does not.

The SPV security assumption is that no hashrate majority will collude in
order to make my transactions incorrectly look confirmed.

With validation-less mining, even a 0.1% hashrate that is part of a group
with 60% hashrate is enough to make that happen.

Of course they won't intentionally do that. No other miner would agree to
do validation-less mining with them again, making it harder for them to
compete. So it is not permissionless: you get higher profitability by
making an agreement with the largest hashrate. I think that is a much worse
centralization effect than having an optional centralized relay network
available... there could even be multiple such networks.

> The incentive follows directly from the cheating cost (the subsidy). Even
if I don't know you, I know you wouldn't waste 25 BTC to try to cheat me
for 25 BTC with a probability of 1/100, that's for sure. On average, you
loose 24.75 BTC per cheat attempt.

Per cheat attempt, or per bug.

> SPV mining incentive will stay until there is no subsidy, as many other
incentives. SPV mining also must be there to prevent malicious actors from
DoS-ing the relay network. If it's there, then the DoS incentive disappears.
>
> Let's code "instant" mining into Bitcoin Core, and do it right.

I thought about this too. Since headers-first it would be trivial to do: if
our best header is ahead of our best block, hand out an empty template in
createblocktemplate, and we're done.

Unfortunately, Greg Maxwell pointed out that this (even with a time limit)
amplifies selfish mining, since I can propagate headers before propagating
blocks, in order to make others temporarily work on top of my chain.

> Also as Michael Rudy points out, higher block rate means lower variance,
and that's good for miners. Last, as I already said, having a lower average
block interval strengthens Bitcoin value proposition, so miners would be
delighted that their bitcoins are more worthy.

Only a small constant factor, but yes.

-- 
Pieter

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