[POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)

[AngryDwarf]

Which is bigger, 2 MB blocks or 4 MB blocks  

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?

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

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

[1714171599]

1714171599

[1714171599]

1714171599

[1714171599]

1714171599

[1714171599]

1714171599

[Carlton Banks]

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?

[AngryDwarf]

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.

[franky1]

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

[d5000]

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]

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

[Lauda]

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).

[AngryDwarf]

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

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.

[AliceWonderMiscreations]

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.

[franky1]

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

[Carlton Banks]

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

[Lauda]

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.

[d5000]

@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 ).

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]

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?

[Carlton Banks]

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

[AngryDwarf]

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.

[Carlton Banks]

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

[AngryDwarf]

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.

[Lauda]

@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 ).

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?

[franky1]

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.