Re: [bitcoin-dev] High consensus fork system for scaling without limits

[Erik Aronesty via bitcoin-dev]

> 1. Allow users to signal readiness by publishing an EB. This EB is an
absolute upper bound, and cannot be overridden by miners. Current EB is
1MB, the status-quo.   Maybe EB can be configured in a config file, not a
UI, since it's an "advanced" feature.
>
> What does EB stand for?

Excessive block size.

> What is the point of users publishing an EB? Is it for miners to
determine what to set theirs to? If so, what about sybil attacks with fake
nodes publishing EBs?

You can't trivially fake coinbase's full node, or gemini's, etc.   Large
users would also be encouraged to report their EB's publically as well.

> How do users publish an EB? Do they use a transaction? Or is it something
that goes into the User Agent?

Same way a version string is published by a node.   Maybe *in* the version
string.

> How high can the EB go? What is its maximum?

Maybe 4MB for now?   Seems fine.   Trivial to change it later, since it's
not a fork to do so.

> 6. Core can (optionally) ship a version with a default EB in-line with
their own perceived consensus.

I would say that Core /should/ ship new versions with new default EB's
in-line with both miner and the economic majority after a 95% consensus
fork.

> 7. Some sort of versioning system is used to ensure that the two networks
(old and new) are incompatible... blocks hashed in one cannot be used in
the other.
>
> I think this would require a soft fork beforehand in order to implement
such a system.

I thought versionbits could handle this?   Can't they?  ALP pointed out
that it was important for a fork to be fully incompatible.

> It would be in the best interests of major exchanges and users would to
publicly announce their EB's.
>
> Why?

So miners can have a more reliable signal to go on.   No reasonable miner
would start mining signal for a fork unless they were confident that they
are doing so in-line with users and exchanges.

> "Scaling" includes a lot more than just the block size. There is much
more to scaling than just increasing the block size.

Yes, which is why I used air-quotes.   The primary idea is to remove a
political issue from affecting core developers.   There is a perception
among some people that "if only core would".   Plus, fees are
*inherently* political because it is a barrier for low-net-worth
individuals transacting using this technology.   Even if lightning worked
perfectly, how can a small business in Africa afford to set up a full node
and being to participate as a hub if fees are $50?   OMG blame core.

Miners and users should be free to wrangle each other over fees any time
they want without the involvement of developers.   I suspect the status quo
would be even *more* stable in that scenario... not less.

> What if the EB of a new node is set to be smaller than the current block
size?

Then it is only used for signal unless a fork occurs that results in a
reduction <= EB... in which case the EB becomes a hard upper bound, just
like any other.   When an EB is set by a user a block-height needs to be
recorded along with it, so it can be handled correctly.   EB set to <
active seems to me to be a special case.   Likewise the percentile shoudl
be the upper 5% in the case of EB < active.

This essentially partitions signalling into "< active" and "> active".
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Unique node identifiers

[Aymeric Vitte via bitcoin-dev]

As stated in this thread and as I see it the use of BIP150 is optional, 
so if some parties want to trust each others and use it, then they can, 
if they don't like it and don't want to use it, then they don't use it


Unless I misread, some statements in this thread involving the Tor 
network are wrong, the Tor network is a centralized network, each node 
(except the bridges) have a long term identity key and have to prove  
periodically to the authority servers that they are the owners of this 
key, if not the other nodes will never extend circuits to them, then 
they will be of course quite difficult to reach


Unfortunately the original proposal starting this thread seems to be 
reinventing this system that probably can only lead to something 
centralized which cannot apply for the bitcoin network (the Tor network 
is centralized because the team want to control what is happening: 
sybils, bugs, attacks, blacklist etc)


Unless some peers/nodes have decided to trust each others (BIP150) I 
don't think it's a good idea at all that bitcoin nodes have anything 
similar to long term nodeIDs (see 
https://gist.github.com/Ayms/aab6f8e08fef0792ab3448f542a826bf , already 
posted, not final, not finished, and the title does not really reflect 
what would be the proposal today, but it carefully avoids any 
possibility for a full node to have a long term ID)



Le 09/03/2017 à 02:55, Pieter Wuille via bitcoin-dev a écrit :

On Wed, Mar 8, 2017 at 5:16 PM, Eric Voskuil  wrote:

On 03/08/2017 03:12 PM, Pieter Wuille wrote:

In that way, I see BIP150 as an extension of IP addresses, except more
secure against network-level attackers. If you believe the concept of
people establishing links along existing trust lines is a problem, you
should be arguing against features in Bitcoin software that allows
configuring preferred IP addresses to connect to as well (-addnode and
-connect in Bitcoin Core, for example).

Weak identity is insufficient to produce the problem scenario that is at
the heart of my concern (excluding people). It is this "[same] except
more secure" distinction that is the problem. You brush past that as if
it did not exist.

So you're saying that a -onlyacceptconnectionsfrom=IP option wouldn't
be a concern to you because it can't exclude people? Of course it can
exclude people - just not your ISP or a state-level attacker.

Please, Eric. I think I understand your concern, but this argument
isn't constructive either.

The proposal here is to introduce visible node identities on the
network. I think that's misguided as node count is irrelevant and
trivial to fake anyway. But you bringing up BIP150 here isn't useful
either. I know that you equate the concept of having verifiable
identity keys in the P2P with a step towards making every node
identifiable, but they are not the same. It's just a cryptographic
tool to keep a certain class of attackers from bypassing restrictions
that people can already make.



--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

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