Bitcoin Forum
December 01, 2021, 06:57:12 PM *
News: Latest Bitcoin Core release: 22.0 [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 14254 times)
Carlton Banks
Legendary
*
Offline Offline

Activity: 3220
Merit: 2599



View Profile
March 12, 2017, 05:34:58 PM
 #181

To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

1) Segwit as first measure;
2) adopt DooMAD/Garzik/Upal proposal (10%+ or 10%- voting when conditions are met), modified by adding a "upper limit"
3) for the first year, a 1,5 MB upper base limit (equivalent to ~3 MB maximal "block unit" size, for now)
4) for years 2-5, a 3 MB upper base limit (equivalent to 6-12 MB [worst case] maximal "block unit" size)

all that coded into a single BIP/pull request, to make it attractive for "big blocker" miners to accept it.

(I hope the terminology is OK)

Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday

Vires in numeris
1638385032
Hero Member
*
Offline Offline

Posts: 1638385032

View Profile Personal Message (Offline)

Ignore
1638385032
Reply with quote  #2

1638385032
Report to moderator
1638385032
Hero Member
*
Offline Offline

Posts: 1638385032

View Profile Personal Message (Offline)

Ignore
1638385032
Reply with quote  #2

1638385032
Report to moderator
1638385032
Hero Member
*
Offline Offline

Posts: 1638385032

View Profile Personal Message (Offline)

Ignore
1638385032
Reply with quote  #2

1638385032
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1638385032
Hero Member
*
Offline Offline

Posts: 1638385032

View Profile Personal Message (Offline)

Ignore
1638385032
Reply with quote  #2

1638385032
Report to moderator
1638385032
Hero Member
*
Offline Offline

Posts: 1638385032

View Profile Personal Message (Offline)

Ignore
1638385032
Reply with quote  #2

1638385032
Report to moderator
1638385032
Hero Member
*
Offline Offline

Posts: 1638385032

View Profile Personal Message (Offline)

Ignore
1638385032
Reply with quote  #2

1638385032
Report to moderator
franky1
Legendary
*
Offline Offline

Activity: 3318
Merit: 2207



View Profile
March 12, 2017, 05:40:48 PM
 #182

To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

1) Segwit as first measure;
2) adopt DooMAD/Garzik/Upal proposal (10%+ or 10%- voting when conditions are met), modified by adding a "upper limit"
3) for the first year, a 1,5 MB upper base limit (equivalent to ~3 MB maximal "block unit" size, for now)
4) for years 2-5, a 3 MB upper base limit (equivalent to 6-12 MB [worst case] maximal "block unit" size)

all that coded into a single BIP/pull request, to make it attractive for "big blocker" miners to accept it.

(I hope the terminology is OK)
3 and 4.. = spoon feeding numbers by devs hard writing the limits and needing users to download new versions (if a dev team even rlease the limit).
if the last 2 years are anything to go by.. forget it.. 2 years SO FAR to debate just getting a 2mb REAL limit even when all devs admit 4-8 is safe so the 2015 2mb compromise was actually ok all along....
we cant keep having these "please dev release a version that has X" debates
and we cant even have users set limit and release to public in their own repo due to "its just a clone of core but not peer reviewed REKT it"

instead
each node could have a speedtest mechanism. it start-point is when it sees a new height block. its end-point is after it has validated and relayed it out.
then over a scale of 2016 blocks it combines the times to get a total score.(recalculated every 2016 blocks) that way it can flag its capability.
thn we can see what is capable

that way the network can know safe capable growth amounts without spoon feeding and 2 year debates.

then below the network limit (capability) upper level:
preference lower level:
also at GUI (options tab) and rpc-console(debug) level.. or even a downloadable .ini file patch USERS can change the settings themselves without needing to recompile each time their independant client. or having to wait for devs to spoonfeed it.
which is adjustable by consensus.




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
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 12, 2017, 05:44:56 PM
 #183

In my opinion segwit should be a hard fork. It's not safe or desirable as a soft fork.
A dynamic base block solution is required that doesn't use arbitrary growth settings or further future block size hard fork debates.
Miners aren't going to create gigantic blocks by midnight, it would be orphaned by the speed of their competitors.
Technology limitations will ultimately decide blocksize growth. Miners are not going to spend 10mins creating a block.
Let a natural market fee market develop between on-chain transactions and off-chain service providers.
The two need implementing at the same time in the same hard fork, or conflict of interest issues could re-occur.

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.
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 05:47:16 PM
 #184

So what is the definition of weight, and how does this relate to data storage requirements?
You should research Segwit yourself. I don't plan on rewriting what is already written in a lot of articles. Use Google.

but are you thinking that a quadratic sigop attack is just about limiting sigops to not cause validation delays when a solved block is relayed.
No.

EG if a block in v.14 only allowed 80ksigops for the block and 16k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.
It is 80k sigops ONCE Segwit is activated. It is scaled with the 4 MB weight, so it comes down to the same thing as before Segwit.

thus a native key user can with just 5 tx stop other tx's getting in. and thus all segwit promises cant be met.
It is quite likely that transactions with such a high amount of sigops would be above 100kb; therefore, they'd not be relayed nor mined by any miner using Bitcoin Core (a non standard TX).

so effectively.. what does segwit actually offer that is a real feature that has real 100% guarantee promise
Miners can prioritize Segwit transactions (e.g. 20% vs. 80%). Simple solution.

That's not what I was looking for. I wanted to know how you managed to extrapolate the conclusion that "most Segwit supporters" don't dispute that.

This is inadequate data. I'd like to see worst case numbers for every block size (e.g. 1 MB, 2 MB, ... 8 MB). This could be nicely represented in a table.

2MB is an action that would "compromise" decentralization and therefore security. and it would be occurring as a result of political pressure rather than technical necessity.
Without adequate consensus (this being a economic super majority and 95% of the network), it does harm every part of the ecosystem.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
jbreher
Legendary
*
Offline Offline

Activity: 2912
Merit: 1515


lose: unfind ... loose: untight


View Profile
March 12, 2017, 05:47:30 PM
 #185

That isn't disputed by most SegWit supporters.
Source?

I think you are on the verge of understanding that issue.
I don't see why it is an issue. I see it as a non-issue, just as you see quadratic validation as a non issue.

I said The SegWit Omnibus Changeset destroys fungibility. I did not say it was an issue. You initially denied the fact that it does ... now you are backtracking to 'not an issue'. Perhaps you should actually think about your claims before you make them.

Quote
OK... sure. I'm quite certain you are unable to poke a hole in my scenario there. Why don't you try? Or even ... why don't you ping Harding with what I posted, and have him see if he can poke holes in it?
I just quickly went through it and saw your conclusion.

IOW, you are happy to wallow in your ignorance. ::sigh:: Oh well - it certainly would not be a first.

Quote
I'm not going to be a messenger between you and someone with clearly superior understanding. Find a way to contact him yourself.

I don't need to contact him. You are the one that appealed to his supposed authority. Which, if accurately relayed by you in both directions (which may or may not have been the case) displays an incomplete analysis if the scenario.

Anyone with a campaign ad in their signature -- for an organization with which they are not otherwise affiliated -- is automatically deducted credibility points.

I've been convicted of heresy. Convicted by a mere known extortionist. Read my Trust for details.
franky1
Legendary
*
Offline Offline

Activity: 3318
Merit: 2207



View Profile
March 12, 2017, 05:55:31 PM
 #186

knowing that ultimately (due to not preventing native key use) segwits only real promise is a fee discount(for the segwit key volunteers)
causes fungibility issues between which tx types cause preference or not(sigop,malle armed+ expensive or disarmed +cheap)

where people will have preference over which type of funds they receive/they prefer to deal with, based on which keys are used.
eg native(starting 1) becomes nasty and segwit(starting 3) becomes 'good money' people will not want to risk funds coming from a 1address

where not only uses start having thier preference but pools do too. where by if you know ur dealing with funds coming from native key may end up taking longer to confirm, or rejected to never confirm if pools start ignoring native keys. etc

aswell as the things jbreher  mentioned

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
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 05:55:50 PM
 #187

To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

1) Segwit as first measure;
2) adopt DooMAD/Garzik/Upal proposal (10%+ or 10%- voting when conditions are met), modified by adding a "upper limit"
3) for the first year, a 1,5 MB upper base limit (equivalent to ~3 MB maximal "block unit" size, for now)
4) for years 2-5, a 3 MB upper base limit (equivalent to 6-12 MB [worst case] maximal "block unit" size)
It doesn't look like you entirely understand how the block size works after Segwit. It changes the block size into two parameters, base size and weight (currently 1:4). If you use base size of 2 MB, you can get up to 4 MB worth of Segwit TXs or a maximum of 8 MB(!) in case of extreme multisignature usage. Your 'proposal' needs to be rewritten. A 'upper base limit of 1.5 MB' is actually equivalent to a maximum of 6 MB and not 3 MB.

Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday
I don't see how it could possibly be abused (size wise) if you add a maximum yearly growth. The consensus rules would dictate that it can't be increased more than that.

You initially denied the fact that it does ... now you are backtracking to 'not an issue'. Perhaps you should actually think about your claims before you make them.
I'm not backtracking on anything. This just shows open-mindedness, unlike what can be said for you and your kind. Money rules I guess.

IOW, you are happy to wallow in your ignorance. ::sigh:: Oh well - it certainly would not be a first.
Parallel validation is so useless that it isn't worth reading through its BIP. It's not about ignorance, it's about time efficiency.

I don't need to contact him. You are the one that appealed to his supposed authority.
I barely know who the person is. Stop using logical fallacies when you are clearly not adequately educated to properly do so.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
Carlton Banks
Legendary
*
Offline Offline

Activity: 3220
Merit: 2599



View Profile
March 12, 2017, 06:17:49 PM
 #188

Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday
I don't see how it could possibly be abused (size wise) if you add a maximum yearly growth. The consensus rules would dictate that it can't be increased more than that.

It can be seriously abused at Step 1 Lauda, the yearly maximums are a part of the steps subsequent to Step 1

Vires in numeris
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 06:20:05 PM
 #189

It can be seriously abused at Step 1 Lauda, the yearly maximums are a part of the steps subsequent to Step 1
Care to elaborate further on that with an example? I don't think we are on the same page.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
Carlton Banks
Legendary
*
Offline Offline

Activity: 3220
Merit: 2599



View Profile
March 12, 2017, 06:21:26 PM
 #190

https://bitcointalk.org/index.php?topic=1823233.0

Vires in numeris
AliceWonderMiscreations
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile WWW
March 12, 2017, 06:27:09 PM
 #191

2MB is an action that would "compromise" decentralization and therefore security. and it would be occurring as a result of political pressure rather than technical necessity.

that is not a compromise i am willing to make.

Do you have any scientific research to back this up?

Any centralization of mining is power cost, not block size.

I hereby reserve the right to sometimes be wrong
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 07:02:10 PM
 #192

It is well known that you could attempt to manipulate it in order to fit a lower amount of TXs. However, I was not talking about this part. I was talking about the other steps. The increase of the 'base size' helps in cases where users (or malicious actors) attempt to use a lot of "native keys". I will respond in that thread as well.

I think the system is very hard to game if you set:
1) A lower bound (size which is the absolute minimum when determining the maximum block size).
2) An upper bound (size which is the absolute maximum when determining the maximum block size).
3) Maximum movements per period (up and down).
4) Maximum total growth per year.

However, it may be very hard to gain consensus as this would have a lot of newly 'chosen' parameters.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
Carlton Banks
Legendary
*
Offline Offline

Activity: 3220
Merit: 2599



View Profile
March 12, 2017, 07:31:24 PM
 #193

The steps come in an order, Lauda. The 1st step, bizarrely, comes first.

There's little point in talking about the subsequent steps, if the 1st step is a significant problem in it's own right

Vires in numeris
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 07:38:40 PM
 #194

The steps come in an order, Lauda. The 1st step, bizarrely, comes first.

There's little point in talking about the subsequent steps, if the 1st step is a significant problem in it's own right
So what is your point.. do Segwit and then nothing? That makes nothing better; it makes things actually worse.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
Carlton Banks
Legendary
*
Offline Offline

Activity: 3220
Merit: 2599



View Profile
March 12, 2017, 07:42:36 PM
 #195

You've changed your tune

Explain how Segwit makes "everything" worse

Vires in numeris
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 07:43:48 PM
 #196

You've changed your tune

Explain how Segwit makes "everything" worse
Without the additional steps, it requires a lower number of TXs to cause the 'issue' that you've specified in your own thread.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
d5000
Legendary
*
Offline Offline

Activity: 3010
Merit: 2925


Decentralization Maximalist


View Profile
March 12, 2017, 07:44:40 PM
 #197

1) Segwit as first measure;
2) adopt DooMAD/Garzik/Upal proposal (10%+ or 10%- voting when conditions are met), modified by adding a "upper limit"
3) for the first year, a 1,5 MB upper base limit (equivalent to ~3 MB maximal "block unit" size, for now)
4) for years 2-5, a 3 MB upper base limit (equivalent to 6-12 MB [worst case] maximal "block unit" size)
It doesn't look like you entirely understand how the block size works after Segwit. It changes the block size into two parameters, base size and weight (currently 1:4).

Yes I took this into account, the ~3 MB estimation is based on estimations (like these from Core) that with the current transaction pattern the maximum block capacity is calculated to be 1,7-2,2 MB with Segwit. I first went for 2 MB, but as this already in extreme cases can mean 8 MB blocks (which aren't aceptable for many at this moment), I reduced it to 1,5 MB.

But for me, we can also modify the scale by:
1) first year, only Segwit + 1 MB max block size (no modifications)
2) years 2-3, Segwit + 2 MB upper bound (here the voting mechanism would start)
3) years 4-5, Segwit + 3 MB upper bound (absolute worst case with heavy multisig use would mean 12 MB blocks, but mostly about 6-10 MB)

Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 07:50:53 PM
 #198

Yes I took this into account, the ~3 MB estimation is based on estimations (like these from Core) that with the current transaction pattern the maximum block capacity is calculated to be 1,7-2,2 MB with Segwit. I first went for 2 MB, but as this already in extreme cases can mean 8 MB blocks (which aren't aceptable for many at this moment), I reduced it to 1,5 MB.
You're mistaken or aren't properly explaining yourself. Segwit as is, has 1 MB base, which can result with ~2.1 MB worth of transactions (with 100% Segwit TXs). However, this also has a potential maximum of creating 4 MB blocks (heavy multisignature usage). In your proposal, a 1.5 MB base has potential to fit ~3MB worth of transactions and a maximum of 6 MB blocks (heavy multisignature usage).

But for me, we can also modify the scale by:
1) first year, only Segwit + 1 MB upper bound (no modifications)
1 MB upper bound of what? The base size? It is best to elaborate as follows:
a) 1 MB base size variable.
b) 2 MB upper bound base size.
c) Weight variable from 4 MB to 8 MB depending on the above.

I think the base-to-weight ratio should possibly be reduced if the base were to grow. 8 MB potential would be too much.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
d5000
Legendary
*
Offline Offline

Activity: 3010
Merit: 2925


Decentralization Maximalist


View Profile
March 12, 2017, 08:03:16 PM
 #199

Oh, you were too fast to answer, I just had edited the post to clarify a bit Wink I meant that for the first year (or for the first 6 months, if miners insist on it) the proposed voting mechanism would be "on ice" to be able to react to attacks, only Segwit with no modifications of the "base" size. I think for one year these 2-4 MB should be enough.

So the last proposal with correct terminology (I hope so Wink ) should be:

1) first year: only Segwit with the 1 MB base variable and 4 MB weight.
2) years 2-3: Voting mechanism for miners (10%+ or - per difficulty period) is enabled; upper bound base size is 2 MB
3) years 4-5: upper bound base size changes to 3 MB; maybe reduction of base-to-weight ratio, like you proposed.

Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 12, 2017, 08:11:16 PM
 #200

Oh, you were too fast to answer, I just had edited the post to clarify a bit Wink
Yeah, sometimes I can be quite fast.

I meant that for the first year (or for the first 6 months, if miners insist on it) the proposed voting mechanism would be "on ice" to be able to react to attacks, only Segwit with no modifications of the "base" size.
Okay so for the first year we only use Segwit and the size it brings on its own.

So the last proposal with correct terminology (I hope so Wink ) should be:

1) first year: only Segwit with the 1 MB base variable and 4 MB weight.
2) years 2-3: Voting mechanism for miners (10%+ or - per difficulty period) is enabled; upper bound base size is 2 MB
3) years 4-5: upper bound base size changes to 3 MB; maybe reduction of base-to-weight ratio, like you proposed.
This looks much better now. The next questions are:
1) What exactly decides whether it goes up 10% or down?
2) Why that specific period? I think that once per retarget is too frequent; maybe once per month is better. Someone else may have more input on that.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!