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

[AngryDwarf]

Link to math please, how much data will take 10`000tps in Bitcoin blockchain using this stuff?
Or how much tps you want to scale to?

Transaction encoding improvements: http://people.xiph.org/~greg/compacted_txn.txt

Schnorr: https://bitcointalk.org/index.php?topic=1377298.msg14011669#msg14011669


On-chain scaling is possible. Blocksizes are not scalable.

Soft fork or hard fork required to efficiently implement these ideas?

[1714106205]

1714106205

[1714106205]

1714106205

[1714106205]

1714106205

[rav3n_pl]

Transaction encoding improvements: http://people.xiph.org/~greg/compacted_txn.txt

Schnorr: https://bitcointalk.org/index.php?topic=1377298.msg14011669#msg14011669


On-chain scaling is possible. Blocksizes are not scalable.

Transaction encoding can give 20-30% disk space and reduction of bandwidth. Good, but not good enough.

New signatures need SegWit anyway:

So the way we could use this to improve scalability in Bitcoin would be to add a OP_GROUPCHECKSIGVERIFY (and perhaps a multi-version of it) as part of a new segwit
script typecode that takes as input sighash flags and a pubkey.

It can give additional 40% capacity and can raise security. Good, but still not enough to scale.

So we can doube-triple current tps? We will need like 100x and more. This can help, but it is not a remedy on 10x or 50x more transactions we have now.

I`m not supporting scaling by raise block size to the moon, we just need more space now. Raising block size and adapting segwit in same time give us much more space and open new possibilities that segwit give us. But it all need TIME. And we run out of it, like 6 months ago.

So, raise block to 2MB is bare minimum we need. Segwit is must-have. We need both.

[hv_]

BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?

More like: http://luke.dashjr.org/programs/bitcoin/files/charts/software.html
90% Core
2.5% BU
7.5% others.

If 148 is USER activated soft fork, and majority of USERS want cheap and fast transactions ON CHAIN, is IS possible to make UAHF and raise block size.
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

You still don't get it, do you? There is no emergent need for a capacity increase HF. As soon as the spam stopped, the mempool is nearly empty. https://tradeblock.com/bitcoin

@Lauda, blocks are NOT verified as whole at one time. Maybe you forget, that every transaction that is received by node is verified on delivery. New block is announced as header (one hash to verify POW) and hashes of transactions included in it - node just need to verify gentx and pull/verify only MISSING transactions. In other words: if node is online and collecting transactions, even 15MB block can be verified in second, because node know and have verified transactions from block.

I am most certain that you don't know how Bitcoin works. You still verify the whole block, not just a partial part of it. You can effectively DoS the network with 2 MB blocks. 15 MB is absurdly large, unsafe,  unneeded and would take down a high percent of our node count.

And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?

How many % are running BTU/altcoin because Ver or his employees were spreading propaganda and/or were lobbying ViaBTC/TopBTC/Jihan?

We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality

It is 'user-activated', not 'miner-activated'. Nodes >0.13.1 already support BIP148.

Im sure you know that moving away from sth that worked for some years is a bigger hurdle than just keep things as usual and stay uninformed.

So you re again showing clearly that you compare apples and snakes by claiming BU boys just follow stupid propaganda and high invested miners do not look into risk calcs. Better check what really happens and judge again.

[Carlton Banks]

Good, but still not enough to scale.

That literally is scaling up. Scaling has nothing to do with the magnitude of improvements. You clearly don't know what "scaling" means

So we can doube-triple current tps? We will need like 100x and more. This can help, but it is not a remedy on 10x or 50x more transactions we have now.

I`m not supporting scaling by raise block size to the moon, we just need more space now. Raising block size and adapting segwit in same time give us much more space and open new possibilities that segwit give us. But it all need TIME. And we run out of it, like 6 months ago.

Nope.

That's all bunk, spam attacks have been driving the transactions fees, not real economic activity. We're running below the 3-7 tx/s capacity today, and have been since the BU coup started to unwind.

Maybe you could wave your hands faster?   That'll work

[David Rabahy]

Have we got your term yet for improving processing?

[Killerpotleaf]

https://www.reddit.com/r/Bitcoin/comments/5y18ub/compromise_lets_merge_bip_102_2mb_hf_and_bip_141

Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) into a single HF (with overwhelming majority consensus).

let's give this guy a medal for not being as retarded as the rest of us.

[David Rabahy]

Is this https://blockchain.info/blocks a good place to watch the block sizes?  If so then it appears to me that very few blocks are less than full.

[XbladeX]

Is this https://blockchain.info/blocks a good place to watch the block sizes?  If so then it appears to me that very few blocks are less than full.

458861 (Główny Łańcuch)    2017-03-25 10:07:46    AntPool    00000000000000000136372dca1af177e8f74cb708b254968b90d8513d923386    415.92KB

458857 (Główny Łańcuch)    2017-03-25 08:51:17    AntPool    000000000000000001cca23f26bb64ec76b8574e4db788c88678f54258d0b700    408.94KB

458854 (Główny Łańcuch)    2017-03-25 08:42:47    AntPool    0000000000000000012f2e70de74a048c9e25cf761e3189f02199b74c73c7576    0.26

458831 (Główny Łańcuch)    2017-03-25 04:36:52    F2Pool    0000000000000000012630565edd760acd7d41e92fd760b158438fcc54096072    0.27KB

458819 (Główny Łańcuch)    2017-03-25 01:11:29    AntPool    00000000000000000003a4389f5fe3ec7dd264d3ac1499f6fe5564688c4b80c5    130.14KB

458926 (Główny Łańcuch)    2017-03-25 20:40:18    AntPool    000000000000000001abc043a7267ef220d273c095dacc4eaa25d37bed1c4882    681.72KB

AntPool = BTC-U supporter of bigger blocks HAHAHAHAHA fuck them those china miners cartel
they need BIGGER BLOCKS ? Why ? They can't even mine constant 1MB....

[-ck]

AntPool = BTC-U supporter of bigger blocks HAHAHAHAHA fuck them those china miners cartel
they need BIGGER BLOCKS ? Why ? They can't even mine constant 1MB....

AntPool = BTC-U supporter of bigger blocks miner control of the network
There, fixed it for you

[franky1]

AntPool = BTC-U supporter of bigger blocks HAHAHAHAHA fuck them those china miners cartel
they need BIGGER BLOCKS ? Why ? They can't even mine constant 1MB....

AntPool = BTC-U supporter of bigger blocks miner control of the network
There, fixed it for you

CK... you should know better
shame on you trying to make scare stories fud and propaganda..

even you know if NODE consensus does not exist, then whatever gets made which does not follow node consensus gets rejected in 3 seconds.
need proof:

Code:

2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

try sticking with facts next time

[d5000]

Some of the people that discussed here will already know it, but the original proposal (2 MB + Segwit) has had support from a prominent Core developer (or better, "security auditor") - Sergio Demian Lerner, also one of the people behind RSK. The original discussion is here at the developer mailing list.

If a "conservative dynamic increase" like those proposed here and in other BIP-100/106-style solutions isn't possible because of lack of support, I would support a 2 MB hard fork with a reasonably large grace time after Segwit activation (~1 year). With a decentralized second layer solution like drivechains or extension blocks working (what we could achieve in 3 years, or not?) it may be even enough for all times.

[franky1]

Some of the people that discussed here will already know it, but the original proposal (2 MB + Segwit) has had support from a prominent Core developer - Sergio Demian Lerner, also one of the people behind RSK.

If a "conservative dynamic increase" like those proposed here and in other BIP-100/106-style solutions isn't possible because of lack of support, I would support a 2 MB hard fork with a reasonably large grace time after Segwit activation (~1 year).

kind of funny
segwit 2weeks grace.
yet anything not blockstream authorized 1year plus grace..

kind of stupid to keep making a bip, but then let blockstream determine to terms and conditions.

[andrew24p]

regular segwit is fine for me. People are blocking it not for technical reasons, but because they will lose the ability to ransom for a HF

[d5000]

kind of funny
segwit 2weeks grace.
yet anything not blockstream authorized 1year plus grace..

kind of stupid to keep making a bip, but then let blockstream determine to terms and conditions.

Why Blockstream? The terms and conditions are set by the node operators and miners. If they don't want a long grace period they can code in a shorter timeframe and use their own implementation. But they would have probably a hard time achieving a majority.

But I pretty agree to the position of some Core devs that a planned hard fork needs more preparation than a couple of months. 1 year from now, I don't see the ~2,1 MB Segwit blocks (as of recent calculations because of transaction patterns) becoming full, even in a speculation bubble. We have ~40% growth per year in transaction volume, so the 2 MB hardfork can wait. The goal is to get the miners that want bigger blocks and are not totally against Segwit on board of the "Segwit ship". Even an USAF in this scenario could be safer if we manage to achieve a strong majority (e.g. >85%).