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

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?

@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?

I don't think downloading 1 TB over 1 year is a problem. The upload side though would be.

No. It is research, and you can try to find the video yourself.

Oh yes, let's make nodes expensive to run. That is good for decentralization!

Nobody is talking about 20 MB blocks tonight; you have reading comprehension problems.

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

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

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'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 didn't say that; stop twisting my argument.

Irrelevant. You can spam whatever you want, miners can prioritize Segwit transactions and are incentivized to do so.

Nope. Read the above.

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 opposite

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



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

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

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

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.

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?

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

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?

you can fill blocks after activation with native transactions, otherwise the 16mill coins(46mill UTXO's) are locked and unspendable (because they are on native keys right now).

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)

---

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.
thus
reducing the room inside the 1mb baseblock to reduce how many other peoples tx's get in. and thus reduce the ratio of base:witness usage.. to then not attain the 2mb you harp on about.
EG
if only a couple segwit tx gets in.. it equates to something small like ~1.000450 total serialised blocksize, but where the 'block' is 100% full. meaning everyone elses tx is sat in mempool waiting.. and waiting

---

my point being is this
you said

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.
just like saying
bitcoin 2009-2016 will definetly deliver >7tx/s (actual math was something like 7.37tx/s)

which we all know we never got to 7tx/s... thus it was an empty promise

---

much like ISP's mis-selling internet speeds
sign with us and you will definitely get upto 100mb/s

users sign up.. no one gets 100mb/s and best some people get is 60mb/s and majority get under 40mb/s

and you can then come back with the stupid argument "i did say > (morethan (but logically you should have said upto) or be more honest abaout chances of getting it) i never promised actually get"

no one will compromise and something will break. either that's bitcoin itself or the will of one of the opposing sides. i kind of get the impression the unlimited fans would prefer to fatally mangle bitcoin and then blame core afterwards.

best case is that unlimited becomes the alt it always wanted to be and everyone else ignores it until it goes away.

I don't need to study anything. You have a fallacious way of arguing and reasoning. You completely changed my argument in order to refute it with your own. You created an argument that I did not make, also known as a strawman argument. You can't DOS the network with native keys with Segwit. Period. You should buy this with your employers money:

you need to really study more.
simply saying "cant b'coz cant" or "wrong because ad-hom"

is becoming very apparent as your rebuttal.

please study these things beyond the 2 paragraph sales pitches of empty promises.

In other words: You can't DOS the network at 1 MB using native keys post Segwit. Which is my whole point. Stop with these strawman arguments.