Bitcoin Forum
December 01, 2021, 07:52:06 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)
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 06:14:15 PM
 #101

Which is bigger, 2 MB blocks or 4 MB blocks   Roll Eyes

And that 4MB is 1MB of transactional data space, and 3MB of segwit data space, the latter of which is mostly reserved for future use.

So don't mislead others into thinking that all of a sudden we will get a 4 fold increase in transactional capacity. We won't.

When you say "Segwit data", you're talking about the data that signs transactions, to prove that the real user actually sent the money.


Are you sure it's not you misleading everyone dwarf? By pretending that signing the transactions is somehow something new, or unneeded? Smiley

Don't worry, franky1 gave a bit more detail in case my wording could be considered as misleading.

Quote from: franky1
for clarity

Quote from: AngryDwarf on Today at 02:14:22 PM
Quote from: Carlton Banks on Today at 02:07:12 PM
Which is bigger, 2 MB blocks or 4 MB blocks   Roll Eyes

And that 4MB is
1MB of transactional data space, and 3MB buffer space, that only partially fills dependant on the % of segwit users in the base block
(0% segwit in 1mb base=0of the 3mb extra used(1mb total))
(10% segwit in 1mb base=0.1mb of the 3mb used(1.1mb total))
(100% segwit in 1mb base=1.1mb of the 3mb used(2.1mb total))

 the latter of which(atleast 1.9mb) is mostly reserved for future use.

So don't mislead others into thinking that all of a sudden we will get a 4 fold increase in transactional capacity. We won't.

FTFY

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.
1638388326
Hero Member
*
Offline Offline

Posts: 1638388326

View Profile Personal Message (Offline)

Ignore
1638388326
Reply with quote  #2

1638388326
Report to moderator
1638388326
Hero Member
*
Offline Offline

Posts: 1638388326

View Profile Personal Message (Offline)

Ignore
1638388326
Reply with quote  #2

1638388326
Report to moderator
1638388326
Hero Member
*
Offline Offline

Posts: 1638388326

View Profile Personal Message (Offline)

Ignore
1638388326
Reply with quote  #2

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

Posts: 1638388326

View Profile Personal Message (Offline)

Ignore
1638388326
Reply with quote  #2

1638388326
Report to moderator
1638388326
Hero Member
*
Offline Offline

Posts: 1638388326

View Profile Personal Message (Offline)

Ignore
1638388326
Reply with quote  #2

1638388326
Report to moderator
Carlton Banks
Legendary
*
Offline Offline

Activity: 3220
Merit: 2599



View Profile
March 11, 2017, 06:19:41 PM
 #102

Don't worry, franky1 gave a bit more detail in case my wording could be considered as misleading.

There is no "reserved for future use". Franky is a misleading statement incarnate.


The Segwit testnet mined a 4MB block, just by including alot of multi-signature transactions (which obviously have a much heavier transaction:signature ratio than regular transactions)



Do you have any arguments that don't involve subverting plainly observable facts?

Vires in numeris
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 06:30:46 PM
 #103

There is no "reserved for future use". Franky is a misleading statement incarnate.

The Segwit testnet mined a 4MB block, just by including alot of multi-signature transactions (which obviously have a much heavier transaction:signature ratio than regular transactions)

So is this the extreme case where a large number of inputs is used in a transaction to fill up the segwit space?

Perhaps you should share with the class what this test case is. Please expand my knowledge and dispell my misconceptions by providing a bit more information.

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

Activity: 3318
Merit: 2207



View Profile
March 11, 2017, 06:32:40 PM
Last edit: March 11, 2017, 07:03:07 PM by franky1
 #104

Don't worry, franky1 gave a bit more detail in case my wording could be considered as misleading.

There is no "reserved for future use". Franky is a misleading statement incarnate.

The Segwit testnet mined a 4MB block, just by including alot of multi-signature transactions (which obviously have a much heavier transaction:signature ratio than regular transactions)

Do you have any arguments that don't involve subverting plainly observable facts?

much like bitcoin testnet got its 7tx/s.. but never happened in reality on bitcoin main net after 8 years of trying

which is why devs are thinking about other novel things to append to transactions such as confidential commitments to fill up atleast 1.9mb gap. because the 2.1mb fill isnt even going to get reached

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

Activity: 3010
Merit: 2925


Decentralization Maximalist


View Profile
March 11, 2017, 06:38:08 PM
 #105

The challenge is now to find a number for this cap. [...]
1) 20 MB is too big right now.
2) 1 TB is definitely too big. Just imagine the IBD after 2 years.
3) You're thinking too big. Think smaller. We need some room to handle the current congestion, we do not need room for 160 million users yet.

160 million users and 20 MB maximum block size (1 TB/year) as a mid-term goal is based on the present consumer HD market storage prices, but also on the idea to capture a significant (at least 10%) part of the market of Western Union and similar services (WU claims to have 1 billion clients). The remittance market is, for the time being, the most interesting one for BTC if it manages to continue to offer fees of less than ~1 USD per (simple) transaction.

The "upper cap" of 20 MB could be the mid-term cap, to be reached ~ 10 years from now. We could set a lower cap for the first 2-3 years (5 MB should be enough, or 2 MB + Segwit) because of current bandwith limitations. Or a moving cap based on speed tests like the one Franky proposes (good idea, I think).


Carlton Banks
Legendary
*
Offline Offline

Activity: 3220
Merit: 2599



View Profile
March 11, 2017, 06:41:42 PM
 #106

There is no "reserved for future use". Franky is a misleading statement incarnate.

The Segwit testnet mined a 4MB block, just by including alot of multi-signature transactions (which obviously have a much heavier transaction:signature ratio than regular transactions)

So is this the extreme case where a large number of inputs is used in a transaction to fill up the segwit space?

The opposite

Multi signature means a single input signed by more than one key.



How can you pretend not to understnad something so simple.....

Vires in numeris
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 06:45:51 PM
 #107

if you are saying native keys cant be spent on activation day.. then your funds cannot be added to a block (because your own funds are on native keys right now)
I didn't say that; stop twisting my argument.

if you can admit native transactions can be added to blocks. you start to see that people with native keys will just spam the 1mb base block.
Irrelevant. You can spam whatever you want, miners can prioritize Segwit transactions and are incentivized to do so.

you have mis-sold a "definitely deliver' by then saying > (im thinking you should have used < but even that is still mis-selling)

meaning its an EMPTY promise.
Nope. Read the above.

160 million users and 20 MB maximum block size (1 TB/year) as a mid-term goal is based on the present consumer HD market storage prices, but also on the idea to capture a significant (at least 10%) part of the market of Western Union and similar services (WU claims to have 1 billion clients). The remittance market is, for the time being, the most interesting one for BTC if it manages to continue to offer fees of less than ~1 USD per (simple) transaction.

The "upper cap" of 20 MB could be the mid-term cap, to be reached ~ 10 years from now. We could set a lower cap for the first 2-3 years (5 MB should be enough, or 2 MB + Segwit) because of current bandwith limitations. Or a moving cap based on speed tests like the one Franky proposes (good idea, I think).
You are not thinking about this straight. Let's say there is no risk for 20 MB blocks, DoS nor orphan wise. Storing 1 TB per year maybe won't be *that big of a problem* for existing nodes. You are forgeting about:
1) IBD.
2) Reindexing in case something goes wrong.

Imagine syncing and validating a 3 TB blockchain from scratch. Do I need to run my nodes only on top end Xeon machines? There was some discussions about a 'drastic' future in which new nodes would never be able to catch up (I think this was scaling workshop 2015).

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 06:47:34 PM
 #108

There is no "reserved for future use". Franky is a misleading statement incarnate.

The Segwit testnet mined a 4MB block, just by including alot of multi-signature transactions (which obviously have a much heavier transaction:signature ratio than regular transactions)

So is this the extreme case where a large number of inputs is used in a transaction to fill up the segwit space?

The opposite

Multi signature means a single input signed by more than one key.



How can you pretend not to understnad something so simple.....

Quote
Perhaps you should share with the class what this test case is. Please expand my knowledge and dispell my misconceptions by providing a bit more information.

I've never used multi-sig, so it is a gap in my knowledge. Perhaps if pro-segwit people would stop hurling insults around and explain things better I might change my mind on what I think the best way forward is. So please explain this test case, and how it would work without segwit.

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.
AliceWonderMiscreations
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile WWW
March 11, 2017, 06:50:49 PM
 #109

Imagine syncing and validating a 3 TB blockchain from scratch. Do I need to run my nodes only on top end Xeon machines? There was some discussions about a 'drastic' future in which new nodes would never be able to catch up (I think this was scaling workshop 2015).

No, bandwidth matters more than threads.

The "drastic" future of which you speak sounds like FUD to me.

However I would highly recommend using a Xeon anyway simply to get ECC - it's worth it. As transistors continue to get smaller, the bits flipped by cosmic rays increase.

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

Activity: 3318
Merit: 2207



View Profile
March 11, 2017, 06:59:33 PM
 #110

The "drastic" future of which you speak sounds like FUD to me.

much like in 1996(in the days of 56k and 4gb hard drive) shouting
dont make Call of Duty:MW in the future an online multiplayer download 'coz 60gb download and 1mb/s bandwidth'..

in short w wont have 20mb blocks tonight. so lets NOT stop dynamic blocks starting at 2mb this year. purely with the '20mb blocks by midnight' doomsday rhetoric..
...when the reality is years away

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
Carlton Banks
Legendary
*
Offline Offline

Activity: 3220
Merit: 2599



View Profile
March 11, 2017, 07:00:06 PM
 #111

I've never used multi-sig, so it is a gap in my knowledge. Perhaps if pro-segwit people would stop hurling insults around and explain things better I might change my mind on what I think the best way forward is. So please explain this test case, and how it would work without segwit.

I'd do it were it not for your false accusation that I hurled insults at you

The evidence that this didn't even happen is in plain black and white on this page

Vires in numeris
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2903


Terminated.


View Profile WWW
March 11, 2017, 07:03:32 PM
 #112

No, bandwidth matters more than threads.
I don't think downloading 1 TB over 1 year is a problem. The upload side though would be.

The "drastic" future of which you speak sounds like FUD to me.
No. It is research, and you can try to find the video yourself.

However I would highly recommend using a Xeon anyway simply to get ECC - it's worth it. As transistors continue to get smaller, the bits flipped by cosmic rays increase.
Oh yes, let's make nodes expensive to run. That is good for decentralization!

in short w wont have 20mb blocks tonight. so lets NOT stop dynamic blocks starting at 2mb this year. purely with the '20mb blocks by midnight' doomsday rhetoric..
...when the reality is years away
Nobody is talking about 20 MB blocks tonight; you have reading comprehension problems.

"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 11, 2017, 07:10:41 PM
Last edit: March 11, 2017, 07:21:28 PM by d5000
 #113

@Lauda: Maybe I'm overly optimistic about technology development in the coming 10 years. (A less than 160 million possible user base for 2027 would mean a pretty low "cap" for Bitcoin's price imho, as I don't believe in the "digital gold" thing and even using LN you need some on-chain transactions. A not small part of the population of this forum thinks that Bitcoin will replace the whole fiat money next year or so Wink ).

In the case of IBD I think that in that in that "drastic future" most users will end downloading blockchain snapshots. That has some centralization risks but I think they are manageable. Also reindexing maybe won't be a thing low-end-equipment users would do regularly - they would simply redownload a snapshot.

We're obviously talking about end users with consumer-level equipment. Professional users that use servers in well-connected datacenters should have no problems with 20 MB blocks, I think.

Edit: What upper limit would you consider realistic?

AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 07:11:27 PM
 #114

The Segwit testnet mined a 4MB block, just by including alot of multi-signature transactions (which obviously have a much heavier transaction:signature ratio than regular transactions)

So how many multiple signatures was associated with the address of this transaction, and many signatures did it require?

Would the seperation of witness data to transaction data make the space used any less?

How important is this to the implementation of lightning networks?

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

Activity: 3220
Merit: 2599



View Profile
March 11, 2017, 07:17:18 PM
 #115

You can't expect good will from those to whom you demonstrate bad will, Dwarf

Vires in numeris
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 07:24:58 PM
 #116

You can't expect good will from those to whom you demonstrate bad will, Dwarf

Calling me Dwarf instead of AngryDwarf might be perceived as insult if it was to come from an Elf. Maybe its perception of tone. Neither did I directly say you was throwing insults, you implied it from me stating it came from pro-segwit people.

Internet forums are not for the thin skinned.

If you don't want to answer the question for me, you could answer it for the benefit of other people.

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

Activity: 3220
Merit: 2599



View Profile
March 11, 2017, 07:32:53 PM
 #117

If you name is inherently insulting to you, you should take responsibility for choosing it

Vires in numeris
AngryDwarf
Sr. Member
****
Offline Offline

Activity: 476
Merit: 500


View Profile
March 11, 2017, 07:43:21 PM
 #118

If you name is inherently insulting to you, you should take responsibility for choosing it

I could make a word play on your username, but I assume you would rather divert this into a slanging match, rather than add to the technical discussion.

So like I say, you can choose to explain it for the benefit of other people, or you can choose not to.

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 11, 2017, 07:50:12 PM
 #119

@Lauda: Maybe I'm overly optimistic about technology development in the coming 10 years. (A less than 160 million possible user base for 2027 would mean a pretty low "cap" for Bitcoin's price imho, as I don't believe in the "digital gold" thing and even using LN you need some on-chain transactions. A not small part of the population of this forum thinks that Bitcoin will replace the whole fiat money next year or so Wink ).
You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security. You need to be conservative to say the least. If you don't believe that Bitcoin is digital gold, or you don't understand where the current value stems from, then you have to re-examine everything.

In the case of IBD I think that in that in that "drastic future" most users will end downloading blockchain snapshots. That has some centralization risks but I think they are manageable. Also reindexing maybe won't be a thing low-end-equipment users would do regularly - they would simply redownload a snapshot.
You shouldn't throw in centralizing aspects like they are trivial changes. The impact of something like that, and potential security concerns are probably not properly researched.

We're obviously talking about end users with consumer-level equipment. Professional users that use servers in well-connected datacenters should have no problems with 20 MB blocks, I think.
I don't understand why you want me, as a user, to spend a lot of money to run my node in datacenters? I use Bitcoin Core for everything, node, wallet, cold storage.

Edit: What upper limit would you consider realistic?
In what time frame? Next 5, 10 years?

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

Activity: 3318
Merit: 2207



View Profile
March 11, 2017, 08:02:17 PM
 #120

You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security.

then stop throwing speculations of things like 20mb blocks... or ur gangs other fake doomsdays of "gigabytes by midnight" "visa by tomorrow"

as thats speculative predictions of the future.

stick to rational REAL abilities now

8mb upper limit and 2mb lower (dynamic) limit.

that gives a while to reassess the 8mb over time.
rather that waiting and halting growth for years due to fears of 20mb blocks.


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
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!