Bitcoin Forum
April 06, 2020, 03:29:45 AM *
News: Latest Bitcoin Core release: 0.19.1 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: Would you approve the compromise "Segwit + 2MB"?
Yes - 78 (62.4%)
No - 35 (28%)
Don't know - 12 (9.6%)
Total Voters: 125

Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 »  All
  Print  
Author Topic: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)  (Read 13989 times)
d5000
Legendary
*
Offline Offline

Activity: 2408
Merit: 1724


Decentralization Maximalist


View Profile
March 07, 2017, 08:07:34 PM
Last edit: April 06, 2017, 03:05:23 AM by d5000
 #1

Update: For those new to the topic: There is already a precise proposal with a patch ready to be tested that implements this compromise solution, called "Segwit2MB", by Core security auditor Sergio Demian Lerner.

I have read this compromise proposal from "ecafyelims" at Reddit and want to know if there is support for it here in this forum.

Compromise: Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF)

Quote from: Reddit user ecafyelims
Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) into a single HF (with overwhelming majority consensus).

Since Segwit changes how the blocksize is calculated to use weights, our goal with the merger would be 2MB of transactional data.

Segwit weighting system measures the transaction weight to be 3x(non-witness base data) + (base data with witness data). This weight is then limited to 4M, favoring witness data.

Transactions aren't all of base or witness. So, in practice, the blocksize limit is somewhere between 1MB (only base data) and 4MB (only witness data) with Segwit.

With this proposed merger, we will increase Segwit weight limit from 4M to 8M. This would allow 2MB of base data, which is the goal of the 2MB HF.

It's a win-win solution. We get 2MB increase and we get Segwit.

I know this compromise won't meet the ideals of everyone, but that's why it's a compromise. No one wins wholly, but we're better off than where we started.

It's very similar to what was already proposed last year at the Satoshi Roundtable. What is the opinion of the Bitcointalk community?

"There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1586143785
Hero Member
*
Offline Offline

Posts: 1586143785

View Profile Personal Message (Offline)

Ignore
1586143785
Reply with quote  #2

1586143785
Report to moderator
1586143785
Hero Member
*
Offline Offline

Posts: 1586143785

View Profile Personal Message (Offline)

Ignore
1586143785
Reply with quote  #2

1586143785
Report to moderator
1586143785
Hero Member
*
Offline Offline

Posts: 1586143785

View Profile Personal Message (Offline)

Ignore
1586143785
Reply with quote  #2

1586143785
Report to moderator
DooMAD
Legendary
*
Offline Offline

Activity: 2296
Merit: 1535


Leave no FUD unchallenged


View Profile WWW
March 07, 2017, 08:17:16 PM
 #2

I'm all for compromise, but still feel that any static, fixed size is a clumsy and crude solution.  As many have argued previously, it's merely kicking the can down the road.  SegWit plus a modified hybrid of BIP100 and BIP106 would be more flexible, adaptable and future-proof.  Not only that, but a sudden, arbitrary one-time surge in space leads to uncertainty and the possibility of abuse by spammers.  The change is healthier being gradual and predictable.

d5000
Legendary
*
Offline Offline

Activity: 2408
Merit: 1724


Decentralization Maximalist


View Profile
March 07, 2017, 08:22:56 PM
 #3

@DooMAD: What you say surely is valid - it's a short-term fix, but it would fix the current bottlenecks and already would enable Lightning and other offchain methods to be tested and in 2-3 years we can then switch to a more flexible variant.

And I think it would be very difficult in the actual situation to reach an agreement that includes some kind of "vote" by the miners for a certain block size, although your proposal seems to be much more moderate than BU (I have read it only superficially, though).


Gimpeline
Hero Member
*****
Offline Offline

Activity: 556
Merit: 507



View Profile
March 07, 2017, 08:28:58 PM
 #4

You have a good point, but I'm pretty sure that there will be no compromise.
The BU side thinks that the Segwit side are idiots, and the Segwit side knows that the BU side are idiots.
There is no compromise
Sundark
Hero Member
*****
Offline Offline

Activity: 560
Merit: 502


View Profile
March 07, 2017, 08:29:11 PM
 #5

We can say for sure that anything SegWit related is no longer gonna be accepted. Anti SegWit movement is too strong.
Naysayers will just conclude that this compromise is a simply backdoor for SegWit and 2MB blocks is just smoke and mirrors.
AgentofCoin
Legendary
*
Offline Offline

Activity: 1092
Merit: 1001



View Profile
March 07, 2017, 08:35:14 PM
 #6

Unfortunately, I think we are about to head into the next evolution of Bitcoin
blockchain theory, in which what will occur has not really happened before
and we will learn new lessons about how Bitcoin truly functions.

Some will lose greatly and others will win, but the current community and
economy will suffer as a whole. When certain actors are no longer properly
incentivized, they will split the single chain premise because you can. For
someone to take such a risk with confidence, it is either clairvoyance or
absolute madness.

This is mostly due to communication failures, misunderstandings, ideologies,
and egos. Compromises are likely over. Now is the quiet before the storm.

If something doesn't happen soon, all out war will begin.
But, maybe that is the only answer to this question, sadly.

Extremism is malicious, within a Consensus system.

I support a decentralized & unregulatable ledger first, with safe scaling over time.
Request a signed message if you are associating with anyone claiming to be me.
-ck
Legendary
*
Offline Offline

Activity: 3094
Merit: 1246


Ruu \o/


View Profile WWW
March 07, 2017, 08:44:34 PM
 #7

Code them up together, but allow each component to be activated *separately* thus allowing clients to choose which component they wish to support... I suspect support for BIP102 will be a lot higher now (yes I know about quadratic scaling issue.)

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 2% Fee Solo mining at solo.ckpool.org
-ck
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 07, 2017, 09:19:17 PM
 #8

Is it not the case that segwit coded as a hard fork would mean that all UTXO's can be spent with segwit? No stupid network topology introduced like with the soft fork mechanism? If so, then yes I think it would be accepted, unless someone things there are reasons why it would be a bad idea. Although my worry then would be that we would be fighting for the next capacity hard fork with no leverage.

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
hv_
Hero Member
*****
Offline Offline

Activity: 1512
Merit: 572

Clean Code and Scale


View Profile WWW
March 07, 2017, 09:50:54 PM
 #9

Given that dev fraction ( blockstream core) solution  SW looks rejected by miner fraction, compromise should be proposed from second fraction, not first one again.

And we might need a third, merchants?, to moderate in case.

Carpe diem  -  understand the White Paper and mine honest.
Memo: 1AHUYNJKPfY7PjVK1hNQFo5LrdGixuiybw  -  https://metanet.icu/
The simple way is the genius way - in Moore's Law and Satoshi's WP we trust.
AgentofCoin
Legendary
*
Offline Offline

Activity: 1092
Merit: 1001



View Profile
March 07, 2017, 10:15:44 PM
Last edit: March 07, 2017, 10:27:33 PM by AgentofCoin
 #10

Is it not the case that segwit coded as a hard fork would mean that all UTXO's can be spent with segwit? No stupid network topology introduced like with the soft fork mechanism? If so, then yes I think it would be accepted, unless ...

Given that dev fraction ( blockstream core) solution  SW looks rejected by miner fraction, compromise should be proposed from second fraction, not first one again.
And we might need a third, merchants?, to moderate in case.


The issue here is that if BU community and BU devs are not willing to cap the blocksize
or cap the blockweight, then there can never be compromise. They will fork eventually
since they are extremists. They are not looking out for the future, only themselves now,
in the most perfect form of greed. The greed that kills the golden goose, which is the most
stupid of all greeds.

 - BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
This is to bring about a more currency like device now, instead of later.
They do not mind network centralization or do deny/ignore its possibility of occurrence.

 - CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).
This is to maintain the unregulatibility and other like aspects now and later.
They do not mind slowed user growth or high fees or do deny/ignore their possible impacts.

They are fundamentally opposed. Like a couple that has different interests now and changed over time.
The normal situation would be that the couple would break up and each do their own thing.

If a compromise can be reached, it will be either full capitulation or a masterful answer still unknown.

I support a decentralized & unregulatable ledger first, with safe scaling over time.
Request a signed message if you are associating with anyone claiming to be me.
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 07, 2017, 10:29:13 PM
 #11

BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).

Bigger blocks tend toward network centralisation, but decentralises the user base (more people can afford to send bitcoin).
Small blocks allow greater network decentralisation, but centralises the user base (only a few big actors can afford to send bitcoin).

How decentralised is LN?

It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
AgentofCoin
Legendary
*
Offline Offline

Activity: 1092
Merit: 1001



View Profile
March 07, 2017, 10:44:25 PM
 #12

BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).
...
How decentralised is LN?

I am not qualified to answer.
In theory, if designed and implemented appropriately, equal to Bitcoin's.


It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

Yes, but there is one problem that is a constant misunderstanding in the
whole Bitcoin community.

When this belief was stated by Satoshi, Nodes were a single entity.
The miners were validators and the validators were miners.
There was only one. Now, there are two separate systems.

Due to these two separate systems, there are two possible choices now.
Satoshi's original comments (as to Nodes) no longer apply to today's reality.

I support a decentralized & unregulatable ledger first, with safe scaling over time.
Request a signed message if you are associating with anyone claiming to be me.
tbonetony
Sr. Member
****
Offline Offline

Activity: 446
Merit: 250


No zuo no die why you try, u zuo u die dont be shy


View Profile
March 07, 2017, 10:51:51 PM
 #13

yes I like this idea. If this can be a configuration choice for node operator to vote, that would be even better.

Forget about BU and BC, we need Bitcoin United Grin

Customizable full-featured crypto trading platform in development. Asking for demo if interested.







I offer private S9 rental for various length: https://bitcointalk.org/index.php?topic=1708351.0
Swimmer63
Legendary
*
Offline Offline

Activity: 1594
Merit: 1000



View Profile
March 07, 2017, 11:08:22 PM
 #14

I am not technically qualified to comment in detail.  But I am very much for compromise and 2MB with Segwit is an excellent place to start.  Let's see who is serious about moving btc ahead. 
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 07, 2017, 11:21:52 PM
 #15

It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

Yes, but there is one problem that is a constant misunderstanding in the
whole Bitcoin community.

When this belief was stated by Satoshi, Nodes were a single entity.
The miners were validators and the validators were miners.
There was only one. Now, there are two separate systems.

Due to these two separate systems, there are two possible choices now.
Satoshi's original comments (as to Nodes) no longer apply to today's reality.

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
franky1
Legendary
*
Online Online

Activity: 2716
Merit: 1656



View Profile
March 07, 2017, 11:32:22 PM
 #16

BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization 1).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization 2).

1 Bigger blocks tend toward network centralisation,
3 but decentralises the user base (more people can afford to send bitcoin).

2 Small blocks allow greater network decentralisation,
4 but centralises the user base (only a few big actors can afford to send bitcoin).

your putting words into people mouths.

1. Bu/bigblockers dont want one brand running anything... most bu/bigblockers are happy with bitcoinj, xt, classic, btcd, etc all running on the same level playing field all using real consensus to come to agreement.. and if core got rid of blockstream corporation. would be happy with core too.(main gripe is blockstreams centralist control)

2. small blockers have shown distaste for anything not blockstream inspired/funded..  (rekt campains agains bitcoinj, xt, classic and bu)

3. correct(people keep funds on thier personal privkeys and use future LN services voluntarily)

4. correct(people move funds to new keys and multisigs where payments need an LN counter party signing. but done forcefully due to politics/fee war games)

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
BitUsher
Legendary
*
Offline Offline

Activity: 994
Merit: 1027


View Profile
March 07, 2017, 11:41:27 PM
 #17

Changing MAX_BLOCK_SIZE to 2MB + segwit literally means we will see 4-8MB blocks.

No thanks ,

I don't care is this HF proposal comes from core or another repo , I will reject it and stay on the original chain. Developers have no power over what software I choose to run .

4-8MB blocks is too big and I am only interested in HF that include many HF wishlist items and permanently solve the scaling problem instead of kicking the can down the road a few months.


Here are some academic papers that reflect how dangerous blocks over 4MB currently are and one reason why segwit limits blocksizes to 4MB max.

http://bitfury.com/content/5-white-papers-research/block-size-1.1.1.pdf

http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf

This is a dangerous precedent giving control to miners or developers without community consensus. Hard forks should be a matter of last resort and when a SF is on the table that offers the same essential blocksize increase as classic we should be greatful and take it instead.

There is significant moral hazard and social hazard in forcing a HF on the community and how that will make us all insecure in the future. If the Developers or miners are viewed as a group that is perceived they can change the protocol without overwhelming consensus of the bitcoin users than they can easily be manipulated and attacked by bad actors like states and others.

There will guarantee be a split where 2-3 coins exist for one thing which will cause short term havoc due to uncertainty, loss of immutability , breaking the 21 million limit promise, moral hazard , social hazard, ect...(Remember Bitcoin is actually used for things unlike Ethereum which is 100% speculation, thus a split is far more damaging to bitcoin)

The ETF follows the most worked chain only, thus if the miners are swayed back to the originally chain after many of us dump our split coins all those ETF investors lose their investment value.

4-8MB blocks will lead to centralization, increase miner and node centralization and force me to shutdown my personal node.
AgentofCoin
Legendary
*
Offline Offline

Activity: 1092
Merit: 1001



View Profile
March 08, 2017, 12:01:35 AM
 #18

It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

Yes, but there is one problem that is a constant misunderstanding in the
whole Bitcoin community.

When this belief was stated by Satoshi, Nodes were a single entity.
The miners were validators and the validators were miners.
There was only one. Now, there are two separate systems.

Due to these two separate systems, there are two possible choices now.
Satoshi's original comments (as to Nodes) no longer apply to today's reality.
I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.

No, you missed my point. I thought it was more evident.
Non-mining nodes are not incentivized the way Miners Nodes are.

The point being:
both can have opposite votes now (two sides), instead of the vote
always tending toward the same incentivized choice by Hardfork.
Now there are more possibilities such as Softforks. (User activated
fork is now another one, but is a new theory which is riskier than
either soft or hard.)

All I'm saying is when you cite Satoshi about Nodes, it was before
the Node split and is entirely in a different context that no longer
exists.

I support a decentralized & unregulatable ledger first, with safe scaling over time.
Request a signed message if you are associating with anyone claiming to be me.
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 08, 2017, 12:14:55 AM
 #19

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.
No, you missed my point. I thought it was more evident.
Non-mining nodes are not incentivized the way Miners Nodes are.

The point being:
both can have opposite votes now (two sides), instead of the vote
always tending toward the same incentivized choice by Hardfork.
Now there are more possibilities such as Softforks. (User activated
fork is now another one, but is a new theory which is riskier than
either soft or hard.)

All I'm saying is when you cite Satoshi about Nodes, it was before
the Node split and is entirely in a different context that no longer
exists.

But non mining nodes are the majority of the network. Miners have to produce blocks that follow the network consensus or they get orphaned. Hard fork consensus means nodes update first, miners follow.

Scaling and transaction rate: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
Do not allow demand to exceed capacity. Do not allow mempools to forget transactions. Relay all transactions. Eventually confirm all transactions.
AgentofCoin
Legendary
*
Offline Offline

Activity: 1092
Merit: 1001



View Profile
March 08, 2017, 12:19:03 AM
 #20

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.
No, you missed my point. I thought it was more evident.
Non-mining nodes are not incentivized the way Miners Nodes are.

The point being:
both can have opposite votes now (two sides), instead of the vote
always tending toward the same incentivized choice by Hardfork.
Now there are more possibilities such as Softforks. (User activated
fork is now another one, but is a new theory which is riskier than
either soft or hard.)

All I'm saying is when you cite Satoshi about Nodes, it was before
the Node split and is entirely in a different context that no longer
exists.
But non mining nodes are the majority of the network. Miners have to produce blocks that follow the network consensus or they get orphaned. Hard fork consensus means nodes update first, miners follow.

That doesn't matter. Miners can fork away without node validators
and the minority hash chain's difficultly will be too high (and may not
adjust in time to prevent possible failure). Meanwhile the Miner nodes
are on a new chain, mining & semi validating away. The minority hash
chain, could in short time, have no hash at all, in theory.

Your statement only applies if there is no malicious forking.
When the two node systems split, this possibility came into existence.
Prior to this, they always moved as one, since there was only one.

I support a decentralized & unregulatable ledger first, with safe scaling over time.
Request a signed message if you are associating with anyone claiming to be me.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!