Pages:
Author

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

legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
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%).
sr. member
Activity: 378
Merit: 250
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
legendary
Activity: 4214
Merit: 4458
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.
legendary
Activity: 3906
Merit: 6249
Decentralization Maximalist
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.
legendary
Activity: 4214
Merit: 4458
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
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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
legendary
Activity: 1302
Merit: 1002
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.

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

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

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

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

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

Quote
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....
hero member
Activity: 709
Merit: 503
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.
sr. member
Activity: 812
Merit: 250
A Blockchain Mobile Operator With Token Rewards
https://www.reddit.com/r/Bitcoin/comments/5y18ub/compromise_lets_merge_bip_102_2mb_hf_and_bip_141
Quote from: Reddit user ecafyelims
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.
hero member
Activity: 709
Merit: 503
Have we got your term yet for improving processing?
legendary
Activity: 3430
Merit: 3074
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?  Cheesy That'll work
hv_
legendary
Activity: 2520
Merit: 1055
Clean Code and Scale
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. Roll Eyes 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? Roll Eyes

We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality Smiley
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.
legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
Transaction encoding improvements: http://people.xiph.org/~greg/compacted_txn.txt

Schnorr: https://bitcointalksearch.org/topic/m.14011669


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:
Quote
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.
sr. member
Activity: 476
Merit: 501
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://bitcointalksearch.org/topic/m.14011669


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

Soft fork or hard fork required to efficiently implement these ideas?
newbie
Activity: 26
Merit: 0
I am not technically qualified to comment in detail.  But I am very much for compromise and 2MB with Segwit is an excellent place to start.  Let's see who is serious about moving btc ahead.
legendary
Activity: 3430
Merit: 3074
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://bitcointalksearch.org/topic/m.14011669


On-chain scaling is possible. Blocksizes are not scalable.
legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
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.

No it isn't

Schnorr signatures confer scaling on-chain

Transaction encoding improvements confer scaling on-chain



Stop spreading falsehoods, these facts are readily avaliable
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?
legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
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. Roll Eyes 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.
(...)
It is 'user-activated', not 'miner-activated'. Nodes >0.13.1 already support BIP148.
1. Looks like you really need catch up code. Node is verifying transaction only once - when arrived.
2. Not a single line about enforcing activation of SegWit in 0.14, so how 0.13.1 is supporting BIP148 (reminder: BIP148 was published 12. march)?

I don`t know how bitcoin works, so I never write a single line of bitcoin-related software, I never contributed to Core code, I never make public lecture about Bitcoin... I`m not a moderator of national Bitcoin forum in Poland either.
legendary
Activity: 3430
Merit: 3074
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.

No it isn't

Schnorr signatures confer scaling on-chain

Transaction encoding improvements confer scaling on-chain



Stop spreading falsehoods, these facts are readily avaliable
hero member
Activity: 770
Merit: 629
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?
We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality Smiley

Indeed.  You cannot enforce a soft fork with non-mining nodes.  You can just bring them to a standstill.

At that point, the only option for the user is to downgrade to an earlier version of core, or to download a bitcoin protocol compatible piece of software somewhere else.
Pages:
Jump to: