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

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

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

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.

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

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

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

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?

So is it likely bitcoin core will pass the above (ie done deal) or will there be controversy within bitcoin core itself on pulling the trigger on such?

(likely not..just not keeping up with all this ..figured quicker to just ask for views)

edit: by pass I mean of course bitcoin core puts it out there as something to activate by the users as you state above.

Hashing power:
40% for BU
30% for SW
30% undecided.
But.
BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?

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.

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

edit: fixed BIP number, its 148 not 168...  https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

Well looks like from the bitcoin core point of view 30% of this kinda hostile take over bitcoin FUD is to be expected and they are simply going to
ignore it...ie if you don't have the chops to take over from bitcoin core...we are gonna ignore your efforts or concerns....status quo

http://www.coindesk.com/bitcoin-on-developers-arent-worried-about-fork/

Oh well, I keep saying I want 'cheap coins' so I should shut up or put up

I really wonder how one still can think that shouting people down might lead to sth good here.

No

All means trying to 'control' bitcoin, people, forum, ... Is just NOT bitcoin. Try find some people you can sign off you ideas and feel free.

Im sure you ll get disrupted the next minute because you did no matter its good or bad.

Open your mind and let the big things happen. You are not alone.

Cry somewhere else. Fact is, you clearly have a very impaired understanding of Bitcoin and the relevant scaling debate. I'll call you out every time you make demands with psuedo-science.

What are you on about? Good luck propagating 15 MB blocks through the network and validating them on time.

Validation requires network bandwidth? Holy cuckoo.

You take your point. Even two. Very mature.

This isn't a valid argument to increase the block size limit. If this was an valid argument, then anyone could push a scenario where it is required to keep raising the block size an *infinite* number of times by creating "too many" transactions (at each upper limit).

Whilst this is a very nice improvement, it has zero relevance. If you have a node with open ports, you will be straining yourself with upload bandwidth not download

Firstly, a client which has pruning enabled is not a full node, it is a pruned node. Secondly, it requires ~4-5 GB of space (not 20 GB). You don't even know what you're talking about and you are making demands!

Which leaves us with.. 0 seconds for validation? You really have no idea how Bitcoin works.

FTFY.

Speculation on SegWit. The popularity of Segwit has nothing to do with the popularity of the latter two.

Simple: Someone or a certain group of *someones* has been lobbying miners and feeding them FUD how LN would steal all of their fees and how Segwit == LN. Both claims are absurdly false.

No, that is most certainly not the case. From what I understand Ver, he wants to *fork away* from the Core contributors are any cost.

No. There will not be three currencies. If the BTU folk fork away, it is highly likely that Segwit would be activated very soon after that (be it with BIP9 signaling or UASF). In the case of two currencies, the latter, also known as BTU, would be an altcoin.

the funny thing is that segwit meant to be soooo backward compatible that it would be accepted.
yet they need deadlines.
makes me wonder why...

i also said to gmaxwell to instill some confidence by asking their partner BTCC to go make a segwit block and include a segwit tx within that block and see if it is acceptable.. worse case is its rejected and even worse case they could use part of thier $70m to pay BTCC $12.5k to say sorry for wasting their time for making a orphan

if it doesnt orphan. then it would give confidence.... strange thing is they are not explaining why such a backward compatible block actually needs a deadline before being made.

but very funny non the last seeing all the promise become empty

Yes they could, and yes, they would be rejected by clients compatible with Bitcoin Core's code.


I think Flag day would be November 15th 2017 according to BIP 148, IIRC.

Not sure about those actual details, but I would imagine so, yes.


What you could do is enable witness pruning before you downgraded (I believe witness pruning is implemented in 13.1). That would safely sidestep such issues (and you could continue to use 13.1 or greater if you so chose). Note that you're technically not a full node after that, although witness data in all the blocks before the Segwit flag day wouldn't be pruned.

Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.

Hmm, if I switch later (sometime after Flag Day = June 14, 2017) to a 0.13.1 or higher version then will my node catchup on all of the witness data blocks?

If I were to run a 0.13.1 or higher version and then downgrade (not sure why, just thinking out loud) then would my full node be ok or would it get confused by the witness data blocks?  Hmm, is downgrading a risky behavior?  Ah, or would downgrading safely involve starting from scratch (in terms of the whole blockchain)?

Likely "Flag day" activation, it was accepted as a draft BIP recently (BIP 149 IIRC)


If you're using 0.13.1 equivalent client or higher, do nothing and you'll receive tx/witness original style blocks, and the new form of witness blocks.

If you're using 0.13.0 equivalent client or lower, you'll only receive the tx/witness original style blocks. Witness blocks are an add-on parallel block, older nodes will not receive the witness blocks, Segwit nodes won't relay witness blocks to "0.13.0 or less" nodes.

Ok, suppose there's no bone thrown from Core to the other camp(s).  When the heck does SegWit activate?  And more importantly, how does it activate?  Hmm, the SegWit blocks will be accepted by "original" Bitcoin nodes because they look good.  So, a bunch of blocks end up on the chain with "extra" meaning.  Weird.

So, my full node (no matter what version I'm running) will see these SW blocks; will they be ok?  Hmm, do SW blocks come in two flavors?  One with the witness data and one without?  Which will my full node get?  If a block with witness data is delivered couldn't it be bigger than 1MB?

Btw, the non-Core camps could embrace SegWit (or is FlexTran their choice instead?) to compromise, right?

I'm truly sorry to be so thick about this but I truly want to try to understand.

There might not be any road if you don't kick forward faster:

I don't think that core proponents are specifically against bigger blocks. Personally I am in favor of increasing the block size, but not in an incredibly stupid and irresponsible way like Bitcoin Unlimited, so I voted "Yes" in the poll.

one day
carlton: forks are bad

next day
carlton: just fork already

next day
carlton: forks are bad

just admit it.. dynamic implementations want consensus. its core that is going to pull the contentious split granade pin, no one else

dynamic implementations have made no threats of banning, changing algo or any deadlines. its just a free open choice and only activates if there is consensus.

if people really want to know what will happen if dynamic accepting pools were to rock the boat without consensus

about 3 seconds of drama.. and its over and in the trash no harm no foul.

it wont matter if the block was 250byte over limit 1mb over limit or 3terrabyte over limit.. 3 seconds later.. its in the trash.

dynamics has no contentious crap. it only works by consensus.
only core using a lower than 95% bip9(yep they can do that), UASF or algo change will cause contentious split

P.S dont blame the pools for being the only vote power of segwit..... core choice that way by going soft.