* [bitcoin-dev] summarising security assumptions (re cost metrics)
@ 2015-11-05 23:03 Adam Back
2015-11-05 23:33 ` Eric Voskuil
2015-11-08 14:54 ` Gavin Andresen
0 siblings, 2 replies; 10+ messages in thread
From: Adam Back @ 2015-11-05 23:03 UTC (permalink / raw)
To: Bitcoin Dev
Some thoughts, hope this is not off-topic.
Maybe we should summarise the security assumptions and design
requirements. It is often easier to have clear design discussions by
first articulating assumptions and requirements.
Validators: Economically dependent full nodes are an important part of
Bitcoin's security model because they assure Bitcoin security by
enforcing consensus rules. While full nodes do not have orphan
risk, we also dont want maliciously crafted blocks with pathological
validation cost to erode security by knocking reasonable spec full
nodes off the network on CPU (or bandwidth grounds).
Miners: Miners are in a commodity economics competitive environment
where various types of attacks and collusion, even with small
advantage, may see actual use due to the advantage being significant
relative to the at times low profit margin
It is quite important for bitcoin decentralisation security that small
miners not be significantly disadvantaged vs large miners. Similarly
it is important that there not be significant collusion advantages
that create policy centralisation as a side-effect (for example what
happened with "SPV mining" or validationless mining during BIP66
deployment). Examples of attacks include selfish-mining and
amplifying that kind of attack via artificially large or
pathologically expensive to validate blocks. Or elevating orphan risk
for others (a miner or collusion of miners is not at orphan risk for a
block they created).
Validators vs Miner decentralisation balance:
There is a tradeoff where we can tolerate weak miner decentralisation
if we can rely on good validator decentralisation or vice versa. But
both being weak is risky. Currently given mining centralisation
itself is weak, that makes validator decentralisation a critical
remaining defence - ie security depends more on validator
decentralisation than it would if mining decentralisation was in a
better shape.
Security:
We should consider the pathological case not average or default behaviour
because we can not assume people will follow the defaults, only the
consensus-enforced rules.
We should not discount attacks that have not seen exploitation to
date. We have maybe benefitted from universal good-will (everybody
thinks Bitcoin is cool, particularly people with skills to find and
exploit attacks).
We can consider a hierarchy of defences most secure to least:
1. consensus rule enforced (attacker loses block reward)
2. economic alignment (attacker loses money)
3. overt (profitable, but overt attacks are less likely to be exploited)
4. meta-incentive (relying on meta-incentive to not damage the ecosystem only)
Best practices:
We might want to list some best practices that are important for the
health and security of the Bitcoin network.
Rule of thumb KISS stuff:
We should aim to keep things simple in general and to avoid creating
complex optimisation problems for transaction processors, wallets,
miners.
We may want to consider an incremental approach (shorter-time frame or
less technically ambitious) in the interests of simplifying and
getting something easier to arrive at consensus, and thus faster to
deploy.
We should not let the perfect be the enemy of the good. But we should
not store new problems for the future, costs are stacked in favour of
getting it right vs A/B testing on the live network.
Not everything maybe fixable in one go for complexity reasons or for
the reason that there is no clear solution for some issues. We should
work incrementally.
Adam
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-05 23:03 [bitcoin-dev] summarising security assumptions (re cost metrics) Adam Back
@ 2015-11-05 23:33 ` Eric Voskuil
2015-11-06 1:56 ` Jeremy
2015-11-06 8:05 ` Chris Priest
2015-11-08 14:54 ` Gavin Andresen
1 sibling, 2 replies; 10+ messages in thread
From: Eric Voskuil @ 2015-11-05 23:33 UTC (permalink / raw)
To: Adam Back, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]
On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
> ...
> Validators: Economically dependent full nodes are an important part of
> Bitcoin's security model because they assure Bitcoin security by
> enforcing consensus rules. While full nodes do not have orphan
> risk, we also dont want maliciously crafted blocks with pathological
> validation cost to erode security by knocking reasonable spec full
> nodes off the network on CPU (or bandwidth grounds).
> ...
> Validators vs Miner decentralisation balance:
>
> There is a tradeoff where we can tolerate weak miner decentralisation
> if we can rely on good validator decentralisation or vice versa. But
> both being weak is risky. Currently given mining centralisation
> itself is weak, that makes validator decentralisation a critical
> remaining defence - ie security depends more on validator
> decentralisation than it would if mining decentralisation was in a
> better shape.
This side of the security model seems underappreciated, if not poorly
understood. Weakening is not just occurring because of the proliferation
of non-validating wallet software and centralized (web) wallets, but
also centralized Bitcoin APIs.
Over time developers tend to settle on a couple of API providers for a
given problem. Bing and Google for search and mapping, for example. All
applications and users of them, depending on an API service, reduce to a
single validator. Imagine most Bitcoin applications built on the
equivalent of Bing and Google.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-05 23:33 ` Eric Voskuil
@ 2015-11-06 1:56 ` Jeremy
2015-11-06 8:05 ` Chris Priest
1 sibling, 0 replies; 10+ messages in thread
From: Jeremy @ 2015-11-06 1:56 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]
I'd also like to see some more formal analysis of the notion that "$10 in
the hand of 10 people is more than $50 in the hand of two, or $100 in the
hand of one". I think this encapsulates the security assumption on why we
want decentralization at all.
This is a very critical property bitcoin exploits for being able to
transact large amounts, among other things. (Closely related is the notion
that defecting will destroy all the value...)
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Thu, Nov 5, 2015 at 6:33 PM, Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
> > ...
> > Validators: Economically dependent full nodes are an important part of
> > Bitcoin's security model because they assure Bitcoin security by
> > enforcing consensus rules. While full nodes do not have orphan
> > risk, we also dont want maliciously crafted blocks with pathological
> > validation cost to erode security by knocking reasonable spec full
> > nodes off the network on CPU (or bandwidth grounds).
> > ...
> > Validators vs Miner decentralisation balance:
> >
> > There is a tradeoff where we can tolerate weak miner decentralisation
> > if we can rely on good validator decentralisation or vice versa. But
> > both being weak is risky. Currently given mining centralisation
> > itself is weak, that makes validator decentralisation a critical
> > remaining defence - ie security depends more on validator
> > decentralisation than it would if mining decentralisation was in a
> > better shape.
>
> This side of the security model seems underappreciated, if not poorly
> understood. Weakening is not just occurring because of the proliferation
> of non-validating wallet software and centralized (web) wallets, but
> also centralized Bitcoin APIs.
>
> Over time developers tend to settle on a couple of API providers for a
> given problem. Bing and Google for search and mapping, for example. All
> applications and users of them, depending on an API service, reduce to a
> single validator. Imagine most Bitcoin applications built on the
> equivalent of Bing and Google.
>
> e
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3515 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-05 23:33 ` Eric Voskuil
2015-11-06 1:56 ` Jeremy
@ 2015-11-06 8:05 ` Chris Priest
2015-11-06 14:08 ` Adam Back
1 sibling, 1 reply; 10+ messages in thread
From: Chris Priest @ 2015-11-06 8:05 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev
On 11/5/15, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
>> ...
>> Validators: Economically dependent full nodes are an important part of
>> Bitcoin's security model because they assure Bitcoin security by
>> enforcing consensus rules. While full nodes do not have orphan
>> risk, we also dont want maliciously crafted blocks with pathological
>> validation cost to erode security by knocking reasonable spec full
>> nodes off the network on CPU (or bandwidth grounds).
>> ...
>> Validators vs Miner decentralisation balance:
>>
>> There is a tradeoff where we can tolerate weak miner decentralisation
>> if we can rely on good validator decentralisation or vice versa. But
>> both being weak is risky. Currently given mining centralisation
>> itself is weak, that makes validator decentralisation a critical
>> remaining defence - ie security depends more on validator
>> decentralisation than it would if mining decentralisation was in a
>> better shape.
>
> This side of the security model seems underappreciated, if not poorly
> understood. Weakening is not just occurring because of the proliferation
> of non-validating wallet software and centralized (web) wallets, but
> also centralized Bitcoin APIs.
>
> Over time developers tend to settle on a couple of API providers for a
> given problem. Bing and Google for search and mapping, for example. All
> applications and users of them, depending on an API service, reduce to a
> single validator. Imagine most Bitcoin applications built on the
> equivalent of Bing and Google.
>
> e
>
>
I disagree. I think blockchain APIs are a good thing for
decentralization. There aren't just 3 or 4 blockexplorer APIs out
there, there are dozens. Each API returns essentially the same data,
so they are all interchangeable. Take a look at this python package:
https://github.com/priestc/moneywagon
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-06 8:05 ` Chris Priest
@ 2015-11-06 14:08 ` Adam Back
2015-11-06 23:41 ` Chris Priest
0 siblings, 1 reply; 10+ messages in thread
From: Adam Back @ 2015-11-06 14:08 UTC (permalink / raw)
To: Chris Priest; +Cc: Bitcoin Dev
You're right that it is better that there be more APIs than fewer,
that is less of a single point of failure. It also depends what you
mean by APIs: using an API to have a second cross-check of information
is quite different to building a wallet or business that only
interfaces with the blockchain via a 3rd party API. There are
different APIs also: some are additive eg they add a second signature
via multisig, but even those models while better can still be a mixed
story for security, if the user is not also checking their own
full-node or checking SPV to make the first signature.
Power users and businesses using APIs instead of running a full-node,
or instead of doing SPV checks, should be clear about the API and what
security they are delegating to a third party, and whether they have a
reason to trust the governance and security competence of the third
party: in the simplest case it can reduce their and their users
security below SPV.
The bigger point however, which Erik explained, was: widespread use of
APIs as a sole means of interfacing with the blockchain also
contributes to reducing network security for everyone, because it
erodes the consensus rule validation security described under
"Validators" in the OP.
Adam
On 6 November 2015 at 09:05, Chris Priest <cp368202@ohiou•edu> wrote:
> On 11/5/15, Eric Voskuil via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
>>> ...
>>> Validators: Economically dependent full nodes are an important part of
>>> Bitcoin's security model because they assure Bitcoin security by
>>> enforcing consensus rules. While full nodes do not have orphan
>>> risk, we also dont want maliciously crafted blocks with pathological
>>> validation cost to erode security by knocking reasonable spec full
>>> nodes off the network on CPU (or bandwidth grounds).
>>> ...
>>> Validators vs Miner decentralisation balance:
>>>
>>> There is a tradeoff where we can tolerate weak miner decentralisation
>>> if we can rely on good validator decentralisation or vice versa. But
>>> both being weak is risky. Currently given mining centralisation
>>> itself is weak, that makes validator decentralisation a critical
>>> remaining defence - ie security depends more on validator
>>> decentralisation than it would if mining decentralisation was in a
>>> better shape.
>>
>> This side of the security model seems underappreciated, if not poorly
>> understood. Weakening is not just occurring because of the proliferation
>> of non-validating wallet software and centralized (web) wallets, but
>> also centralized Bitcoin APIs.
>>
>> Over time developers tend to settle on a couple of API providers for a
>> given problem. Bing and Google for search and mapping, for example. All
>> applications and users of them, depending on an API service, reduce to a
>> single validator. Imagine most Bitcoin applications built on the
>> equivalent of Bing and Google.
>>
>> e
>>
>>
>
> I disagree. I think blockchain APIs are a good thing for
> decentralization. There aren't just 3 or 4 blockexplorer APIs out
> there, there are dozens. Each API returns essentially the same data,
> so they are all interchangeable. Take a look at this python package:
> https://github.com/priestc/moneywagon
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-06 14:08 ` Adam Back
@ 2015-11-06 23:41 ` Chris Priest
2015-11-07 0:44 ` Eric Voskuil
0 siblings, 1 reply; 10+ messages in thread
From: Chris Priest @ 2015-11-06 23:41 UTC (permalink / raw)
To: Adam Back; +Cc: Bitcoin Dev
> The bigger point however, which Erik explained, was: widespread use of
> APIs as a sole means of interfacing with the blockchain also
> contributes to reducing network security for everyone, because it
> erodes the consensus rule validation security described under
> "Validators" in the OP.
I completely disagree with this. You are implying that there is some
sort of ideal ratio of full nodes to 'client only' nodes that the
network must maintain. You seem to be implying that if that ideal
ratio is to somehow be disrupted, then security suffers. My question
to you is what is that ideal ratio and what methodology did you use to
come up with it?
The way I see it, the security of the system is independent on ratio
between full nodes and lightweight nodes.
In other words, if there are 100,000 lightweight wallets to 100 full
nodes, then you have the same security profile as one with 100,000
full nodes to 100 lightweight wallets.
I think most 'big blockers' think the same way I do, hence the rub
between the two camps.
Small block people need to make a better case as to how exactly full
node ratio relates to network security (especially the 'for everyone'
part), because the link is not clear to me at all. Small block people
seem to take this simple fact as self evident, but I just don't see
it.
On 11/6/15, Adam Back <adam@cypherspace•org> wrote:
> You're right that it is better that there be more APIs than fewer,
> that is less of a single point of failure. It also depends what you
> mean by APIs: using an API to have a second cross-check of information
> is quite different to building a wallet or business that only
> interfaces with the blockchain via a 3rd party API. There are
> different APIs also: some are additive eg they add a second signature
> via multisig, but even those models while better can still be a mixed
> story for security, if the user is not also checking their own
> full-node or checking SPV to make the first signature.
>
> Power users and businesses using APIs instead of running a full-node,
> or instead of doing SPV checks, should be clear about the API and what
> security they are delegating to a third party, and whether they have a
> reason to trust the governance and security competence of the third
> party: in the simplest case it can reduce their and their users
> security below SPV.
>
> The bigger point however, which Erik explained, was: widespread use of
> APIs as a sole means of interfacing with the blockchain also
> contributes to reducing network security for everyone, because it
> erodes the consensus rule validation security described under
> "Validators" in the OP.
>
> Adam
>
>
> On 6 November 2015 at 09:05, Chris Priest <cp368202@ohiou•edu> wrote:
>> On 11/5/15, Eric Voskuil via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
>>>> ...
>>>> Validators: Economically dependent full nodes are an important part of
>>>> Bitcoin's security model because they assure Bitcoin security by
>>>> enforcing consensus rules. While full nodes do not have orphan
>>>> risk, we also dont want maliciously crafted blocks with pathological
>>>> validation cost to erode security by knocking reasonable spec full
>>>> nodes off the network on CPU (or bandwidth grounds).
>>>> ...
>>>> Validators vs Miner decentralisation balance:
>>>>
>>>> There is a tradeoff where we can tolerate weak miner decentralisation
>>>> if we can rely on good validator decentralisation or vice versa. But
>>>> both being weak is risky. Currently given mining centralisation
>>>> itself is weak, that makes validator decentralisation a critical
>>>> remaining defence - ie security depends more on validator
>>>> decentralisation than it would if mining decentralisation was in a
>>>> better shape.
>>>
>>> This side of the security model seems underappreciated, if not poorly
>>> understood. Weakening is not just occurring because of the proliferation
>>> of non-validating wallet software and centralized (web) wallets, but
>>> also centralized Bitcoin APIs.
>>>
>>> Over time developers tend to settle on a couple of API providers for a
>>> given problem. Bing and Google for search and mapping, for example. All
>>> applications and users of them, depending on an API service, reduce to a
>>> single validator. Imagine most Bitcoin applications built on the
>>> equivalent of Bing and Google.
>>>
>>> e
>>>
>>>
>>
>> I disagree. I think blockchain APIs are a good thing for
>> decentralization. There aren't just 3 or 4 blockexplorer APIs out
>> there, there are dozens. Each API returns essentially the same data,
>> so they are all interchangeable. Take a look at this python package:
>> https://github.com/priestc/moneywagon
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-06 23:41 ` Chris Priest
@ 2015-11-07 0:44 ` Eric Voskuil
0 siblings, 0 replies; 10+ messages in thread
From: Eric Voskuil @ 2015-11-07 0:44 UTC (permalink / raw)
To: Chris Priest, Adam Back; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5485 bytes --]
On 11/06/2015 03:41 PM, Chris Priest wrote:
>> The bigger point however, which Erik explained, was: widespread use of
>> APIs as a sole means of interfacing with the blockchain also
>> contributes to reducing network security for everyone, because it
>> erodes the consensus rule validation security described under
>> "Validators" in the OP.
>
> I completely disagree with this. You are implying that there is some
> sort of ideal ratio of full nodes to 'client only' nodes that the
> network must maintain. You seem to be implying that if that ideal
> ratio is to somehow be disrupted, then security suffers. My question
> to you is what is that ideal ratio and what methodology did you use to
> come up with it?
Nobody has advocated a golden ratio.
> The way I see it, the security of the system is independent on ratio
> between full nodes and lightweight nodes.
>
> In other words, if there are 100,000 lightweight wallets to 100 full
> nodes, then you have the same security profile as one with 100,000
> full nodes to 100 lightweight wallets.
This is a false dichotomy. Both scenarios are poor for security, as
nobody with a wallet is validating. It's entirely possible, even
probable, that one person controls all of the nodes.
> I think most 'big blockers' think the same way I do, hence the rub
> between the two camps.
>
> Small block people need to make a better case as to how exactly full
> node ratio relates to network security (especially the 'for everyone'
> part), because the link is not clear to me at all. Small block people
> seem to take this simple fact as self evident, but I just don't see
> it.
Fewer people independently validating their own transactions means trust
is placed in fewer people. The degenerate case of one validator and
everyone trusting it is dispositive, and equates roughly to the Federal
Reserve.
> On 11/6/15, Adam Back <adam@cypherspace•org> wrote:
>> You're right that it is better that there be more APIs than fewer,
>> that is less of a single point of failure. It also depends what you
>> mean by APIs: using an API to have a second cross-check of information
>> is quite different to building a wallet or business that only
>> interfaces with the blockchain via a 3rd party API. There are
>> different APIs also: some are additive eg they add a second signature
>> via multisig, but even those models while better can still be a mixed
>> story for security, if the user is not also checking their own
>> full-node or checking SPV to make the first signature.
>>
>> Power users and businesses using APIs instead of running a full-node,
>> or instead of doing SPV checks, should be clear about the API and what
>> security they are delegating to a third party, and whether they have a
>> reason to trust the governance and security competence of the third
>> party: in the simplest case it can reduce their and their users
>> security below SPV.
>>
>> The bigger point however, which Erik explained, was: widespread use of
>> APIs as a sole means of interfacing with the blockchain also
>> contributes to reducing network security for everyone, because it
>> erodes the consensus rule validation security described under
>> "Validators" in the OP.
>>
>> Adam
>>
>>
>> On 6 November 2015 at 09:05, Chris Priest <cp368202@ohiou•edu> wrote:
>>> On 11/5/15, Eric Voskuil via bitcoin-dev
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>> On 11/05/2015 03:03 PM, Adam Back via bitcoin-dev wrote:
>>>>> ...
>>>>> Validators: Economically dependent full nodes are an important part of
>>>>> Bitcoin's security model because they assure Bitcoin security by
>>>>> enforcing consensus rules. While full nodes do not have orphan
>>>>> risk, we also dont want maliciously crafted blocks with pathological
>>>>> validation cost to erode security by knocking reasonable spec full
>>>>> nodes off the network on CPU (or bandwidth grounds).
>>>>> ...
>>>>> Validators vs Miner decentralisation balance:
>>>>>
>>>>> There is a tradeoff where we can tolerate weak miner decentralisation
>>>>> if we can rely on good validator decentralisation or vice versa. But
>>>>> both being weak is risky. Currently given mining centralisation
>>>>> itself is weak, that makes validator decentralisation a critical
>>>>> remaining defence - ie security depends more on validator
>>>>> decentralisation than it would if mining decentralisation was in a
>>>>> better shape.
>>>>
>>>> This side of the security model seems underappreciated, if not poorly
>>>> understood. Weakening is not just occurring because of the proliferation
>>>> of non-validating wallet software and centralized (web) wallets, but
>>>> also centralized Bitcoin APIs.
>>>>
>>>> Over time developers tend to settle on a couple of API providers for a
>>>> given problem. Bing and Google for search and mapping, for example. All
>>>> applications and users of them, depending on an API service, reduce to a
>>>> single validator. Imagine most Bitcoin applications built on the
>>>> equivalent of Bing and Google.
>>>>
>>>> e
>>>>
>>>>
>>>
>>> I disagree. I think blockchain APIs are a good thing for
>>> decentralization. There aren't just 3 or 4 blockexplorer APIs out
>>> there, there are dozens. Each API returns essentially the same data,
>>> so they are all interchangeable. Take a look at this python package:
>>> https://github.com/priestc/moneywagon
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-05 23:03 [bitcoin-dev] summarising security assumptions (re cost metrics) Adam Back
2015-11-05 23:33 ` Eric Voskuil
@ 2015-11-08 14:54 ` Gavin Andresen
2015-11-08 17:19 ` Bryan Bishop
1 sibling, 1 reply; 10+ messages in thread
From: Gavin Andresen @ 2015-11-08 14:54 UTC (permalink / raw)
To: Adam Back; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 7785 bytes --]
On Thu, Nov 5, 2015 at 11:03 PM, Adam Back via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Some thoughts, hope this is not off-topic.
>
> Maybe we should summarise the security assumptions and design
> requirements. It is often easier to have clear design discussions by
> first articulating assumptions and requirements.
>
> Validators: Economically dependent full nodes are an important part of
> Bitcoin's security model because they assure Bitcoin security by
> enforcing consensus rules. While full nodes do not have orphan
> risk, we also dont want maliciously crafted blocks with pathological
> validation cost to erode security by knocking reasonable spec full
> nodes off the network on CPU (or bandwidth grounds).
>
Agreed. That is why BIP101 / BitcoinXT includes code to limit the relay and
validation cost of blocks.
>
> Miners: Miners are in a commodity economics competitive environment
> where various types of attacks and collusion, even with small
> advantage, may see actual use due to the advantage being significant
> relative to the at times low profit margin
>
Agreed, with a quibble: mining economics means they will ALWAYS have a low
profit margin.
>
> It is quite important for bitcoin decentralisation security that small
> miners not be significantly disadvantaged vs large miners. Similarly
> it is important that there not be significant collusion advantages
> that create policy centralisation as a side-effect (for example what
> happened with "SPV mining" or validationless mining during BIP66
> deployment). Examples of attacks include selfish-mining and
> amplifying that kind of attack via artificially large or
> pathologically expensive to validate blocks. Or elevating orphan risk
> for others (a miner or collusion of miners is not at orphan risk for a
> block they created).
>
Okey dokey-- perhaps we should have another discussion about SPV mining, as
far as I know it harmed nobody besides the miners who mindlessly created
invalid, empty blocks (well, and besides being very annoying for developers
who had to figure out what was happening and get the offending miners to do
the right thing).
In any case, it seems to me all of this (except perhaps selfish mining) is
independent of the maximum block size, and solutions for all of the above
(including selfish mining) should be pursued regardless of what is done
with the max block size (e.g. I sent Ittay and Gun email a few minutes ago
with some might-be-wong-ideas for how weak block announcements might be
used to detect selfish mining).
>
> Validators vs Miner decentralisation balance:
>
> There is a tradeoff where we can tolerate weak miner decentralisation
> if we can rely on good validator decentralisation or vice versa. But
> both being weak is risky. Currently given mining centralisation
> itself is weak, that makes validator decentralisation a critical
> remaining defence - ie security depends more on validator
> decentralisation than it would if mining decentralisation was in a
> better shape.
>
I'm very disappointed you don't mention the tradeoff at "the other end of
the bathtub" -- Key-holder versus Validator decentralization balance. Did
you see the excellent Poon/Dryja "bathtub" presentation at Montreal?
https://scalingbitcoin.org/montreal2015/presentations/Day2/3-JosephPoonAndThaddeusDryja.pdf
Security:
>
> We should consider the pathological case not average or default behaviour
> because we can not assume people will follow the defaults, only the
> consensus-enforced rules.
>
Agreed, which is why BIP101/XT consider pathological behavior.
>
> We should not discount attacks that have not seen exploitation to
> date. We have maybe benefitted from universal good-will (everybody
> thinks Bitcoin is cool, particularly people with skills to find and
> exploit attacks).
>
Disagree on wording: we should not ignore attacks that have not seen
exploitation. But in the never-ending-list of things to be worried about
and to write code for, attacks that have not been seen should be lower
priority than attacks that have been seen, either in Bitcoin or elsewhere.
E.g. Bitcoin has never seen a buffer-overflow attack, but we absolutely
positively need to put a very high priority on the network attack surface
-- we know buffer-overflow attacks are commonly exploited.
On the other hand, Bitcoin has never seen a "Goldfinger attack" (take a big
short position on Bitcoin, then find a way to destroy confidence so the
price drops and you can profit), and "Goldfinger attacks" don't seem to be
common anywhere (you don't see people taking huge short positions in
companies and then bombing their factories). There might be a reason
Bitcoin is more vulnerable, or the same checks-and-balances (e.g. whoever
took the other side of the large short has a strong incentive to report
you, and assuming you got paid in something other than Bitcoin that is
probably possible).
(Aside: anybody who wants to talk about the likelihood of "Goldfinger
attacks" please start a thread somewhere else, I don't think that's
appropriate for bitcoin-dev).
>
> We can consider a hierarchy of defences most secure to least:
>
> 1. consensus rule enforced (attacker loses block reward)
> 2. economic alignment (attacker loses money)
> 3. overt (profitable, but overt attacks are less likely to be exploited)
> 4. meta-incentive (relying on meta-incentive to not damage the ecosystem
> only)
>
Agreed.
> Best practices:
>
> We might want to list some best practices that are important for the
> health and security of the Bitcoin network.
>
> Rule of thumb KISS stuff:
>
> We should aim to keep things simple in general and to avoid creating
> complex optimisation problems for transaction processors, wallets,
> miners.
>
I agree with KISS.
I think we can't avoid creating complex optimization problems sometimes--
see, for example, the difficulty of a wallet predicting what transaction
fee is needed for a transaction to get confirmed in X blocks (lots of
factors involved-- max block size, time since last block, miner policy as
expressed in previous blocks, transactions currently waiting in
mempool....). I do agree we should prefer simple optimization problems
over complex wherever we can.
> We may want to consider an incremental approach (shorter-time frame or
> less technically ambitious) in the interests of simplifying and
> getting something easier to arrive at consensus, and thus faster to
> deploy.
>
Or we may want to go with something that is already tested and deployed...
>
> We should not let the perfect be the enemy of the good. But we should
> not store new problems for the future, costs are stacked in favour of
> getting it right vs A/B testing on the live network.
>
I disagree about "storing new problems for the future." We don't know what
the problems will be in the future, so there is alway a leap of faith that
future engineers will be smart enough to fix the engineering problems that
arise (see the worries over quantum computing advances making ECDSA
obsolete) -- ESPECIALLY if we have thumbnail sketches of solutions that
we're reasonably certain will work (e.g. switching to a quantum-resistant
signature algorithm via soft-fork).
>
> Not everything maybe fixable in one go for complexity reasons or for
> the reason that there is no clear solution for some issues. We should
> work incrementally.
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
I think the disagreement is how big a change fits into the definition of
"incrementally."
As Jeff Garzik has pointed out, the recent change from "we never hit the
maximum block size limit" to "we regularly run into the maximum block size
limit" was a large, NON-incremental change...
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 11126 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-08 14:54 ` Gavin Andresen
@ 2015-11-08 17:19 ` Bryan Bishop
2015-11-09 16:27 ` Gavin Andresen
0 siblings, 1 reply; 10+ messages in thread
From: Bryan Bishop @ 2015-11-08 17:19 UTC (permalink / raw)
To: Gavin Andresen, Bryan Bishop; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
On Sun, Nov 8, 2015 at 8:54 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I'm very disappointed you don't mention the tradeoff at "the other end of
> the bathtub" -- Key-holder versus Validator decentralization balance
Gavin, could you please provide some clarity around the definition and
meaning of "key-holder [decentralization]"? Is this about the absolute
number of key-holders? or rather about the number of transactions (per unit
time?) that key-holders make? Both/other?
Anyone can generate a private key, and anyone can sign a transaction
spending to a new commitment. Child-pays-for-parent could be used when
transaction fees are too high. Perhaps more interesting would be something
like lightning network payment channels, where only the commitment
transaction needs to be in the blockchain history; does that count as
key-holder decentralization at all?
Also, consider the following scenario. Suppose there's a bunch of
merge-mined sidechains that are mainnet BTC-pegged, and these sidechains
are accessible by the lightning network protocol (multi-chain payments).
Suppose also that on the different sidechains there are different
transaction fee trends because of various technical differences underlying
consensus or a different blockchain implementation (who knows). When
someone routes payments to one of those different sidechains, because UTXOs
could be cheaper over there due to different fee pressures, ... would that
count as key-holder decentralization? Some of this scenario is described
here, although not in more detail:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html
Previously there has been the suggestion to use BTC-pegged merge-mined
chains to handle excess transaction demand:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004797.html
I notice that in the Poon file there is a concern regarding "only 10 key
holders", but how does that scenario really work? I think the actual
scenario they mean to describe is "there's always a transaction backlog
where the fees are so high that lower fee transactions can never get
confirmations". So, more specifically, the scenario would have to be
"lightning network exists and is working, and no lightning node can ever
route enough different payments to commit to the blockchain under any
circumstance". How would that be possible? Wouldn't most participants
prefer the relatively instantaneous transactions of lightning, even if they
can afford extremely high fees? Seems like the settlements have all
necessary reason to actually happen, don't know what your concern is,
please send help.
I don't mean to put words in anyone's mouth, everything above is mostly
asking for clarification around definitions. Some of these questions are
repeats from:
http://gnusha.org/bitcoin-wizards/2015-11-08.log
Thank you.
- Bryan
http://heybryan.org/
1 512 203 0507
[-- Attachment #2: Type: text/html, Size: 4372 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] summarising security assumptions (re cost metrics)
2015-11-08 17:19 ` Bryan Bishop
@ 2015-11-09 16:27 ` Gavin Andresen
0 siblings, 0 replies; 10+ messages in thread
From: Gavin Andresen @ 2015-11-09 16:27 UTC (permalink / raw)
To: Bryan Bishop; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Sun, Nov 8, 2015 at 12:19 PM, Bryan Bishop <kanzure@gmail•com> wrote:
> Gavin, could you please provide some clarity around the definition and
> meaning of "key-holder [decentralization]"? Is this about the absolute
> number of key-holders? or rather about the number of transactions (per unit
> time?) that key-holders make? Both/other?
>
Both. If few transactions are possible, then that limits the number of
key-holders who can participate in the system.
Imagine the max block size was really small, and stretch your imagination
and just assume there would be enough demand that those small number of
transactions pay enough transaction fees to secure the network. Each
transaction must, therefore, pay a high fee. That limits the number of
keyholders to institutions with very-large-value transactions-- it is the
"Bitcoin as a clearing network for big financial players" model.
Using the Lightning Network doesn't help, since every Lightning Network
transaction IS a set of Bitcoin transactions, ready to be dropped onto the
main chain. If those Lightning Network transactions don't have enough fees,
then the whole security of the Lightning Protocol falls apart (since it
relies on being able to get timelocked transactions confirmed on the main
chain in case your trading partner cheats).
There is video of the Poon/Dryja talk:
https://youtu.be/TgjrS-BPWDQ?t=41m58s
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2226 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-11-09 16:27 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-05 23:03 [bitcoin-dev] summarising security assumptions (re cost metrics) Adam Back
2015-11-05 23:33 ` Eric Voskuil
2015-11-06 1:56 ` Jeremy
2015-11-06 8:05 ` Chris Priest
2015-11-06 14:08 ` Adam Back
2015-11-06 23:41 ` Chris Priest
2015-11-07 0:44 ` Eric Voskuil
2015-11-08 14:54 ` Gavin Andresen
2015-11-08 17:19 ` Bryan Bishop
2015-11-09 16:27 ` Gavin Andresen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox