Topic: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) - page 5. (Read 14392 times)

No offense

But this thread may be 'redundant' in that as far as I can tell. Bitcoin Unlimited and Bitcoin Core are not in any negociations anymore.

Bitcoin Unlmited wants a hard blocksize increase,  first before seg witness (if at all) or other measures

Bitcoin Core wants NO hard blocksize increase under any circumstances...don't even mention it

Hard to get anywhere ..if no one will get out their chairs to come to the negociation table

So looking to me like if BU gets 51% they will simply FORK right away to solidify their postion on this as a lever

ie 400 usd btc at that point..imho..and likely some other alt (dash?) will fork over 300 bucks at that point in time

what a cluster


I like the ideas on this thread...but don't seem like it is gonna happen if no one is talking

You are clearly missing the point.  Miners don't need the other nodes to get their blocks and make their chain.  They only need to connect amongst themselves, and they have all reasons to do so for matters of speed.  If miners make one single chain, whether other nodes don't like that chain or not, doesn't matter.  There is only one chain out there.  Nobody's making another one.

If tomorrow, there is consensus between all miners and they ONLY make the segwit chain, then that's it, and whether users like it or not, they have no choice.   If tomorrow, there is consensus about BU between all miners, and they only make the BU chain, then that's it, and users have no choice.  And if tomorrow (like today) miners have consensus and only make the standard chain, that's it, users have no choice.

You are talking about the case when there is no consensus between pools, and when pools make different chains.  Then nodes can pick one of the two (or three or four) chains that are available.  

But non-mining nodes have nothing to say to the blocks that miners put on the chain they build.  They can simply download them, and accept them or not.  That's all non-mining nodes do: download blocks from miners.  They can't stop miners from building chains.

And now we come to users: if miners only make one chain, users have no choice: that's the chain they have to use, there isn't any other.  But of course, users can decide to sell their coins and leave the thing, which is bad for miners, who need users to buy their coins.  So with one chain, users HAVE TO use it, but they can set the absolute market cap.

If there are more chains, users can use the different chains to buy and sell, and DETERMINE THE RELATIVE MARKET CAPS.  But in order for users to be able to do so, miners have to make different chains in the first place (with hard forks).  When  users set different relative market caps, miners will follow these ratios.

So again: miners make block chains, which nodes can download if they like it.  Users can only use the chains that miners make.  But they set the market cap of these chains, which is the ultimate thing miners are after.  If miners are in disagreement, and make hard forks, they leave the choice to the user.  If miners are in consensus and make only one chain, the user has only the choice to stay or to leave.

But, apart from the case of a hard fork and setting the relative market caps, users have nothing to say about WHICH chain(s) miners can make.  And nodes in all this story don't matter AT ALL.

your still not understanding bitcoin.
your looking at things too two-dimensionally.

users are not slaves to pools. just taking what pools hand out. users want to have a say in what is created. and thus they become nodes.
they then via majority consensus and rejecting blocks they dont like, cause pools to form a single chain (stack of bank notes) that the majority accept and are happy to use as currency.

those that object to the majority. can either stay with the network. objecting (orphaning what they get) and being left unsynced because they choose not to keep any blocks.
or
give in to majority and decide to match the majority of nodes choice and use the currency.
or
ban all communications with the ugly nodes and pools to avoid the orphan drama. and find a pool that will make the blocks they prefer and start their own altcoin.

yea there are some users that set themselves up as wallet services for random users that dont care much about the big decisions, and those uncaring users can just use the popular currency via third parties because they trust the third party shares their same basic desire to not need to run a node themselves.
but others want a more active role so become nodes to be part of consensus. knowing the more people voting for a certain thing the less chance some strange lobbied group cant just come in and vote to create something different and force a change.

and thats where majority consensus comes in..
securing bitcoin from random changes and only changing if there is majority consent of the community.

Essentially, yes.
Well, they do need customers (people paying good money for the coins on their chain).  These customers need wallets.  So pools do need customers with wallets.  These wallets can connect directly to the pools' nodes ; or they can connect to those nodes that serve as proxy servers too.  Things like exchanges will probably run a full node, so pools would like these exchanges to take a copy of the block chain they make.


You're confusing users and nodes again.  Of course pools need users that pay good money for the coins the pools dump on the users.  But for that, the users need to have a choice.

With alt coins, that's not difficult.  There are other alt coins.  If the alt coin chain doesn't please alt coin users, they simply sell their coins, and buy others.

But with bitcoin it is different because the only thing bitcoin has going for it, is its brand name, its "first mover" image.  So if bitcoin miners only make one bitcoin chain, well, that is bitcoin.  And users have no choice, because there's no OTHER chain to prefer that has this brand image.

But in any case, it is a matter of miners and users, not of nodes. 

Your example of bank notes is also between those printing the notes, and those using it.  Whether the notes come by you through several different postal services (nodes) or they come to you as a user because you go and get them directly where they are printed, is the right analogy.  If the postal service refuses to carry the notes to your place, but you, as a user, want them, then you will go and get them directly where they are printed.

On the other hand, if the only notes that are printed, are green ones and nobody is making purple notes, well, you will still have to use the green ones if you want to use bank notes.   There aren't purple ones, EVEN if the postal service only wants to transport purple notes (that do not exist), and refuses to transport green ones.  You will have to go and get the green ones at the printer's site, if you want bank notes.  Even if you, and the postal service ,prefer purple ones.

your not seeing the bigger picture..

you think because pools can make their blocks that they dont need nodes.. well lets word it this way

you design a new bank note. you include all the security features.. but then you find that although you have a huge stack of bank notes.. no one likes them. they would prefer purple bank notes.. not green.

you could keep making green bank notes and thinking your making money..  but if no one is accepting them... your wasting your time. you cant spend them anywhere

now you start to realise about community consensus. if they dont like your blocks. your wasting your time making them.

I agree with that. I think the scaling should be flexible, adapt to the block size at the time. That is similar to the Monero.

Yes, but that is an "inter-pool" affair only.


Majority of proof of work.


But then you bloody don't need proof of work !  Why not simply have the nodes keep a big mempool and call that the block chain ??  And each time there's a difference, we let the nodes vote, and the majority is right ?

Why do you think Satoshi introduced proof of work do you think ?  To come to a consensus !  Because if you rely just on nodes, which you could, then this is not secure against a Sybil attack: everyone can fire up 100 000 nodes.  Now, if there is a mechanism to DETECT a Sybil attack and not take it into account, you've just found a new consensus mechanism.  But it is not bitcoins.  Bitcoins consensus mechanism is proof of work.  Not "number of nodes voting".

As usual, not capable of giving any reasoned argument against what I'm telling you.
Why would a POOL be "reliant" on nodes to get them their competitors' blocks on which they decide to build or not ?
What use does another node have for that pool ?  The pool can find out for itself whether that block satisfies its own criteria, doesn't need other blocks to verify that for him.  On the other hand, that pool wants to know that block as fast as it can, in order not to waste hash rate on an orphaned block.  So there is not one single reason why a pool would not connect DIRECTLY to its competitor's nodes.

What makes you think 'blocktracker' is Barry Silbert? That's a weird statement.

There's nothing to peer review yet. People are advocating for the idea.

https://bitcoinec.info/

i still think that non-pool nodes should really utilise policy.H more..

EG Consensus.h node hardwarelimit = something set by the nodes performing its own speed test of what it is physically capable of
for example 8mb
 then policy.h is the PREFERED size the network should work with.
EG 1mb today and maybe 2mb on activation day.

whereby pools see all the policy.h (prefered) in the node useragents.
and pools then
set their own policy.h just below what the majority of nodes prefer.
EG 0.999 today and 1.000250 day of activation. and pools then test the water of orphan risk and other unforseen bugs and increment up to 1.999 before the 'majority/minority' preferences kick in
thus a minority would accept the block but have their policy.h altered by warning system

While the code is not released yet, for those not following up to date news, it seems to be latest Core client patched with BU Emergent Consensus concept:

EB (Excessive Blocks): user is able to set easily how big blocks to accept maximally, default value 1 MB
AD (Acceptance Deepth): BitcoinEC set it always to infinite, so your node can not automatically fall back to bigger blocks than your EB setting. But the BitcoinEC going to monitor where the longest proof of work (PoW) chain is and providing a warning when your not following longest PoW chain anymore because of your low EB setting.

Personally I see it step in the right direction as well.

bitcoinEC.. lets just see

hmm
i wonder..
yep another DCG portfolio

oh look bitcoinec maintained by blocktracker.... https://keybase.io/blocktracker/ oh Barry silbert.. of DCG sems to be a follower (edit: now not)
let me guess lauda is ok with..
core (->blockstream ->DCG)
KNots? (luke JR->blockstream ->DCG)
bitcoinEC(silbert->DCG)

i find it funny how lauda shouts loudly in favour of all these DCG portfolio corporations/teams. yet hasnt read the lines of code yet of any implementation

though bitcoinEC is a 'in concept' a step in the right direction wise to move bitcoin forward. by having dynamics. im shocked at the ones jumping in advocating it without peer reviewing first

bitcoin needs to remain decentralised. multiple pools. and also the NODES killing off blocks it doesnt like. that way the pools are not just reliant on each other but the nodes too.

if we start going down the rabbit hole of one codebase of nodes
then
one pool

then we might aswell just be using fiat.

bitcoin is different and revolutionary due to diversity where there is not nor should not be any point of failure or control.
EG if one pool drops off the other pools continue.
if one codebase has a bug the others continue while the issues are being sorted by those affected.

consensus is the mechanism that self regulates the network by majority consent .
as long as the majority is not a sybil/shill corporate party, all running the exact same thing(making bitcoin weaker)..
but instead diverse independent consensus. then bitcoins revolution can continue. and bitcoin becomes stronger.

core wanting to split the network or baiting and switching to falsely state all non-core will do it. where by what core have left is their software and using BTCC & slush (their DCG partners) as pools. is centralisation..

it wont matter how good or bad the code is.. by being all part of the DCG portfolio. bitcoin loses its ethos of being revolutionary and will just turn into something like paypal/banking system.

bitcoin should rise above the greed of the banking sector corporate control and stick with consensus by independent diverse community.

I think only the following client implementations make sense for *compromise*, *consensus* or whatever:
Core: Segwit
Bitpay: SegWit + Adapative Block size - although I don't know how resistant it is to being gamed.
BitcoinEC: SegWit + Emergent Consensus - Already *praised* by ViaBTC (see here: https://twitter.com/ViaBTC/status/842748341767290880) [1].

---

[1] - Client not released yet.

This is why I propose to use BOTH SegWit and Adaptive Block Size (Bitcoin ABS? XD )

That is not Segwit, that is LN. You are confusing two completely different things.

That version didn't gather much support if any. Bitcoin scales very inefficiently on the first layer, that's why it requires a secondary layer.

I would like to see adaptive block size: make it once and for ever. Raise to 2MB now, and what, another HF in 2 years or less?
https://github.com/bitpay/bitcoin/issues/42

Cute Book. 


Segwit would open up many attacks on the Time Locking System , included in deadwit,
say a hacker finds a way to break the time lock early , they will be able to steal BTC like crazy and it could be months before anyone knows they were robbed. 
Hacking an LN hub, to steal BTC is a matter of time, nothing else.

 

My point was that the argument of "the more nodes, the more time it takes" is not correct.  There is no reason for nodes not to connect directly to one of the mining pool nodes (which can afford to have a datacenter-type node).  Then, all non-mining nodes are one single hop away from the pool-datacenter and are served directly.  No need for a P2P slow network.

This has nothing to do with decentralisation.  There is only one SOURCE of the block chain: the minerpool network.  If there is only one pool, well, this sole pool is the block chain source.  If there are 20 of them, they are well-connected between them, and all of them, most of them, or some of them will set up a data center to serve the non-mining nodes.  In any case, each of these miners is a good, primary source of the block chain, cannot cheat (if it withholds blocks, it will orphan its own blocks, it cannot make fake blocks - wasted hash rate - and they are eager to get the latest blocks from their co-miners), has no incentive to cheat and wants good connections to customer nodes to get to their transactions first, so that they can get hold of the most interesting fees first.

Whether you get the block chain directly from the source, or after several P2P hops, doesn't matter if you're not in a hurry, but if you are, then you better get it directly from a minerpool server.  And then, it doesn't really matter how many of the other nodes are also being served by that same data center.

Also, if the network interface on the network is well defined, whatever software you actually run on your client node, doesn't really matter.  If you are happy with it, that's fine.  People can use firefox or internet explorer or chrome or whatever as a browser ; so your node software, which is a "block chain downloader and browser/checker" can also be of various brands.  Doesn't matter, as long as it understands the (sole) block chain that is being served.

Where are your technical arguments?


If I'm so lacking in value as a source of truth, why do you need to attack nothing but my character? Why do you need to attack at all, surely I'm ssssssso transparent that anyone can see it without your "help"?


You can't make any actual arguments, or defend your own nonsense, and so you must attack nothing but me.

Let's see what people really think (and oh look, no-one's interested in reckless blocksize hard-forks, as usual)