Bitcoin Forum

Update: For those new to the topic: There is already a precise proposal with a patch ready to be tested that implements this compromise solution, called "Segwit2MB (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html)", by Core security auditor Sergio Demian Lerner.

I have read this compromise proposal from "ecafyelims" at Reddit and want to know if there is support for it here in this forum.

Compromise: Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) (https://www.reddit.com/r/Bitcoin/comments/5y18ub/compromise_lets_merge_bip_102_2mb_hf_and_bip_141/)


It's very similar to what was already proposed last year at the Satoshi Roundtable. What is the opinion of the Bitcointalk community?

I'm all for compromise, but still feel that any static, fixed size is a clumsy and crude solution.  As many have argued previously, it's merely kicking the can down the road.  SegWit plus a modified hybrid of BIP100 and BIP106 (https://bitcointalk.org/index.php?topic=1801057.msg17965476#msg17965476) would be more flexible, adaptable and future-proof.  Not only that, but a sudden, arbitrary one-time surge in space leads to uncertainty and the possibility of abuse by spammers.  The change is healthier being gradual and predictable.

@DooMAD: What you say surely is valid - it's a short-term fix, but it would fix the current bottlenecks and already would enable Lightning and other offchain methods to be tested and in 2-3 years we can then switch to a more flexible variant.

And I think it would be very difficult in the actual situation to reach an agreement that includes some kind of "vote" by the miners for a certain block size, although your proposal seems to be much more moderate than BU (I have read it only superficially, though).

You have a good point, but I'm pretty sure that there will be no compromise.
The BU side thinks that the Segwit side are idiots, and the Segwit side knows that the BU side are idiots.
There is no compromise

We can say for sure that anything SegWit related is no longer gonna be accepted. Anti SegWit movement is too strong.
Naysayers will just conclude that this compromise is a simply backdoor for SegWit and 2MB blocks is just smoke and mirrors.

Unfortunately, I think we are about to head into the next evolution of Bitcoin
blockchain theory, in which what will occur has not really happened before
and we will learn new lessons about how Bitcoin truly functions.

Some will lose greatly and others will win, but the current community and
economy will suffer as a whole. When certain actors are no longer properly
incentivized, they will split the single chain premise because you can. For
someone to take such a risk with confidence, it is either clairvoyance or
absolute madness.

This is mostly due to communication failures, misunderstandings, ideologies,
and egos. Compromises are likely over. Now is the quiet before the storm.

If something doesn't happen soon, all out war will begin.
But, maybe that is the only answer to this question, sadly.

Extremism is malicious, within a Consensus system.

Code them up together, but allow each component to be activated *separately* thus allowing clients to choose which component they wish to support... I suspect support for BIP102 will be a lot higher now (yes I know about quadratic scaling issue.)

Is it not the case that segwit coded as a hard fork would mean that all UTXO's can be spent with segwit? No stupid network topology introduced like with the soft fork mechanism? If so, then yes I think it would be accepted, unless someone things there are reasons why it would be a bad idea. Although my worry then would be that we would be fighting for the next capacity hard fork with no leverage.

Given that dev fraction ( blockstream core) solution  SW looks rejected by miner fraction, compromise should be proposed from second fraction, not first one again.

And we might need a third, merchants?, to moderate in case.

The issue here is that if BU community and BU devs are not willing to cap the blocksize
or cap the blockweight, then there can never be compromise. They will fork eventually
since they are extremists. They are not looking out for the future, only themselves now,
in the most perfect form of greed. The greed that kills the golden goose, which is the most
stupid of all greeds.

 - BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
This is to bring about a more currency like device now, instead of later.
They do not mind network centralization or do deny/ignore its possibility of occurrence.

 - CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).
This is to maintain the unregulatibility and other like aspects now and later.
They do not mind slowed user growth or high fees or do deny/ignore their possible impacts.

They are fundamentally opposed. Like a couple that has different interests now and changed over time.
The normal situation would be that the couple would break up and each do their own thing.

If a compromise can be reached, it will be either full capitulation or a masterful answer still unknown.

Bigger blocks tend toward network centralisation, but decentralises the user base (more people can afford to send bitcoin).
Small blocks allow greater network decentralisation, but centralises the user base (only a few big actors can afford to send bitcoin).

How decentralised is LN?

It would seem the former of these two options was envisiged by the creator at the time. Nodes centralising around well connected mining nodes and bitcoin service providers, and users using SPV wallets.

I am not qualified to answer.
In theory, if designed and implemented appropriately, equal to Bitcoin's.



Yes, but there is one problem that is a constant misunderstanding in the
whole Bitcoin community.

When this belief was stated by Satoshi, Nodes were a single entity.
The miners were validators and the validators were miners.
There was only one. Now, there are two separate systems.

Due to these two separate systems, there are two possible choices now.
Satoshi's original comments (as to Nodes) no longer apply to today's reality.

yes I like this idea. If this can be a configuration choice for node operator to vote, that would be even better.

Forget about BU and BC, we need Bitcoin United ;D

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. 

I don't think the fact that not all nodes are mining nodes changes the fundamental premise. In fact it strengthens it as there are more validation nodes.

your putting words into people mouths.

1. Bu/bigblockers dont want one brand running anything... most bu/bigblockers are happy with bitcoinj, xt, classic, btcd, etc all running on the same level playing field all using real consensus to come to agreement.. and if core got rid of blockstream corporation. would be happy with core too.(main gripe is blockstreams centralist control)

2. small blockers have shown distaste for anything not blockstream inspired/funded..  (rekt campains agains bitcoinj, xt, classic and bu)

3. correct(people keep funds on thier personal privkeys and use future LN services voluntarily)

4. correct(people move funds to new keys and multisigs where payments need an LN counter party signing. but done forcefully due to politics/fee war games)

Changing MAX_BLOCK_SIZE to 2MB + segwit literally means we will see 4-8MB blocks.

No thanks ,

I don't care is this HF proposal comes from core or another repo , I will reject it and stay on the original chain. Developers have no power over what software I choose to run .

4-8MB blocks is too big and I am only interested in HF that include many HF wishlist items and permanently solve the scaling problem instead of kicking the can down the road a few months.


Here are some academic papers that reflect how dangerous blocks over 4MB currently are and one reason why segwit limits blocksizes to 4MB max.

http://bitfury.com/content/5-white-papers-research/block-size-1.1.1.pdf

http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf

This is a dangerous precedent giving control to miners or developers without community consensus. Hard forks should be a matter of last resort and when a SF is on the table that offers the same essential blocksize increase as classic we should be greatful and take it instead.

There is significant moral hazard and social hazard in forcing a HF on the community and how that will make us all insecure in the future. If the Developers or miners are viewed as a group that is perceived they can change the protocol without overwhelming consensus of the bitcoin users than they can easily be manipulated and attacked by bad actors like states and others.

There will guarantee be a split where 2-3 coins exist for one thing which will cause short term havoc due to uncertainty, loss of immutability , breaking the 21 million limit promise, moral hazard , social hazard, ect...(Remember Bitcoin is actually used for things unlike Ethereum which is 100% speculation, thus a split is far more damaging to bitcoin)

The ETF follows the most worked chain only, thus if the miners are swayed back to the originally chain after many of us dump our split coins all those ETF investors lose their investment value.

4-8MB blocks will lead to centralization, increase miner and node centralization and force me to shutdown my personal node.

No, you missed my point. I thought it was more evident.
Non-mining nodes are not incentivized the way Miners Nodes are.

The point being:
both can have opposite votes now (two sides), instead of the vote
always tending toward the same incentivized choice by Hardfork.
Now there are more possibilities such as Softforks. (User activated
fork is now another one, but is a new theory which is riskier than
either soft or hard.)

All I'm saying is when you cite Satoshi about Nodes, it was before
the Node split and is entirely in a different context that no longer
exists.

But non mining nodes are the majority of the network. Miners have to produce blocks that follow the network consensus or they get orphaned. Hard fork consensus means nodes update first, miners follow.

That doesn't matter. Miners can fork away without node validators
and the minority hash chain's difficultly will be too high (and may not
adjust in time to prevent possible failure). Meanwhile the Miner nodes
are on a new chain, mining & semi validating away. The minority hash
chain, could in short time, have no hash at all, in theory.

Your statement only applies if there is no malicious forking.
When the two node systems split, this possibility came into existence.
Prior to this, they always moved as one, since there was only one.

I see your point about malicious forking. At this point I need others view points to consider.

side note for you both,
"malicious forking"
many people are over using umbrella terms. of "forking"

try to stick with clear definitions (even im using gmaxwells buzzwords to keep things clear(so even he cant poke the bear))

EG soft = pools move without node
EG hard = node move and pools follow

consensus = if its near unanimous agreement(few orphans orphans now and again but one chain)
controversial = if its arguable low agreement (lots of orphans before it settles down to one chain)
bilateral split = intention avoidance of consensus/orphans/opposition (an altcoin creator with second chain sustaining life)

---

now then
segwit is in essense a soft consensus.
segwit has 2 parts. although pools change the rules without nodes consent. segwit has other things. like changing the network topology (FIBRE) so that they are upstream (central/top close to pools) able to translate and pass downstream block data in a form nodes can consent to/accept.

however putting segwit aside and looking at bip9 which is how pools were given the vote. a soft bilateral split can happen
bip9 allows
soft(pool) BILATERAL SPLIT

in essence ignoring opposing pools where by those other pools still hash
which can lead to:
a split of 2 chains where they continue and just build ontop of THEMselves, or
they give up and find other jobs, or
they change software and join the majority

---

totally different bip not even in any bitcoin version right now..
hard(node and pool) BILATERAL SPLIT
new UASF does this. (although the buzzword is meant to make it sound easier by stroking the sheep to sleep by pretending its a "soft" (S of UASF)fix. but because its node caused. its hard)

because it involves intentionally rejecting valid blocks purely based on who created it. it leads to the pool:
split of 2 chains where they continue and just build ontop of THEMselves, or
they give up and find other jobs, or
they change software and join the majority.

however because nodes are doing this. it can cause further controversy(of the nodes not pools) because the nodes are then differently selecting what is acceptable and hanging onto different chains

which is where UASF is worse than hard consensus or hard bilateral due to even more orphan drama

For the sake of clarification for users who wish to know what I was referring to,
it would be a "controversial hardfork". Node banning due to a majority of miners
being out of consensus does not matter, since those miners are intentionally leaving
the node network for good to create a chain that will directly fight with the old (replays).
In a sense, it is like dragging the old network with it. It would be a test in whether
network follows hash or the hash follows the network.

No one would want to do a purposeful bilaterial hardfork since then there will be time to
protect against such an situation and economies will be able to choose one or the other.
Bilaterial fork is when two parties agree to disagree. A controversial hardfork is by its
nature malicious since it will cause issues if performed correctly.

The real difference is that one is programmed to split and the other is an accidental split
that is purposefully attempting to maintain an invalid chain to the point in which it may
become a valid chain. In this event, malicious miners could in theory, with enough hash,
continue indefinitely, never needing to provide forewarning, like a bilaterial.

A controversial hardfork is malicious. A Bilateral hardfork in theory, is not.

Guy, there is No Compromise , no matter how , if Segwit is Activated the Miners are Fucked.
Segwit allows LN to function without Trust and will allow LN to Steal Transactions Fess directly from the miners.

There is No Compromise Possible as long as they want Segwit.

 8)

FYI:

FYI2:
Bitcoin Unlimited Fixes the issue for good without segwit, Nothing else needs to happen.

BTC Core Devs placed their own personal interests in front of BTC performance , they have to be fired as they can no longer be trusted.
Segwit is a Trojan, once activated it can never be removed from the blockchain.

When you get a transaction stuck on the chain for days on end with the standard fee and you have a two to three hour window to lock in a rate on a Bitcoin exchange to convert to fiat.
Yep BIP102 most certainly will start acquiring more support from the average users.

On the topic of compromise if people can get the support to do this scaling compromise then sure lets go with it.
In the end as long as the block-size rises in the short term we can keep kicking the bucket and that works for now.

While were at it someone could make a MSR on what Bitcoin's operating requirement is for the Chinese miners.

I worry that a scaling compromise may be just perpetual kicking  of the can and if we can't even kick the can we may really just end up with two chains.
A hard-fork may be the only way we will see consensus, as the capabilities and requirements where the miners are located is part of the current issue and a stakeholder mandate is needed not just a miner one.
https://randomoracle.wordpress.com/2016/01/25/observations-on-bitcoins-scaling-challenge/



I agree no one would want to do a purposeful hardfork if it can be resolved with a soft-fork but someone would at least try to get a general feel of the best solution in the case that a hardfork is the resulting outcome.

As you pointed out there are two clear development paths.

 - BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
This is to bring about a more currency like device now, instead of later.
They do not mind network centralization or do deny/ignore its possibility of occurrence.

 - CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).
This is to maintain the unregulatibility and other like aspects now and later.
They do not mind slowed user growth or high fees or do deny/ignore their possible impacts.

Whether it becomes two over one and we see a bi-lateral hardfork is what the real question is.


(Mumble sometimes someone bumps an old post and necros but this one is relevant to today)
https://bitcointalk.org/index.php?topic=48.0

No hard fork please, you know the price crashed due to Chinese Antpool mined BU block? Hard fork will 100% kill bitcoin, or hazard the price.

No Offense but if you truly believe what you just said, You should sell every crypto coin you own and stick with cash.
You are too timid for this environment.


 8)

I have read DooMAD's proposal now (https://bitcointalk.org/index.php?topic=1801057.msg17965476#msg17965476) and I like it a bit. It would give less powers to miners as they only can vote for small block size increases, but would eliminate the need for future hardforks. The only problem I see is that it could encourage spam attacks (to give incentives to miners to vote higher blocksizes) but spam attacks will stay as expensive as they are today will be even more expensive than today because of the "transaction fees being higher than in last period" requirement, so they are not for everyone.


That certainly sounds like a good idea, if the community decides to support this proposal. Would Core allow to activate that kind of compromise proposal coded into a real pull request?

It most likely will not work. As I have outlined in a recent post, there are too many different and "entrenched" camps.

We can even expand on this. There are people that think 51% of hashrate (node percentage is irrelevant) is adequate for a hard fork as an upgrade, and there are those who think that 100% is required. Both of these ideologies are absurd.

I do have to add that, while I think that it would be still extremely hard to gather 90-95% consensus on both ideas, I think both would reach far higher and easier support than either Segwit or BU.

Core can not stop community/miner consensus. Let me see a viable BIP + code first, then we can talk about that.

I agree with this and for some reason the community is blind to it.
There seems to be a denial and slight delusion about all this.
This is mainly why I have come to the unfortunate conclusion that a hardfork to
attack or to split the community is not far off now. We are just chasing the tail.

Also, I'm sure if the ETF is denied on Friday, Core supporters and BU supporters
will blame the other, and if accepted (which IMO is not likely) each side will take
the credit. The point being that those two sides are locked into perpetual hate.

firstly core bypassed community consensus using bip9 by going soft..


secondly read bip 9, yep it can be changed. even gmaxwell admits this.

^ this is where the UASF comes in (A leads to B leads to C)

secondly you personally know about banning nodes. you have often highlighted yourself as the guy with all the 'know' of the node IP's everyone should ban

its not rocket science

Core would not because they're all convinced we must have segwit before increasing the block size to prevent a quadratic scaling sigop DDoS happening... though segwit doesn't change the sigops included in regular transactions, it only makes segwit transactions scale linearly which is why the blocksize increase proposal is still not on the hard roadmap for core as is. If block generation is biased against heavy sigop transactions in the core code (this does not need a consensus change, soft fork or hard fork) then pool operators would have to consciously try and include heavy sigop transactions intentionally in order to create a DDoS type block - would they do that? Always assume that if a malicious vector exists then someone will try and exploit it, though it would be very costly for a pool to risk slow block generation/orphanage by doing so.

Maybe you can help to dispel some commonplace FUD about the sigops DDoS attack.

Bitcoin already has a sigops per block limit to mitigate the risk of this attack (despite the FUD that introducing such a limit is all that's needed to solve the problem, which is pretty dumb considering that's already what happens ::))




Now, surely this limit could continue to apply to the base 1MB block _after_ segwit is activated (which can only contain sigs from non-segwit transactions)? Is this how the fork is coded anyway?

That's just silly hysteria. You should be made aware that BU blocks have been mined into the main Bitcoin blockchain for over a year now.

Forgive me if i'm a bit skeptical that segwit is a good idea.  It sounds very complicated and
that once we do it, we'll be stuck with it.

I thought it was initially promoted as a way to avoid a hard fork but if we're going to
be forking to 2MB anyway, what is the point?

It's just a flag added to the block to show whether the pool is voting for segwit or BU, nothing more. The blocks are exactly the same otherwise as far as I know.

Well, yes. I was just illustrating how hysterical the notion that "the price crashed due to Chinese Antpool mined BU block" was.

cores limit is not low enough

MAX_BLOCK_SIGOPS_COST = 80000;
MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

who the damned F*ck should be allowed to build a single tx that uses 20% of a block!!
who the damned F*ck should be allowed to build a single tx has 16,000 sigops!!

lower the TX sigop limit to something rational and you wont have the worry of delays due to sigop validation

also. one thing CB is missing out on


meaning native transaction users can still sigop SPAM.
segwit has nothing to do with disarming the whole block.. just segwit transaction users

again because carlton is not quite grasping it

No.

Banning nodes is completely fine.

---

Anyone ready for the altcoin called BTU? ::)

https://i.imgur.com/pkiscE1.png
https://i.imgur.com/cyAh83x.png

https://twitter.com/zaifdotjp/status/839692674412142592
https://twitter.com/SatoshiLite/status/839676935768715264

apparently, Sigop DDoS attack is possible now, because the Sigops per block limit is too high.


Why isn't anyone using the attack then? :D

Bitcoin is permissionless. The proper answer to "who the damned F*ck should be allowed to build..." is anyone who wishes to.

But another aspect of permissionless is the fact that no miner is compelled to include that transaction into a block. In fact, there is a natural disincentive to any miner including such a transaction into a block. Blocks that take a long time to validate are likely to be orphaned by other blocks which validate quickly.

You're sounding like a Segwitter jbreher


How come Franky, the Bitcoin genius who loudly shouts about how loudly shouting makes him right all the time, can't figure this out too

but this is where the rules need to be defined. so that if a malicious pool did add it. the LOWER tx sigops would be knowingly rejected by consensus so pools wont bother.

by keeping it at 16,000 malicious pools 'could' accept it and know its a valid block and only have to worry about 'timing' as the disincentive, rather than RULES.

however if you prefer not to have RULES and just rely on belief or faith of pools.. then that is a weakness.
however if belief and faith were strong for such an occurrence not to happen. than quadratics has never been a problem and never be a problem because bitcoin is protected by belief that it will get orphaned due to 'time'.

meaning segwit doesnt need 100% of users to move their funds to segwit keys (weeks after activation) just to possibly get a segwit fix to fix it(never gonna happen anyway), because belief alone in 'time' has protected the network thus far and will continue to

No new rules need be defined.


No weakness. No belief. No faith. Natural incentives of rational self-interest.


Yes - now you're getting it.

I don't understand that statement. Are you talking about DooMAD's idea (modified BIP100+BIP106) or the compromise proposed by "ecafyelims", or both?

I ask because I think DooMAD's "10%-blocksize-change-voting proposal" sounds interesting and if there is support by staff/respected community members/devs then it would be worth discussing it in a separate thread to elaborate a "final BIP".


Well, if I understand right (as a [almost] non-programmer) then that problem could be solved by coding the change proposal in a way that explicitly delays the hardfork until a lot of time (several months) has passed after the Segwit activation. That should be possible - it would then signal the "big blockers" that their desired blocksize change will come, but would give the system time to adopt Segwit transactions.

my "doesnt need" was sarcasm because segwit does actually need it.
the sarcasm was pointed at those that think segwit will fix the issues simply by the belief in 'time'

Your sarcasm escaped me. Though I must admit your statement elicited some surprise, as you have indeed been otherwise consistent in your advancing the notion that the quadratic hashing time solution within The SegWit Omnibus Changeset could simply be stepped around by an attacker.

Why I am trying to tell you is that it doesn't matter. It's not a problem in any systemic sense. Market forces will conspire to orphan blocks that take an inordinate amount of time to verify. Regardless of which -- or even if any -- scaling solution be adopted.

From memory the closest we've come to that to date was that single transaction 1MB block from f2pool that took nodes up to 25 seconds to validate. It is possible to make it much worse, but newer versions of bitcoind (and probably faster node CPUs) would have brought that down. Rusty at the time estimated it could still take up to 11 seconds with 1MB:

https://rusty.ozlabs.org/?p=522

So yeah it has been used... possibly unwittingly at the time.

so there has never been an excessively quadratic blocks in bitcoin.. due to faith in "time"

:D are you sure :D

careful how you reply, careful what you say next. the blockchain history never lies

by limiting blocks ability to make a 1mb tx
by having improvements of libsec
by having hardware improvements (raspberry Pi is now atleast v3) quadratics doesnt become an issue.

if blocks grow to say 8mb we just keep tx sigops BELOW 16,000 (we dont increase tx sigop limits when block limits rise).. thus no problem.

however needing to rely on "probability of time" or "hope of 100% user migration of funds to segwit keypairs" is not a good enough solution to me and not a good enough thing to be selling segwit as the solution for. (because 100% key adoption wont occur, malicious users will stay with native keys on purpose)

No compromise.

When I read your comment, this is what my mind flashed to.
https://www.youtube.com/watch?v=9fdcIwHKd_s (https://www.youtube.com/watch?v=9fdcIwHKd_s)

No, "there has never been an excessively quadratic blocks in bitcoin". Yes, I am sure.

Of course, 'excessive' requires finesse. There has been, to my knowledge, one block in the history of bitcoin that contained a single transaction of nearly 1MB. That transaction took quite a long time to validate due to the quadratic hash time issue.

But what has been the repercussions of this event? Naddadamnthing. Well, there has been endless FUD yammering and chicken-little-ing. But in terms of the core function of Bitcoin, there has been exactly zero effect. In other words, not excessive.

Of course, if a persistent repeated sequence of such blocks were to be somehow mined back-to-back, that might slow transaction processing to a crawl*.

That is, if no other miner bothered to mine a competing block. Which, of course, is what a rational miner would do in such a situation. For then he would reap the rewards of a more-quickly validating block. (That would be the coinbase reward for solving a block).

The 'excessivity' solves itself. Through natural incentive of rational self-interest.

Sure, we should replace the current algorithm with one that scales linearly. After we address more pressing issues. Such as the cartel-like hard capped transaction production quota.

*Anyone supporting the core approach to 'scaling' has already tacitly accepted transaction processing being slowed to a crawl.

You keep talking about miners mining this more quickly validating block... there is no code currently that can try to validate two different blocks concurrently and pick the one that validates faster. The first one that comes in will be under validation while any other blocks come in wait before they can be validated so unless someone has a rewrite that does what you claim, the problem still exists. First block that hits will always win.

This and other similar mix of BIP's has been suggested... If it scales, I'm down for it or pretty much anything else.


Very interesting post. The other issue I see here is that such code doesn't exist, thus isn't tested, so it can't be deployed anytime soon.

also worth noting

miners dont care about blocksize.

an ASIC holds no hard drive. an asic receives a sha256 hash and a target.
all an asic sends out is a second sha256 hash that meets a certain criteria of X number of 0's at the start

miners dont care if its 0.001mb or 8gb block..
block data still ends up as a sha hash

and a sha hash is all a miner cares about

---

pools (the managers and propagators of blockdata and hash. do care what goes into a block)

when talking about blockdata aim your 'miner' argument to concern pools ... not the miner(asic)

No disrespect intended. But should excessively-long-to-validate blocks ever become significant, mining using an implementation that does not perform parallel validation is a guaranteed route to bankruptcy.

"no code" - you sound pretty sure of yourself there. It may even be the case ... right up until the point in time that it is not.

Right, there is no *public* code that I'm aware of, and I do hack on bitcoind for my own purposes, especially the mining components so I'm quite familiar with the code. As for "up until the point in time that it is not", well that's the direction *someone* should take with their code if they wish to not pursue other fixes for sigop scaling issues as a matter of priority then - if they wish to address the main reason core is against an instant block size increase. Also note that header first mining, which most Chinese pools do (AKA SPV/spy mining), and as proposed for BU, will have no idea what is in a block and can never choose the one with less sigops.

im starting to see what game jbreher is playing.

now its public that segwit cant achieve sigop fix. he is now full on downplaying how bad sigops actually is...
simply to down play segwits promises by subtly saying 'yea segwit dont fix it, but it dont mtter because there is never been a sigop problem'

rather than admit segwit fails to meet a promise. its twisted to be 'it dont matter that it doesnt fix it'.

much like luke JR downplaying how much of a bitcoin contributor his is at the consensus agreement. by backtracking and saying he signed as a human not a bitcoin contributor.. much like changing his hat and pretending to be just a janitor to get out of the promise to offer a dynamic blocksize with core.

https://bitco.in/forum/threads/buip033-passed-parallel-validation.1545/

For those unwilling to click through:

Now you just look silly. I'll leave it at that.

Thanks I wasn't aware of that. Probably something worth offering in conjunction with BIP102 then.

I support SegWit  ;D

Both.

The idea is worth discussing on its own, regardless of whether there is support by others. Do note that "support by staff" (if you're referring to Bitcointalk staff) is useless. Excluding achow101 and potentially dabs, the rest have very limited or just standard knowledge. Did you take a look at recent luke-jr HF proposal? Achow101 modified it by removing the initial size reduction. Read: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013544.html

That's not how this works.

Which effectively.. solves nothing.

I could get behind Achow101's proposal (https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki) (the link in that linuxfoundation text ended with an extraneous "." which breaks the link) if that one proves less contentious.  I'd also consider tweaking mine to a lower percentage if that helped, or possibly even a flat 0.038MB if we wanted an absolute guarantee that there was no conceivable way it could increase by more than 1MB in the space of a year.  But recurring increases every diff period are unlikely if the total fees generated has to increase every time.  We'd reach an equilibrium between fee pressure easing very slightly when it does increase and then slowly rising again as blocks start to fill once more at the new, higher limit.

I forgot to mention in my previous post, that this is a healthy stance to have as the majority of the technology oriented participants of the ecosystems are fully backing Segwit.

I think it does, as it doesn't initially reduce the block size. This is what made luke-jr's proposal extremely contentious and effectively useless.

I don't like fixed increases in particular either. Percentage based movements in both directions would be nice, but the primary problem with those is preventing the system from being gamed. Even with 10%, eventually this 10% is going to be a lot. Who's to say that at a later date, such movements would be technologically acceptable?

The thing to bear in mind is we'll never make any decision if we're too afraid to make a change because there's a possibility that it might need changing at a later date.  Plus, the good news is, it would only require a soft fork to restrict it later.  But yes, movements in both directions, increases and decreases alike would be ideal.  This also helps as a disincentive to game the system with artificial transactions because your change would be undone next diff period if demand isn't genuine.

You could argue that it may already be quite late/near impossible to make such 'drastic' changes. I've been giving this some thought, but I'm not entirely sure. I'd like to see some combination of the following:
1) % changes either up or down.
2) Adjustments that either align with difficulty adjustments (not sure if this makes thing complicated or riskier, hence the latter) or monthly adjustments.
3) Fixed maximum cap. Since we can't predict what the state of the network and underlying technology/hardware will be far in the future, it is best to create a top-maximum cap a few years in the future. Yes, I know that this requires more changes later but it is better than nothing or 'risking'/hoping miners are honest, et. al.

imagine a case where there were 2 limits.(4 overal 2 for nodes 2 for pools)
hard technical limit that everyone agree's on. and below that a preference limit (adjustable to demand of dynamics).

now imagine
we call the hard technical limit (like old consensus.h) that only moves when the NETWORK as a whole has done speed tests to say what is technically possible and come to a consensus.
EG 8mb has been seen as acceptable today by all speed tests.
the entire network agrees to stay below this, pools and nodes
as a safety measure its split up as 4mb for next 2 years then 8mb 2 years after that..

thus allowing for upto 2-4 years to tweak and make things leaner and more efficient and allow time for real world tech to enhance.
(fibre obtic internet adoption and 5G mobile internet) before stepping forward the consensus.h again

---

then the preferential limit(further safety measure) that is adjustable and dynamic (policy.h) and keeps pools and nodes inline in a more fluid temporary adjustable agreement. to stop things moving too fast. but fluid if demand occurs

now then, nodes can flag the policy.h whereby if the majority of nodes preferences are at 2mb. pools consensus.h only goes to 1.999
however if under 5-25% of nodes are at 2mb and over 75% of nodes are above 2mb. then POOLS can decide on the orphan risk of raising their pools consensus.h above 2mb but below the majority node policy

also note: pools actual block making is below their(pools) consensus.h

lets make it easier to imagine.. with a picture

black line.. consensus.h. whole network RULE. changed by speed tests and real world tech / internet growth over time (the ultimate consensus)
red line.. node policy.h. node dynamic preference agreement. changed by dynamics or personal preference
purple line.. pools consensus.H. below network RULE. but affected by mempool demand vs nodes overall preference policy.h vs (orphan)risk
orange line.. pools policy.h below pools consensus.h
https://i.imgur.com/CPISuXV.png

so imagine
2010
32mb too much, lets go for 1mb
2015
pools are moving thier limit up from 0.75mb to 0.999mb
mid 2017
everyone agree's 2 years of 4mb network capability (then 2 years of 8mb network capability)
everyone agree's to 2mb preference
pools agree their max capability will be below everyones network capability but steps up due to demand and node preference MAJORITY
pools preference(actual blocks built). below other limits but can affect the node minority to shift(EB)
mid 2019
everyone agree's 2 years of 8mb network capability then 2 years of 16mb network capability
some move preference to 4mb, some move under 3mb some dont move
late 2019
MINORITY of nodes have their preference shifted by dynamics of (EB)
2020
MINORITY nodes manually change their preference to not be controlled by dynamics of (EB)
late 2020
MINORITY of nodes have their preference shifted by dynamics of (EB)
2021
MINORITY nodes manually change their preference to not be controlled by dynamics of (EB)
mid 2021
a decision is made whereby nodes preference and pools preference are safe to control blocks at X% scaling per difficulty adjustment period
pools preference(actual blocks built). below other limits but can shift the MINORITY nodes preference  via (EB) should they lag behind

p.s
its just a brainfart. no point knit picking the numbers or dates. just read the concept. i even made a picture to keep peoples attention span entertained.

and remember all of these 'dynamic' fluid agreements are all extra safety limits BELOW the black network consensus limit

I like that we're moving forward in the discussion, it seems. The original compromise that was the reason for me to start the thread now looks a bit dated.

I would support Lauda's maximum cap idea, as it's true that there could be circumstances where such a flexible system could be gamed.

The challenge is now to find a number for this cap. I had done some very rogue calculations that a 1 TB/year blockchain (that would be equivalent to approximately 20 MB blocks) would enable 160 million people to do about 1-3 transactions (depending on the TX size) per month. That would be just enough for this user base if we assume that Lightning Network and similar systems can manage smaller pauments. 1 TB/year seems pretty high, but I think it's manageable in the near future (~5 years from now).

Obviously if we want the 7 billion people on earth to be able to use Bitcoin on-chain the limit would be much higher, but I think even the most extreme BU advocates don't see that as a goal.

My thoughts are:

Was the 1 MB cap introduced as an anti spam measure when everybody used the same satoshi node, and did that version simply stuff all mempool transactions into the block in one go?

Big mining farms are probably not using reference nodes, since they probably wouldn't be able to pick transactions where they have been priotised using a transaction accelerator.

Increasing the block size cap in the simplest manner would avoid BU technical debt, as the emergent consensus mechanism probably wouldn't work very well if people do not configure their nodes (it would hit a 16MB cap in a more complicated manner.)

Miners have to way up the benefits of the higher processing costs required to build a bigger block versus the orphan risk associated with the delay caused by it. In other words, a more natural fee market develops.

So it won't be massive blocks by midnight.

Any comments? (probably a silly question  ;) )

mhm
dont think 7billion by midnight.

think rationally. like 1billion over decades.. then your fears start to subside and you start to see natural progression is possible

bitcoin will never be a one world single currency. it will be probably in the top 10 'nations' list. with maybe 500mill people. and it wont be overnight. so relax about the "X by midnight" scare storys told on reddit.

Yes, that's exactly what my 'proposal/wish' is supposed to have. A dynamic lower bound and a fixed upper bound. The question is, how do we determine an appropriate upper bound and for what time period? Quite a nice concept IMHO. Do you agree?

What software did you do this in? (out of curiosity)

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

Preference level for me:
Segwit + dynamic block size proposal (as discussed so far) > Segwit alone > block size increase HF alone > BTU emergent consensus. The latter is risky and definitely not adequately tested.

Preference level for me would be (current moment of thought - I reserve the right to change my mind):
Segwit + dynamic block size HF > block size HF > BTU > Segwit SF. The latter introducing a two tiered network system and a lot of technical debt.

Although a quick and simple static block size increase is needed ASAP to allow time to get the development of the preferred option right.

Exactly. There is no problem which requires solving. This merely eliminates the DoS potential that quadratic hash time exploits might incur, if there was not this obvious workaround already inherent in the protocol.

Lesser implementations that have no embedded nullification of this exploit may wish to take note.

i just quickly opened up microsoft excel and added some 'insert shape' and lines..
i use many different packages depending on what i need. some graphical some just whatever office doc i happen to already have open

lol

blockstreamer: segwit solves quadratics, its a must, its needed. quadratics is a big deal and segwit promises to solve it
community: malicious users will stick to native keys, thus still quadratic spamming even with segwit active.. meaning segwits promise=broke
blockstreamer: quadratics has never been a problem relax its no big deal

i now await the usual rebuttal rhetoric
"blockstream never made any contractual commitment nor guarantee to fix sigop spamming" - as they backtrack earlier promises and sale pitches
or
personal attack (edit: there we have it, p.S personal attacks aimed at me sound like whistles in the wind)

You're looking ridiculous again, franky1. Y'all might wanna reel you-self back in.

Having a little thought about this concept of 'emergent consensus'. Is not the fact that different versions of nodes, or different versions of different node implementations that exists on the network today a form or 'emergent consensus'?

to answer your question is..

basically that BU and core already have the variables..

nodes: consensus.h policy.h
pools: consensus.h policy.h

and that all nodes have 2 limits although not utilitised to the best of their ability.. meaning at non mining level core does not care about policy.h

and the punchline i was going to reveal to Lauda about my example of dynamics.
BU uses
consensus.h (...) as the upperbound limit (32mb(2009), then 1mb for years and in the future going up as the hard limits EG 16mb)
policy.h (...) as the more fluid value BELOW consensus.h that if the node is in minority. can be pushed by EB or the user manually without needing to wait for events. which is signalled in their useragent eg 2mb and dynamically going up

core however, require tweaking code and recompiling to change both each time)

AT this point in time it is about POWER to move the future of btc imho. The devs of any flavor..most are mega whales..so it is the coding/power trip now...
as reasonable as this sounds...I just don't see it happening because of  price above 1k and 1mb block size for bitcoin core is just dandy for all they care. NOT saying
I agree on either camp but bitcoin core...sees BTC as a store of value..so imho...it can sit at 1mb for years as long as price does reflect that store of value thinking

thus stalemate..thus 1mb btc...so only other option if I'm correct (hope i'm not) is an attempted BU fork and/or BU gets 51% of the folk to push their view

all very silly..just compromise already..its NOT like if we had another unexpected btc fork like back in the day ..they would not pop out a hard fix anyway

(what do I know I at one time drank the BFL kool aid) but just seems it is about status/power and the devs of any flavor just really, really don't like the other camp

 

Segwit IS the compromise. I've refrained from saying this up until recently, but I think 4MB is too big. I'd be much happier with a Segwit proposal that kept the size at 1MB, but in the hope that others would recognise that 4MB is meeting in the middle, I helped to promote Segwit hoping they would accept it. The fact they have rejected Segwit only demonstrates that bigger blocks has got nothing to do with it, it's about having power over the source code.

segwit is not the compromise

activating segwit solves nothing.
moving people to segwit keys after activation is then a 'percentage of solution'

never a complete 100% solving bugs, or never 100% fixing or never 100% boosting. because even after activation segwit will still be contending against native key users

also the 4mb segwit weight is not utilised.
AT VERY BEST the expectation is 2.1mb.. the other 1.9mb would be left empty.
segwit cannot resegwit again to utilise the 1.9mb extra weight.

the extra weight would be (from reading core/blockstream plans) with bloat data to include confidential commitments appended onto the end of a tx. (not extra tx capacity) to bloat a tx that would have, without confidential commitments been alot leaner

---

segwit also turns into a 2 tier network of upstream 'filters' and downstream nodes. rather than a equal network of nodes that all agree on the same thing.

for the reddit crew.. in simple terms. segwit fullnode = full data.. downstream= 'tl:dr' nodes

They are just two very different approaches... I thought the activation of Segwit will then followed by "easier/better" future plan of blocksize increase?

Perhaps we can compromise and buy time by allowing bigger blocks (eg. 2MB) to activate, and then decide if Segwit should be implemented?

This second compromise is nothing but a veiled attempt at setting a precedent that we force a HF without consensus on the community and either giving the decision to miners or developers instead of the users themselves. As we can see from this poll , consensus over a HF is not anywhere near being found and thus the HF proposal offered isn't anywhere good enough to be considered. I don't want to even consider accepting politically motivated hard forks and just want to focus on whats right for bitcoin.

Segwit IS the compromise, and it's more of a compromise towards big blocks than what you're suggesting. ::)


Which is bigger, 2 MB blocks or 4 MB blocks   ::)

As many have argued before, I think this will not work, whereas in the other hand it is damaging, I personally think segwit + a different transformation will be more flexible, such as BIP 106. I have a great deal of faith in this transformation, and we need a healthy and predictable change that we should not take unexpected measures. But in the actual situation, I think this is very difficult, the miners will always keep their decision, so it is difficult to change.

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.

or if having an organised hard consensus (meaning old nodes have to drop off anyway(the small minority outside activation threshold)
dynamic blocks (using policy.h(lower bound) as the dynamic flagging scaler) and segwit keys. where the witness is appended to the tail of the tx.
without needing to have separation(of tree's(blocks)).

that way ALL nodes validate the same thing.

(ill get to the punchline later about the then lack of need for segwit.. but want to see if people run scenario's in their head first to click their lightbulb moment into realising what segwit does or doesnt do)

for clarity


FTFY

In theory you can get up to 14 TPS with Segwit. However, with realistic usage that is not the case (similarly with the current network having a theoretical capacity of 7 TPS). Segwit will definitely deliver >2 MB according to the latest usage patterns.

It is.

It does.

Nobody cares. You can't DOS the network with "native" keys post Segwit.

This is only the case if the majority of nodes don't support Segwit. Ironically to your statement, the big majority is in favor of Segwit.

emphasis >2mb
> (should be UPTO, but your saying more than) but only if 100% segwit key use to get 2mb
dont down play it that nothing needs to be done by users to attain the 2mb..
also factoring in native spam and users not using sgwit keys. the entire baseblock wont be 100% segwit users meaning not attaining 2mb
EG
imagine there were 4500 users. so far they argue over blocksize that can only fit ~2250
even if 4499 users moved to segwit.
1 users can make 2249 NATIVE transactions. meaning only 1 segwit transaction gets in. so the 'blocksize. only becomes 1.000444


lauda: compromise meaning lost, sold out, victim 'you left your password on girlfriends phone, now your funds are compromised'
community: compromise meaning agreed reduced level

segwit is not an agreed reduced level. its a risk of screwing many over for the fortunes of the corporate elite


go on PROVE IT!! explain it


you can.
native keys still work after segwit activates. otherwise 16mill coins are locked and unspendable!!

segwit activates by pool only.
meaning(if all pools were equal for simple explanation)
19 out of 20 pools activate it.
1 pool gets disreguarded.
but then the node count turns to
~3000 upstream full validation UPSTREAM filters.
and
3000 hodgepodge of downstream nodes that dont fully validate, may have witness may not have, may be prunned may not be.

which the upstream nodes wont sync from but "could" filter to (if they were not banlist biased)

There is nothing wrong with that. Users are incentivized to start using Segwit and plenty of providers are either already ready or are 'in-progress'.

No. That is just one of the meanings, see here: http://www.dictionary.com/browse/compromise

This is bullshit and you know it.

Everything is properly explained on the Bitcoin Core website. Do I really need to draw it out for you?

Wrong. The DOS attack vector is not present at 1 MB, and you can't create a 2 MB block with native keys when Segwit is activated.

You can blame BU for their stubbornness to implement SWSF. A lot of the very outdated nodes are irrelevant IMO, they don't properly validate some newer soft forks anyways (+ potentially have security holes as they can be very outdated, e.g. <0.10.0).

lauda please

native keys would fill the 1mb base block so that segwit cant get a chance.. thus there wont be a 2mb block..
EG
imagine there were 4500 users. so far they argue over blocksize that can only fit ~2250
even if 4499 users moved to sgwit.
1 users can make 2249 NATIVE transactions. meaning only 1 segwit transaction gets in the base. so the 'blocksize. only becomes 1.000444
in short
even if 99.9% of users moved over to segwit, they are still subject to normal bloat from a malicious bloater filling the base block. which takes up the base block space to not allow segwit key users in. thus the ratio of segwit in base:witness is super low... thus total blocksize remains super low, but the base block is super filled with native bloat

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.

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.

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:

https://image.slidesharecdn.com/logicfordummies-isbn0471799416-131208002917-phpapp02/95/logic-for-dummies-1-638.jpg?cb=1386463664

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.

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"

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.

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?

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.

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

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

The opposite

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



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

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

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.

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.

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

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

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.

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

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?

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.

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.

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.

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.

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.

In what time frame? Next 5, 10 years?

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.

You are engaging in a discussion between another user and myself; we are free to discuss whatever we want and however we want. If you can't comprehend our discussion properly, then don't comment on it.

Where is the academic research backing up that 8 MB is safe as upper limit? For which time frame? How does the 2 MB grow to 8 MB? At what periods?

if you want a private conversation between 2 people then go to Private message with them


even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
as for how...

are you forgetting the example of dynamics . i even drew you a picture to keep your concentration span open.

what you need to understand by having the limits is that the NODES flag what they are happy with and POOLS work below that.
meaning it wont get out of control of what general nodes can cope with. because the nodes are flagging it.

oh and i remember rusty russel (blockstream) had some stats of 8mb being fine. so try not to proclaim that 8mb is evil as its your gangs own agreement that 8mb is fine as a upper limit, but a preference for less as a lower limit

You need to visit some courses in order to improve your faulty comprehension skills. We can discuss whenever we want and wherever we want.

Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.

No. I'm asking you for the specifics of your proposal, but there are none apparently.

So what is the technical reason for this to be the case?

For one (ignoring everything else): Linear sigops validation vs. quadratic validation.

lol segwit doesnt solve it!!

even after segwit activates native key users are not disarmed.
segwit only offers to disable people who voluntarily use segwit keys to perform quadratics by not having the quadratics problem in a segwit key tx signing.

it does not take the quadratics opportunity away from native key users.

reducing or keeping tx sigops limit at or below 16,000 sigops per block no matter what the blocksize is. ensures quadratic spammers cannot spam large sigop quadratic tx's
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000

core 0.12: MAX_BLOCK_SIZE = 1000000;
core 0.12: MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
meaning
core 0.12: MAX_BLOCK_SIGOPS = 20000
core 0.12: MAX_STANDARD_TX_SIGOPS = MAX_BLOCK_SIGOPS/5;
meaning
core 0.12: MAX_STANDARD_TX_SIGOPS = 4000;

segwit actually allowed increasing tx sigops limit since v0.12 from 4000 to 16000 . while thinking that people will all be using segwit keys will be enough defense.. they have not thought about native users taking advantage.

oh and please dont instantly reply, untill you read the code.
read the code dont just reply "wrong because blockstream are kings"


edit: after reading lauda's instant reply below.. i actually pasted in and done the maths for him from cores own code...
lauda: read the code.

You still don't understand how Segwit works?
1 MB quadratic hashing = no DoS risk AFAIK.
2 MB quadratic hashing -> DoS risk.
Segwit activated 2 MB block (Segwit TXs) = no DoS risk (linear hashing)
Segwit activated 1 MB block (old TXs) = no DoS risk at 1 MB (quadratic hashing).

That.. doesn't actually solve it IIRC. Have you actually proposed this somewhere/done calculations or did you pull 16k out of thin air?

What is the reason for old tx's using quadratic hashing instead of linear hashing, and why is it considered safe with segwit if not for normal transactions?

That's the way that it is currently implemented; a known inefficiency (O(n^2) time). This is one of the reasons for which Segwit is quite beneficial. They packed up a lot of improvements at once.

But is there any reason that this could not be implemented on the old tx's?

Segwit introduces a new transaction type which can't be malleated as old TX's and which have linear scaling. I don't know what exactly is needed in order to make old TXs scale linearly as well. I'm going to assume that it may require a hard fork of some type.

sigop attack
v0.12 had a 4000 sigop per tx limit (read the code)
v0.14 had a 16000 sigop per tx limit (read the code)

so now check the code.
https://github.com/bitcoin/bitcoin/tree/0.14/src
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000

https://github.com/bitcoin/bitcoin/tree/0.12/src
core 0.12: MAX_BLOCK_SIZE = 1000000;
core 0.12: MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
meaning
core 0.12: MAX_BLOCK_SIGOPS = 20000
core 0.12: MAX_STANDARD_TX_SIGOPS = MAX_BLOCK_SIGOPS/5;
meaning
core 0.12: MAX_STANDARD_TX_SIGOPS = 4000;
nothing stops a native tx from sigops spamming, you can only control how much spam is allowed

blockstream just thinks that people using segwit keys is enough defense they have not realised native users will stick to native keys

That is what I am wondering. If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good. Could a native address automatically be a segwit address, negating the need for users to move UTXO's from native keys to segwit keys (which is going to cost a transaction fee and put unnecessary pressure on network capacity)?

nope.

only real defense is keep limit per tx down........................ or blindly think malicious people will move to segwit keys to disarm themselves so everyone is using segwit keys

You still don't understand it. Spamming with native keys after Segwit has been activated is useless. You can't DoS the network with them.

No. The difference between SFSF and SFHF is negligible (aside from hard forks being dangerous without consensus). In order for something like that happen, it would probably require a whole different BIP and approach.

I doubt it. Even the other attempt at fixing malleability with a hard fork called Flextrans (from the Classic dev, i.e. a BTU supporter) doesn't do that.

you can by filling the baseblock.

EG
a block based on v:0.12 fills the 1mb block with sigop tx's totallying 4000 sigops per tx
a block based on v:0.14 fills the 1mb block with sigop tx's totallying 16000 sigops per tx

edit: here is the clincher justdoing 5 tx's uses up the blocks max tx count.. no one else can be added

READ THE CODE. not the sales pitch by blockstreamers on reddit

Is this because it will eventually only be possible to send to a segwit key, or is there some function in the two tier network that the SWSF creates?


So does this mean a soft fork bypasses consensus?


Does flextrans require a new address key type as well?

Maybe we've different opinions here. I believe Bitcoin's value comes mainly from its usability as a value transfer (and later, also value storage) platform for many use cases among many users ("network effect") and its advantage ahead of similar cryptocurrencies ("altcoins"). But that could lead to a long discussion, so here in this thread, let's focus on the block size issue. ;)

Then I would encourage research on that topic - I think it's inevitable at some point to provide "lighter" IBD procedures. Maybe Electrum and other light wallets could serve as objects in such a study.


No! Obviously the goal must be to allow end users running their node on PCs or notebooks. That was only a comment about professional equipment today - because the power of pro-equipment should be reached by consumer-level hardware at most a decade later. (Connectivity/bandwidth is another point, here you're right that mainly the upload bandwidth growth is a major bottleneck).
Let's say 5 years, 10 years maybe is too far away.

(The 20 MB blocks were only an example to show the approximate relation between block size and possible user base, for now, I won't insist on this number)

Are you trying to say that Bitcoin can be DOS'ed at 1 MB now? ::)

No. You can refuse to use Segwit if you do not want to.

No. Soft forks are backwards compatible, therefore mitigating the risk of a network split.

Yes.
It sounded like I was talking to Roger Ver for a second, but okay.

Then encourage it, but don't spread it around like it is trivial until we know for 'sure'.

Noted. My bad.

We also need to determine whether we are talking about a block size in the traditional sense or a post-Segwit 'base + weight' size (as the "new" block size). Which is it?

The 'DoS' doesn't even require a protocol change to nullify. Indeed, there is a natural incentive already in the protocol that ensures it will never become a systemic problem. If large-time-to-verify-blocks ever became A Thing, miners will employ parallel validation. This will ensure that such large-time-to-verify-blocks will be orphaned by faster-to-verify-blocks.

Miners who gravitate to parallel validation will earn more income, and miners who do not employ parallel validation will become bankrupted over time. As will miners who create such DoS blocks.

This is already part of the protocol. No change is needed.

Note that this requires believing that making nodes that currently operate in a trustless manner suddenly dependent upon others for security fits the definition of 'backwards compatible'. I think that definition of 'backwards compatible' is ludicrous. YMMV.

I've asked for a refreshment about 'parallel validation':

something we can agree on.. needing segwit nodes as the 'upstream filters' (gmaxwell own buzzword) is bad for security. plus its not "backward compatible"

i prefer the term backward trimmed(trimmable), or backwards 'filtered' (using gmaxwells word) to make it clearer old nodes are not getting full validatable blockdata
not a perfect term. but atleast its slightly more clearer of what segwit is "offering" compared to the half truths and half promises and word twisting to offset giving a real answer.

The 20 MB I mentioned before were calculated by the straightforward traditional [non-segwit] way. So to compare to my previous calculation, and because unfortunately Segwit is still not active, I would be more interested in the "traditionally-calculated" value. But you can obviously add an estimation for a post-Segwit size.

You almost made me fall for this.. I was too tired to check whether your numbers were true or not myself right away. That '80000' number is the Segwit number, i.e. it is scaled for the 4 MB weight. 80 000/4 = 20 000. Now if you apply 'MAX_BLOCK_SIGOPS_COST/5;' on this number, you get.. 4000.  ::)

I'm not exactly sure how to mitigate the DOS vector in that case. If that was mitigated in some way, I'd say 10 MB upper limit for the next 5 years. I doubt that someone could expect that we'd need more than 30 TPS + all the secondary layer solutions so quickly.

i used 0.12 as an example of how many quadratics were permissible prior to segwit
and
i used 0.14 as an example of how many quadratics were permissible post segwit
prior: 4000
post: 16000

but in actual fact it is not v0.14 =4000 prior segwit its actually still 16,000 prior segwit (for pools using these uptodate versions EG 0.14 today)
check the code

This is my biggest concern about segwit being implemented as a soft fork. All nodes are equal until they are not. If it was implemented as a hard fork, we wouldn't have this two tier network system, if I understand correctly.

Segwit is like any other soft fork before it. Nodes that do not update, do not validate new rules..Alternatively in the HF, nodes that do not update are cut off from the network.

No, you misunderstand this completely. This is absurd. You can create a TX with 20k sigops maximum, you just can't do this with Core. You're confusing policy and consensus rules and you're misread the code. See this for example: https://github.com/bitcoin/bitcoin/pull/8438

admit there is a 2 tiered system. not the word twisting

As soon as you admit to being wrong with your "numbers". We all know that day won't come. ::)

Did any soft fork that came before it create a two tier network system? At least with a hard fork miners will not create segwit blocks until the vast majority of nodes have upgraded. Those who find there nodes unable to sync will upgrade there nodes. With the two tier network system introduced with the SWSF, nodes that have not been upgraded are being filtered data, so they are no longer full nodes. This appears to be a mechanism to bypass full node consensus, if the miners agree to start creating segwit blocks. Miners that do not wish to upgrade find they have too or risk having their blocks orphaned, so are basically forced to upgrade. Please someone correct my misunderstanding, otherwise I have a right to feel rather uncomfortable about this.

this is your mis understanding
the 20k limit (old v0.12) is the BLOCK LIMIT for sigops
the 4000 is the TRANSACTION limit
meaning a malicious spammer can make 5 TX of 4,000 sigops in v0.12 without and FILL THE BLOCKS sigop limit (no more tx's allowed)

the 80k limit (v0.14) is the BLOCK LIMIT for sigops
the 16000 is the TRANSACTION limit
meaning a malicious spammer can make 5 TX of 16,000 sigops in v0.12 without and FILL THE BLOCK sigop limit (no more tx's allowed)

as for your link - https://github.com/bitcoin/bitcoin/pull/8438

meaning they acknowledge they are allowing transactions to be more quadratically used to attack.

they simply think that its not a problem. but lets say in the future. things move forward. if they then made it 32000sigops per tx. and 160,000 per block. still thats 5 tx per block and also because a native malicious user will do it .. the TIME to process 5tx of 32,000 compared to last years 5tx of 4000 will impact...

---

the solution is yes increase BLOCK sigop limits. but dont increase TX sigop limits. keep it low 16,000 maybe but preferably 4000 as a constant barrier against native key malicious quadratic creators.
meaning if it was 80,000 a malicious user has to make 20 tx to fill the blocks 80,000 limit. instead of just 5..
and because its only 4000X20 instead of 16,000X5 the validation time is improved
but they havnt

Well, there is yet another effect which seems rarely discussed. Under The SegWit Omnibus Changeset, there are essentially two classes of bitcoins. Those that have been created by legacy, and those which have been created by SegWit. This is by definition a destruction of fungibility.

How important fungibility is to you is something only you can decide.

OK, 10 MB looks good for me (it would be possible to handle at least 50 million users with that) - and it's also close to Franky's 8 MB. With Segwit, if I understand it well, that transaction capacity (30 tps) would be equivalent to a 2-4 MB limit approximately.

Harding's concern would be founded. But only to the point that all miners would suddenly start performing only zero-transaction block mining. Which of course is ludicrous.

What is not said, is that miners who perform zero-transaction mining do so only until they are able to validate the block that they are mining atop. Once they have validated that block, they modify the block that they are mining to include a load of transactions. They cannot include the load of transactions before validation, because until validated, they have no idea which transactions they need to exclude from the block they are mining. For if they mine a block that includes a transaction that was mined in a previous block, their block would be orphaned for invalidity.

So what would happen with parallel validation under such a scenario?

Miner A is mining at height N. As he is doing so, miner B solves a block that contains a aberrant quadratic-hash-time transaction (let us call this 'ADoS block' (attempted denial of service)) at height N, and propagates it to the network.
Miner A, who implements parallel validation and zero-transaction mining stops mining his height A block. He spawns a thread to start validating the ADoS block at height N. He starts mining a zero-transaction block at height N+1 atop ADoS.
Miner C solves a normal validation time block C at height N and propagates it to the network.
When Miner A receives block C, he spawns another thread to validate block C. He is still mining the zero-transaction block atop ADoS.
A short time thereafter, Miner A finishes validation of block C. ADoS is still not validated. So Miner A builds a new block at height N+1 atop block C, full of transactions, and switches to mining that.
From the perspective of Miner A, he has orphaned Miner B's ADoS block.
Miner A may or may not win round N+1. But statistically, he has a much greater chance to win round N+1 than any other miner that does not perform parallel validation. Indeed, until the ADoS block is fully validated, it is at risk of being orphaned.
The net result is that miners have a natural incentive to operate in this manner, as it assures them a statistical advantage in the case of ADoS blocks. So if Miner A does not win round N+1, another miner that implements parallel validation assuredly will. End result: ADoS is orphaned.

End result: Harding's concern is irrelevant. The quadratic hash time problem solves itself. No change to the protocol needed.

This is a massive issue. Im surprised at the lack of votes so far

'Voting' is pointless. The only 'votes' that matter are tendered by people choosing which code they are running.

I'm 'voting' BU.

Nope. Wrong. You are confusing policy & consensus rules and Segwit. The 80k number is Segwit only. A non-Core client can create a TX with 20k maximum sigops, which is the maximum that the consensus rules allow (not the numbers that you're writing about, e.g. 4k nor 16k).

No. It does not destroy fungibility.

Definitely; everyone is a honest actor in this network and we are all living on a rainbow. ::)

Do you understand that 'fungibility' is the property that no units of a thing have differing characteristics from other units?


Way to make a technical rebuttal, Lauda. You're certainly on your game tonight.

So for you, being part of UTXO vs Segwit UTXO is an adequate characteristic to destroy fungibility? What happens when *all* (in theory) keys are Segwit UTXO? Fungibility suddenly returned?

I've come to realize that it is pointless to event attempt that since you only perceive what you want to. You are going to come to the same conclusion each time, regardless of whether you're wrong or not.

Actually it is. That isn't disputed by most SegWit supporters.

I think you are on the verge of understanding that issue.


OK... sure. I'm quite certain you are unable to poke a hole in my scenario there. Why don't you try? Or even ... why don't you ping Harding with what I posted, and have him see if he can poke holes in it?

Source?

I don't see why it is an issue. I see it as a non-issue, just as you see quadratic validation as a non issue. ::)

It was not worth bothering to be frank[1]; I just quickly went through it and saw your conclusion. I'm not going to be a messenger between you and someone with clearly superior understanding. Find a way to contact him yourself.

---

[1] - Looks like I'm turning into Franky. ::)

I'd like to understand the reason spamming with native keys is useless after segwit activation.

However, it would seem that core is mitigating the problem by putting in restrictive policies right now:

Note: Code from 0.14 branch, not backtracked it to see when it was added - edit checked it is in the 0.13.x branch, so maybe not something new

policy.h


policy.cpp


net_processing.cpp


wallet.cpp


In other words, segwit activation is not needed for the change. It is effective right now. So what does segwit activation bring?

This is quite simple. Take a look:
1) 1 MB (current) -> No DoS risk (quadratic hashing).
2) 2 MB (bare block size increase) -> DoS risk (quadratic hashing).
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).
4) 1 MB post Segwit (implies 100% native keys) -> No DoS risk (quadratic hashing); the same as the first line.

---

I'll check the remainder of your post later today.

1) 1 MB (current) -> lower DoS risk (quadratic hashing).
2) 2 MB (bare block size increase) -> higher DoS risk (quadratic hashing).
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).
4) 1 MB post Segwit (implies 100% native keys) -> lower DoS risk (quadratic hashing); the same as the first line.

Is that a fair FTFY?

Also

5) 2 MB post Segwit (implies 100% native keys) -> higher DoS risk (quadratic hashing) - unless there are plans to limit native key space in blocks

Yes and no. Writing it like that seems rather vague considering that we don't have exact data on it. It would be nice if someone actually did some in-depth research into this and tried to construct the worst kind of TX possible (validation time wise).

As core not done any research on this then? - also check edits above.

No. You still don't understand Segwit. You can not create a 2 MB block using 100% native keys when Segwit is activated. You can only create a 1 MB block if you're using 100% native keys.

I'm saying that you and I don't have adequate data, and no exact data in this thread. There was some article about a block that takes longer than 10 minutes to validate at 2 MB somewhere.

I think I misunderstood the below and thought you was talking about a post segwit block size increase.


So that would be

3) 2 MB estimated effective capacity (1MB transaction block limit) post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

No, that is not the case. Basically the first two points are about a 'base block size increase', and the second one are just pure Segwit as it currently is. You can formulate the points in a better fashion, as long as they stay correct.

So how would you reword point 3? The original version may be open to interpretation which could lead to misunderstanding. Why do you think my wording is not correct?

I did not say it was incorrect. If you want to be even further specific, stop referring to it as 'block size' if you're talking about a scenario in which Segwit is activated. The block size is split into two parameters:
1) 1 MB base.
2) 4 MB weight.

Using simple logic these arguments are nothing to be debated. We cannot deny that segwit came out to the open because it can solve the issue on blocksize. If it cannot help solve the current problems on bitcoin network then they will not propose it. For now instead of debating why not just wait for the consensus to occur so we can enjoy bitcoins without flaw.

So what is the definition of weight, and how does this relate to data storage requirements?

lauda.

take no offense by this..(think of this as a genuine question, requiring your critical thinking cap to be worn)
but are you thinking that a quadratic sigop attack is just about limiting sigops to not cause validation delays when a solved block is relayed.
..
because thats how im reading your thought process on your definition of DoS attack


have you thought about this as a DoS attack:
those limits which you think are defending validation time attack of solved blocks. can actually be used as an attack by filling a block

EG if a block in v.12 only allowed 20ksigops for the block and 4k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.
EG if a block in v.14 only allowed 80ksigops for the block and 16k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.

thus a native key user can with just 5 tx stop other tx's getting in. and thus all segwit promises cant be met.
no boost to blocksize as no segwit tx's adding to the block.

rmember im not talking about delay in validation times of propagation after block is solved. im just talking about filling blocks (mempool attack leaving everyone waiting)

---

so knowing that the segwit 'activation' does nothing to disarm native keys.
meaning
blocks can stay at 1mb. (either with as little as 5 native(sigopsbloatfill) or thousands of natives(databloatfill))
malleation and sigops are not disarmed.

---

so effectively.. what does segwit actually offer that is a real feature that has real 100% guarantee promise

https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179#.mt4mf9jjh

2MB is an action that would "compromise" decentralization and therefore security. and it would be occurring as a result of political pressure rather than technical necessity.

that is not a compromise i am willing to make.

To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

1) Segwit as first measure;
2) adopt DooMAD/Garzik/Upal proposal (10%+ or 10%- voting when conditions are met), modified by adding a "upper limit"
3) for the first year, a 1,5 MB upper base limit (equivalent to ~3 MB maximal "block unit" size, for now)
4) for years 2-5, a 3 MB upper base limit (equivalent to 6-12 MB [worst case] maximal "block unit" size)

all that coded into a single BIP/pull request, to make it attractive for "big blocker" miners to accept it.

(I hope the terminology is OK)

https://rusty.ozlabs.org/?p=522

Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday

3 and 4.. = spoon feeding numbers by devs hard writing the limits and needing users to download new versions (if a dev team even rlease the limit).
if the last 2 years are anything to go by.. forget it.. 2 years SO FAR to debate just getting a 2mb REAL limit even when all devs admit 4-8 is safe so the 2015 2mb compromise was actually ok all along....
we cant keep having these "please dev release a version that has X" debates
and we cant even have users set limit and release to public in their own repo due to "its just a clone of core but not peer reviewed REKT it"

instead
each node could have a speedtest mechanism. it start-point is when it sees a new height block. its end-point is after it has validated and relayed it out.
then over a scale of 2016 blocks it combines the times to get a total score.(recalculated every 2016 blocks) that way it can flag its capability.
thn we can see what is capable

that way the network can know safe capable growth amounts without spoon feeding and 2 year debates.

then below the network limit (capability) upper level:
preference lower level:
also at GUI (options tab) and rpc-console(debug) level.. or even a downloadable .ini file patch USERS can change the settings themselves without needing to recompile each time their independant client. or having to wait for devs to spoonfeed it.
which is adjustable by consensus.

In my opinion segwit should be a hard fork. It's not safe or desirable as a soft fork.
A dynamic base block solution is required that doesn't use arbitrary growth settings or further future block size hard fork debates.
Miners aren't going to create gigantic blocks by midnight, it would be orphaned by the speed of their competitors.
Technology limitations will ultimately decide blocksize growth. Miners are not going to spend 10mins creating a block.
Let a natural market fee market develop between on-chain transactions and off-chain service providers.
The two need implementing at the same time in the same hard fork, or conflict of interest issues could re-occur.

You should research Segwit yourself. I don't plan on rewriting what is already written in a lot of articles. Use Google.

No.

It is 80k sigops ONCE Segwit is activated. It is scaled with the 4 MB weight, so it comes down to the same thing as before Segwit.

It is quite likely that transactions with such a high amount of sigops would be above 100kb; therefore, they'd not be relayed nor mined by any miner using Bitcoin Core (a non standard TX).

Miners can prioritize Segwit transactions (e.g. 20% vs. 80%). Simple solution.

That's not what I was looking for. I wanted to know how you managed to extrapolate the conclusion that "most Segwit supporters" don't dispute that.

This is inadequate data. I'd like to see worst case numbers for every block size (e.g. 1 MB, 2 MB, ... 8 MB). This could be nicely represented in a table.

Without adequate consensus (this being a economic super majority and 95% of the network), it does harm every part of the ecosystem.

I said The SegWit Omnibus Changeset destroys fungibility. I did not say it was an issue. You initially denied the fact that it does ... now you are backtracking to 'not an issue'. Perhaps you should actually think about your claims before you make them.


IOW, you are happy to wallow in your ignorance. ::sigh:: Oh well - it certainly would not be a first.


I don't need to contact him. You are the one that appealed to his supposed authority. Which, if accurately relayed by you in both directions (which may or may not have been the case) displays an incomplete analysis if the scenario.

knowing that ultimately (due to not preventing native key use) segwits only real promise is a fee discount(for the segwit key volunteers)
causes fungibility issues between which tx types cause preference or not(sigop,malle armed+ expensive or disarmed +cheap)

where people will have preference over which type of funds they receive/they prefer to deal with, based on which keys are used.
eg native(starting 1) becomes nasty and segwit(starting 3) becomes 'good money' people will not want to risk funds coming from a 1address

where not only uses start having thier preference but pools do too. where by if you know ur dealing with funds coming from native key may end up taking longer to confirm, or rejected to never confirm if pools start ignoring native keys. etc

aswell as the things jbreher  mentioned

It doesn't look like you entirely understand how the block size works after Segwit. It changes the block size into two parameters, base size and weight (currently 1:4). If you use base size of 2 MB, you can get up to 4 MB worth of Segwit TXs or a maximum of 8 MB(!) in case of extreme multisignature usage. Your 'proposal' needs to be rewritten. A 'upper base limit of 1.5 MB' is actually equivalent to a maximum of 6 MB and not 3 MB.

I don't see how it could possibly be abused (size wise) if you add a maximum yearly growth. The consensus rules would dictate that it can't be increased more than that.

I'm not backtracking on anything. This just shows open-mindedness, unlike what can be said for you and your kind. Money rules I guess.

Parallel validation is so useless that it isn't worth reading through its BIP. It's not about ignorance, it's about time efficiency.

I barely know who the person is. Stop using logical fallacies when you are clearly not adequately educated to properly do so.

It can be seriously abused at Step 1 Lauda, the yearly maximums are a part of the steps subsequent to Step 1

Care to elaborate further on that with an example? I don't think we are on the same page.

https://bitcointalk.org/index.php?topic=1823233.0

Do you have any scientific research to back this up?

Any centralization of mining is power cost, not block size.

It is well known that you could attempt to manipulate it in order to fit a lower amount of TXs. However, I was not talking about this part. I was talking about the other steps. The increase of the 'base size' helps in cases where users (or malicious actors) attempt to use a lot of "native keys". I will respond in that thread as well.

---

I think the system is very hard to game if you set:
1) A lower bound (size which is the absolute minimum when determining the maximum block size).
2) An upper bound (size which is the absolute maximum when determining the maximum block size).
3) Maximum movements per period (up and down).
4) Maximum total growth per year.

However, it may be very hard to gain consensus as this would have a lot of newly 'chosen' parameters.

The steps come in an order, Lauda. The 1st step, bizarrely, comes first.

There's little point in talking about the subsequent steps, if the 1st step is a significant problem in it's own right

So what is your point.. do Segwit and then nothing? That makes nothing better; it makes things actually worse.

You've changed your tune

Explain how Segwit makes "everything" worse

Without the additional steps, it requires a lower number of TXs to cause the 'issue' that you've specified in your own thread.

Yes I took this into account, the ~3 MB estimation is based on estimations (like these (https://bitcoincore.org/en/2016/10/28/segwit-costs/#risks-due-to-larger-blocks) from Core) that with the current transaction pattern the maximum block capacity is calculated to be 1,7-2,2 MB with Segwit. I first went for 2 MB, but as this already in extreme cases can mean 8 MB blocks (which aren't aceptable for many at this moment), I reduced it to 1,5 MB.

But for me, we can also modify the scale by:
1) first year, only Segwit + 1 MB max block size (no modifications)
2) years 2-3, Segwit + 2 MB upper bound (here the voting mechanism would start)
3) years 4-5, Segwit + 3 MB upper bound (absolute worst case with heavy multisig use would mean 12 MB blocks, but mostly about 6-10 MB)

You're mistaken or aren't properly explaining yourself. Segwit as is, has 1 MB base, which can result with ~2.1 MB worth of transactions (with 100% Segwit TXs). However, this also has a potential maximum of creating 4 MB blocks (heavy multisignature usage). In your proposal, a 1.5 MB base has potential to fit ~3MB worth of transactions and a maximum of 6 MB blocks (heavy multisignature usage).

1 MB upper bound of what? The base size? It is best to elaborate as follows:
a) 1 MB base size variable.
b) 2 MB upper bound base size.
c) Weight variable from 4 MB to 8 MB depending on the above.

---

I think the base-to-weight ratio should possibly be reduced if the base were to grow. 8 MB potential would be too much.

Oh, you were too fast to answer, I just had edited the post to clarify a bit ;) I meant that for the first year (or for the first 6 months, if miners insist on it) the proposed voting mechanism would be "on ice" to be able to react to attacks, only Segwit with no modifications of the "base" size. I think for one year these 2-4 MB should be enough.

So the last proposal with correct terminology (I hope so ;) ) should be:

1) first year: only Segwit with the 1 MB base variable and 4 MB weight.
2) years 2-3: Voting mechanism for miners (10%+ or - per difficulty period) is enabled; upper bound base size is 2 MB
3) years 4-5: upper bound base size changes to 3 MB; maybe reduction of base-to-weight ratio, like you proposed.

Yeah, sometimes I can be quite fast.

Okay so for the first year we only use Segwit and the size it brings on its own.

This looks much better now. The next questions are:
1) What exactly decides whether it goes up 10% or down?
2) Why that specific period? I think that once per retarget is too frequent; maybe once per month is better. Someone else may have more input on that.

D'accord to your second proposal, 2016 blocks may be a too small period.

Yes, there should be more input from advanced users. If this discussion here gets stalled, a new thread about the modified proposal in the Development/Technical Discussion section would be the way to go, I think - then I would also contact the autors (Garzik, Upal, DooMAD).

What makes this proposel different from BU if the max block size is defined in specific 'quant' sized jumps nodes / miners could vote for ? Such a quant could have the size of 0.2MB and would be added ( or removed ) if the voting reaches some 75% agreement.

The (auto) voting could be done in same manner as the difficulty is adjusted over a block number period.

This proposal wouldn't have the following issues:

https://www.reddit.com/r/Bitcoin/comments/5z6d56/a_summary_of_bitcoin_unlimiteds_critical_problems/

What I'm thinking is there will never be consensus. Anything offered will get say no more
Then 30% adoption due to fud. Thus bitcoin core is happy. They think of btc as a store of value
(Gold).

Thus stuck.

Other Alt coins will fill the consumer use niche imho.

Seems like bitcoin core's strategy.  Apathy rules. 1mb block is just dandy.

Bitcoin Core has already offered a solution with bigger block, i.e. Segwit. Apparently the market does not want a block size increase or pool owners (e.g. Jihan) are being severely lobbied into doing the opposite.

its not a native block increase!
its only a growth if people use segwit keys and only reaches potential amounts dependant on how much segwit key adoption there is.

stop thinking just segwit activation causes native tx's to have 2mb..

you know this. you have admitted such in different posts/topics. so dont exaggerate it into a native base block increase, when its not.

again its only a 'effective size if X,Y,Z is achieved AFTER activation..
no promises no guarantee's.

this 'effective potential' can be inhibited(prevented) by atleast 5 attack vectors that can stop segwit ever getting any effective increase in tx counts

Stupid comments like this don't help with a compromise.

Apparently someone lacks a brain, and it ain't neither Searing nor I. Segwit is the compromise.

Take away your nonsense somewhere else. Segwit -> Big blocks. Writing long posts won't change that in any way or form.

The SAME can be done with BTU. ::) ::)

nope not the same.
segwit is still limited and dependant on the 1mb base block.
(by this i mean if no segwit key tx's get into the 1mb base.. the 3mb is empty)
Vs
BU,xt,classic, and and other dynamic proposals, grow beyond the 1mb base. meaning its not limited to 1mb thus requires more effort to spam.

EG SEGWIT
fill a baseblock with 1mb of native garbage and the other 3mb of weight are MEANINGLESS (100%native bloat=0% weight occupied)
you seem to forget that the weight is dependant on the base and what can get into the base to then utilise the weight.
segwit just doesnt give real capacity growth unless a few issues are sorted. which it cannot sort because it doesnt stop native attacks.

all it does is disarm segwit volunteers. but those segwit volunteers are still at the mercy of the 1mb base block and native key spammers.
its not like a berlin wall wher ALL segwit data sits in the 3mbweight. and all native sit in the base
segwit need to get into the base to then spread their legs into the weight.

vs BU, classic, xt (and other real-block growth proposals)
2mb baseblock means it requires twice as much effort..

I've already told you that you can easily prioritize Segwit transactions over native ones as a miner.

No. If the sigops limit remains the same, e.g. 20k, it doesn't matter even if the block size is something absurdly large. You just need to hit the sigops threshold.

Let's see what happens when some form of UASF gains popularity with people that don't have all day long to sit around shit talking about this



You can all fuck off with your "2MB" compromise, which has taken less than 12 pages to warp itself into 12MB  ::)

Lauda in particular, you should know better than this by now, which makes me question your intentions towards the whole issue to begin with

I hope you all have sufficient understanding of what "fuck off" means

I'm fine with segwit + 2MB. I do not support transferring more control to miners by giving them a voting mechanism to decide about the future rules. Some of them currently show us their malicious behavior. We should not reward this by giving them more control.

Which is not what's being proposed

The problem with that is, as Todd mentioned, that there is no safe & ready implementation in addition to the uncertainity of the safety of the idea itself. The concept is interesting though.

A potential maximum of 12 MB weighted in 5 years is much different from 12 MB right now. Even then, the weight ratio should be adjusted to lower the total maximum.

Stop attacking my character. I was always pro :Segwit -> proper HF. I've been saying this for a long time. The primary problem for me is the lack of a proper proposal (e.g. Luke-jr's is bad, emergent consensus is a disaster).

Your behaviour is being attacked, not your character (seriously, you're now reaching for the bed-wetting "ad-hom" rhetoric)


You've consistently excluded any interest in suddenly changing your mind to "on-chain scaling works", if you said it, it was 1% of your total output for several YEARS , and you've certainly never said "on-chain scaling works", even if you did express an interest in "2MB only".

Now, you're here using all the trust and confidence others might have placed in you to push for the opposite of what you used to say, and this has been 75% of your output in JUST A FEW DAYS. Are you hoping that no-one would notice the huge, gaping contradiction?  ::)



Now, that's a sudden change in your behaviour, not your character, your character was clearly always prone to hypocrisy and conceit.

And it's sold now as the compromise coin.

Choose between bad (do nothing) and evil (HF) ....


I really wonder who should go long that - just B Banks ?

No, that is not the case with a SF.

My bad; still sub optimal at this time of day.

Saying that X MB is acceptable in Y time frame != aon-chain scaling works. I haven't claimed this to be the case either.

And there it is. Is this your way of handling things when someone has a different stance on a matter?

You're wriggling Lauda, visibly


Saying "X MB is acceptable in Y time frame" == saying on-chain scaling works


Go on, try again. See if Franky's strategies work for you, repeat your logical fallacy again and again and again



Proving them wrong? Why yes, when they are wrong, that's what one does



My assessment proves that you have built up trust in the long term, then used up all of that trust in a couple of days to sell a contradiction.

Problem?

Following your own logic, by supporting Segwit (2/4MB maximum) you are stating the same, i.e. saying on-chain scaling works. Sigh.

You can do that without attacking character/behavior or whatever.

Untrue. I am not selling anything. Bitcoin Core roadmap has a dynamic block size/flexcaps down the road AFAIK.

More Franky style lying by omission


You know full well that's not my position, I don't think Segwit's 4MB is sensible either. And you know that, hence you are dishonest


And now the actual ad-hom. I am saying things about you that are relevant to the issue, and which are also true


We are all selling, Lauda, every minute of every day. Only the dishonest deny it, even if they are primarily lying to themselves

Should I rename myself to Franky2? ::)

So your position is what exactly, 2 MB (Segwit) and layer 2 only?

I'd accept 4MB Segwit (which is the actual proposal), or less increase than that. And of course, the only purpose of that is in reality to enable 2nd layers, yes.


Because only 2nd layers provide any meaningful scaling paradigm

So, assuming technology allows us a certain size on-chain post-Segwit, you still wouldn't accept any kind of increase (regardless of BIP, author, implementation)?

Still wondering how much time it takes to understand that economically it does not make any sense promoting (also to miners)

infinite scaling in 2nd layers  (poor investment needed + bit of code hack, try to earn lot of fees / steel from miners)


AND


limiting miners business to 1MB ( high investment by miners DONE)



All we see is just reactions on this (miners awake and do their analysis)  -> a swing back is just natural to that.



Now you need to offer really more to miners or you've lost this battle.

You're attempting a false premise right off the bat


There is no guarantee that internet infrastructure will be sufficiently capable to deal with on-chain scaling to begin with.

Instead of designing changes around a medium or best case scenario that hasn't happened yet, we should plan for the worst case scenario instead


You're making a super huge assumption that global internet connectivity does not deteriorate over the next 5 years of your "scaling" plan


What happens if the global internet infrastructure deteriorates in bandwidth or connectivity over that timeframe? ::)

What happens if the global electricity infrastructure deteriorates so much that mining by PoW will not be possible any more ?

I would say that if global internet infrastructure deteriorates so much, that we probably have MUCH MUCH bigger problems to handle than caring about a crypto currency on the internet.  Maybe, finding a gun and defend ourselves, and trying to find food or something.  Mad Max style things.

Crypto currencies are a side product of high network connectivity, cheap computing and sufficient electricity.

The problem with block chain based crypto currencies is that they start from some most probably erroneous principles.  Full trustlessness is very, very hard to implement, and the price to pay is way, way too high for a real-world situation where partial trust is often a good investment.   Block chain based crypto currencies, writing all transactions on a global ledger, are extremely wasteful on computing, storing, and network resources ; but as these resources grow over time, and as adoption of these crypto currencies is NOT THAT IMPORTANT, there is a natural throttling of the adoption by the technological cost.  What is strange, is to limit this resource artificially with block limits, instead of having the resource price be a natural limit.

Block chain based crypto currencies will never equal fiat style payment systems, because the investment in trust in these fiat payment systems allows for HUGE advantages in terms of capacity.  The price that block chain based crypto currencies pay, is that they try to adhere to full trustlessness, which is too high a price to pay to compete with trusted systems. 

This is like driving to your work in a fully blinded tank, with all reserve food to be able to sustain all kinds of attacks: for sure, your system is more "secure", but the resources wasted on that are so big, that you are not competitive as compared to the guy taking his bike.  Your costs in terms of maintenance, consumption, capital cost etc for your tank are so big, that you waste all the money you win in going to work in the first place.   The guy on the bike takes the risk of being shot down, true, but at least, he's way, way more competitive in earning money than you are. 

Block chain based crypto currencies are over-protected by trustlessness, and hence, are not competitive with fiat systems.

Of course, you can transform block chain based crypto into less trustless "banking systems" on top of them.  That is more or less what the LN tries to do.  You will get a network of LN banks (big hubs where you have "an account", that is to say, a small-user payment channel).

Yes, you can build faster and lighter structures on top of bitcoin.  By giving up trustlessness.  And building a fiat system.

My idea is that the only use of crypto currencies are those niches where fiat doesn't work.  Those niches are not that important, and advances in technology will push the limits of what crypto currencies can handle to a level where most of those niches are addressed.  In other words, the relative scarcity of adoption that crypto currencies allow will be taken by the most useful niches that need it.

And all the rest will be done by fiat.  I don't see the use of building another fiat system on top of bitcoin: we already have that.  Let crypto currencies exist for those niches where you can't do it with fiat.

And then, one day we will invent better systems than block chains.  That day may not be far away. 

Not realistic


Deterioration or outright paradigm change of the global internet is very plausible. Get a grip










@Lauda, did you stop talking when I proved you thoroughly wrong, only to leave an opening for Mr. Walls-of-text to disrupt the thread?

Deterioration in internet capacity. Possible. Netflix is in trouble, dump your shares. Better make your way down to the bank branch to find out it has been closed due to online banking use.

Yes, and the "Mad Max" hyperbole is nonsense, something closer to Brave New World or Terry Gilliam's Brazil IMO (Terry Gilliam's Brazil is pretty close to reality even now)

Ah, yes, sure.   Then we agree.  But then you can forget about "decentralized" in any case.  And then, in any case, your worries will be of a different type than caring for a crypto currency. 

If the hardware or software is not ready, the miners will not use the bigger block size. So the size increase will slow even though the limit is high.

A question that has no useful purpose Lauda, hence it being derided as falsely premised


Why are we talking about fantasy scenarios, exactly? You may as well ask what my position would be if all 7 billion humans receive 1 Gbit/s connections and quantum computers free of charge next week


Good point. Now you're starting to get it; if internet resources became seriously inhibited, 4MB could be crippling to Bitcoin. It's not the such a great compromise when you consider that possibility

My grandma told me to learn to calculate with paper and pensil, because if all pocket calculators would one day fail I could still do my sums with paper and pencil.

Assuming the Bitcoin network would be able to handle 1.5 MB base + 6 MB weight is a fantasy scenario now? I think you're in the wrong thread.

Why stop there? 1 MB might be way too much as well. I don't like this argument one bit.

I'm going to invest in a factory that makes 56kbit line modems.

So that's what you would you do if such a situation occurred? Complain directly to reality itself?

I know you don't like the argument, that's why you're trying to wish it away. But political developments of all sorts could cause such drastic things to take place, and who knows how long for, and that's not at all implausible. The worst aspect is exactly how uncertain we can be about the severity or duration of such a possibility. But 12MB blocks though, right?

What is the actual basis of your argument for any of this, all you've done is this thread is jump on the linear x=y big blocks bandwagon without providing any reasoning as to what the purpose of the big blocks will be. Don't say scaling, lol

Suggestion to OP: Close this thread, start a self-moderated one with a more exact approach to the proposal. This is the only way to filter out the noise if you only want to discuss the proposal and its implications.

I'm prepping Enigma 2.0. ::)

You don't want people discussing the proposal unless it's to sing it's fallacious glories? I am discussing the proposal and it's implications, it appears you just prefer the most optimistic scenario possible, which of course is engineering suicide.

And you have zero argument, only mockery? I see

That kind of argument is a fallacy (I think it is called "fallacy of catastrophic expectations"), because, even though unlikely, the hypothesis is not impossible, the hypothesis makes that the problem at hand is not an important problem any more.

This is like "one shouldn't put a roof on a house, because when there's a meteor impact like the one that killed the dinosaurs, the roof will not resist".  If there's a meteor impact like the one that killed the dinosaurs, the problem of the solidity of your roof is not a problem worthy of attention any more.

If society is so fucked up, by technical or political reasons, that computing and internet connectivity falls drastically backwards, "crypto currencies" are not something to worry about any more. (trying to survive from the dictatorship or trying to find food, is).

No, you're exaggerating

Good engineering practice involves planning for marginal cases, and what I presented represents a LIKELY possibility, not the HIGHLY UNLIKELY scenario you used. Please use rational arguments, not hyperbole.

You think that it is likely that in the coming years, internet capacity goes down ?   Without some big cataclysm ?  Seriously ?

Not following geoplitics then I take it?

No cataclysms, super-giant meteorites or alien invasions necessary: all it could take would be something like the Philipino president or the North Korean president provoking a serious conflict with the US. That sort of thing happens constantly, the US establishment is always "policing" states that present them with an opportunity to do so.

The danger is that China would step in to help. And that's a very real danger; the South China Sea is strategically prized by the Chinese government, they already have an independent dispute both with the Japanese and the US over the various islands in that area.

And guess what strategic assets traverse the sea bed of the South China Sea and in the Pacific Ocean surrounding the Philipines? And no, it's not shapeshifting lizard creatures from outer space

america are hating china.. not because there is some chinese guy sleeping on the american peoples door steps. but because america has been watching too much fox news.

while we had the "everyone hate russia" moment for the last decade.. america was actually doing trade deals with russia.. literally giving russia the front door key to the international space station and a taxi licence to charge americans to be taken to the door and open the door for america to access the space station.

you can buy apple iphones, mcdonalds, and thousands of other american things all in russia.. all while fox news was spewing out to hate russia..

bringing politics back on topic:

and now we have core who gave the pools the vote and bypass node consensus. core changed the fee estimation, relay and allowance lines of code..
but good old coindesk (barry silbert: DGC: blockstream) is using the media band wagon to try swaying people to blame china for bitcoin issues...

never accept what has been spoonfed for you by script writers. even if 100 people repeat it.. instead do you own research.
blockstream changed the fee mechanisms, blockstream changed who gets to vote. but blockstream didnt expect 50% undecided resistance and 25% opposition. they thought it was a easy domination with soft strokes of peoples asses.. but now realise they didnt get it soo easy.. so now they wanna ram the ban hammer hard and blame it all on the pools or other nodes for causing a split..
either playing the victim card of the fake first strike defense tactic as a way to stroke asses to pretend they are protecting bitcoin when really its about gaining domination of bitcoin.

if anyone dares reply that they want to avoid consensus and happy to have blockstream control it and no one else can or shoot keep them on their toes... then just reply "centralising is ok"

My slide rule doesn't need batteries.

I don't think it is very fast at hashing though...

@Carlton Banks: Well, then we in South America take over Bitcoin. We've resolved the last conflict on our continent and you can all die, but Bitcoin will survive ;)

Seriously, the Internet is decentralized, there will be a network ready to manage 12 MB blocks. Mesh wi-fi networks also could be a solution. And even if a extremely catastrophic event causes the Bitcoin network to stop processing blocks for a while, then we eventually could start it again.

@Lauda: I have thought about starting a new thread. For now, I'll wait a bit more and see, because I'm reading currently a bit about Bitcoin's consensus and how one could avoid miners given too much power, so my conclusions could be discussed in the new thread. Here, for example, I discussed a possible counter-measure (https://bitcointalk.org/index.php?topic=1799036) (proposed by another user in the German language forum) in case miners ignore completely the majority's wishes - it shares the "spirit" of UASF.

Is it me, or does that sound incredibly reckless? Don't you understand how fragmented and bottlenecked a widespread mesh-net could be if it wasn't very carefully planned and diligently protected? I'm in favour of that kind of solution, but your casual description is not capturing the full extent of the problem, a successful neighbourhood or town level mesh-net is a whole different ball game to covering an entire land mass with interconnected mesh nets. How are we going to use mesh nets to cross the oceans? (which was the crux of my point anyway)

And what is your ACTUAL RATIONALE for wanting 12 MB blocks? I've not seen anything in this thread that isn't a circular argument

Some people just want more on-chain capacity and secondary layer solutions. As I've mentioned earlier, it is quite possible that Bitcoin Core will go in the direction of a dynamic block size or flex caps (unless the individuals silently changed their opinions on this), see here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

It's very, very difficult to imagine an event like you're pointing out (e.g. where most of all trans-oceanic cables are broken). It's even more difficult to imagine that the Bitcoin transaction volume would stay as high as before the catastrophe. So even if all what you imagine comes true, block size would be almost for sure much smaller (and block propagation temporarily faster). But I don't want to profundize here as I consider that event highly improbable.


If we really want mass adoption (>1 billion users), we would need >12 MB blocks even to enable LN users to open one payment channel per year. And LN needs to enable its users to close the channels when they need it (one on-chain transaction more per user), because otherwise the counterparty could steal the money. Imagine if a hub tries to steal Bitcoins from their users. We would have instantly millions of unconfirmed transactions because of all users wanting to close their channels.

So your "maximum of 4 MB" would mean Bitcoin user base being capped permanently at about 50 million users, even if all the transactions were done in a second layer/off chain manner.

As already said, I don't want 12 MB now, but a gradual plan to move towards possible mass adoption.

It would help your credibility a great deal if you weren't putting massively exaggerated words in my mouth. I specifically did not say "most or all" trans-oceanic cables are at risk of breaking, I gave a specific (and HIGHLY PLAUSIBLE) political scenario where some important cables could be broken. Your arguments are still circular, you proved me wrong by saying "it's improbable, because I say it's improbable"

Again, why are you planning for optimistic scenarios when we're supposed to be treating this like an actual engineering problem, where that approach FREQUENTLY AND DEMONSTRATIVELY LEADS TO FAILURES NO-ONE FORESAW. Where is your safety margin?


Your imagination for transaction rate increases seems strangely limited to the block size only, considering I asked for an ACTUAL RATIONALE.


Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork

Why not explore the possibility of decreasing the block interval target FIRST, which is also a hard fork

Why not explore the possibility of separating tx and coinbase blocks (and making the tx block interval more frequent) FIRST, which is also a hard fork

Why not do everything that isn't the most dangerous option FIRST?


With some combination of ALTERNATIVES, WHICH EXIST, the x3 increase in tx rate from 4MB could achieve the same exact effect that your inherently more dangerous suggestion does. Why not play it safe, like an ACTUAL ENGINEER. It's only a highly important development in human progress, after all

Is it more circular than your argument "I think it's plausible, so it's plausible?"


I haven't said that I'm against an alternative to an increase of block size and I think it's good that you mention them. If these alternatives exist and are capable of solving the problem, why aren't they more thoroughly discussed in the scalability debate? (Serious question.)


These two look interesting. What is the combined potential, in transaction capacity per MB, of these two measures? (Is the second one Bitcoin-NG? Why was it not explored?)

That one will be most probably been rejected by most of the community because it modifies the original reward schedule and has its own dangers (more orphans). And it would not solve the problem of a large blockchain (that also applies to the Bitcoin-NG proposal), but could improve the propagation and validation of individual blocks.

Edit: Don't forget that the original intention of the proposals we're discussing here is to achieve approval for Segwit by miners of the "big blockers" fraction to get rid of the stalemate. I for myself, for now, would be perfectly happy with Segwit alone for now and then let the Core devs decide further scaling measures.

Internet was originally designed to withstand a Nuclear War.

However advancements in technology are such that a Targeted EMP Pulse designed to destroy an entire Country Electronic infrastructure is not out of reason.

So lets say China uses one on the US,
what happens their is no electricity , no internet , hell, Fiat is not even worth a damn, so who will give a shit about BTC.

However if you save your private keys on paper and can escape the aftermath to a friendly country and are not killed on site for being an american.
Then you can renter this other country and use BTC , because the rest of the world was left untouched and continue living and BTC continued normally.

However the US has safeguards in place to prevent an EMP pulse from China or anyone else, even from that little space weapon they think the US does not know about.  ;)
http://www.screenused.com/images/ap2/AUSTIN_POWERS_2-small.jpg



The Odds of BTC dying from being not being able to process a transaction or the price of processing a transaction is a Bigger Direct Threat to BTC that what you are worried about CB.  ;)

Good Book on EMP , is One Second After by William R. Forstchen .


 8)

FYI:
If only this magical bandwidth issue that keeps you you at night,
the easy solution is this, when large blocks start causing too many orphans problems.
Decrease the size of the blocks and move to a faster block speed.  ;)
ie: https://bitcointalk.org/index.php?topic=1827943.msg18206691#msg18206691

 

The 2nd strawman argument that you've made against me.


My argument is that diplomatic tension is rising between the states that adjoin the South China Sea. One of those states (Phillipines) has switched allegiances from one major military superpower (US) to another (China) just recently. The president of The Phillipines has denounced international organisations strongly (threatening to burn the UN assembly building to the ground, for instance), and is being investigated by the International Criminal Court for crimes against humanity.

Separately, the US, China and Japan are all having a stand off between one another over disputed islands right in the middle of the exact same region.

And if that wasn't enough, one highly unpredictable, volatile nuclear armed state (North Korea) is exhibiting increasingly bellicose rhetoric towards ALL parties.

If that doesn't sound like a plausible tinderbox ready to catch fire, I don't know what sort of scenario you would actually consider potentially dangerous. It's a serious threat, and it's only 1 out of many possible serious threats. It's likely there are even threats to the internet's operation that no-one could have imagined, hence my focus on margins of safety and risk analysis.


Now, how is any of that either implausible or a circular argument




If you're actually interested in responsible scaling, maybe you could investigate them too? But I doubt that you are, you've spent far too long defending your entrenched and dogmatic position, when you don't really have any good arguments to support it.



Which part of "explore the possibility" do you not understand?

The orphan rate has been improved vastly now we're at version 0.13 - 0.14. The amount of slack that frees up COULD be used to safely reduce the block interval, but that would have to be proven on a test network before any proposal could even be made.


And maybe you have something to remember; Segwit itself is a blocksize increase, of 4x. A 4x increase is NOT to be underestimated in impact, increasing resource use by a factor of 4 is very large for a peer 2 peer network.

Segwit => DeadWIT

Miners will never allow it to activate,

If you know anyone dumb enough to work and send their paychecks to someone else.
Because that is what you are asking the miners to do.


 8)

OK. I don't believe it will happen, but let's explore the possibility. Which cables - apart from some regional connections - are threatened by that possible conflict? The rest of the world is pretty well connected. If the Philippines, because of the "intelligence" of their president, are temporarily disconnected, the rest of the world would not even notice. Seriously threatening the connectivity of China and the rest of East Asia will be a LOT more difficult, there must be a >WW2-like scenario for it. And even then the rest of the world could continue to use Bitcoin.

And: What problem do you see arising? Block propagation or IBD? If it's the first one - I seriously don't believe that a 12 MB data packet every 10 minutes or so is too much for even a low-bandwidth connection of today's standards. And we are talking about >4 years from now and about the absolute worst case - if a large part of the transactions were multisig, for example.


Where is your answer to this question? You're trying to trick me into a rhetoric labyrinth to sustain your maximalist position.


Hey, stop a bit. I'm discussing various possibilities here and even gave you room to explain your favoured alternatives, but all you say to me is "investigate yourself". You have brought in the proposals, so please point me to the relevant discussions. Don't forget this sentence:


The "dogmatic positions" are actually BU and Segwit/1MB maximalism, not the exploration of a compromise!


That's why the last proposal is gradual and has a grace period where the base size would not be changed for one year, so if there was an actual danger the code change can be reverted. The 12 MB would only be possible after 4 years - 4 years where the developers at every time could revert the change if there is a catastrophic scenario which makes impossible such a high block size.

And it's NOT a final proposal, it's only the result of the discussion of some users in this thread. It can be changed.

Regarding your recent mention of reducing the block generation time, I asked on IRC. Apparently even with all the relay improvements, they are not adequate to reduce the generation time safely to e.g. 5 minutes claimed Maxwell. There were a few more people giving their opinion at the time, but I forgot to save a copy of the chat. This is quite unfortunate though, I'd definitely like to see 2017 data for this kind of expertiment. Maybe a testnet with constantly full 1 MB blocks and 5 min block interval.

Thx for doing this. To me a 5min interval (halving the reward) would be a sign of flexibility and step into right direction. It would also reduce waiting time - win win.

I do not really understand why this is a real issue since we see some bigger shit coins work mostly ok with less time.... Hmmm

You're shifting the argument, and it's dishonest

My point is not to argue the finer details of whether this scenario or that scenario is sufficiently problematic to cause impact X on the network.

What I'm saying (and which you did not address) more broadly is that there are multiple possible situations like the scenario I presented that are becoming more likely because of the rising trend of polarised diplomatic relationships between strategically important states, all over the world.


Lie to us, tell us that polarised diplomacy between major states doesn't carry the serious threat of conflicts that could disrupt the internet very badly




I am not sure how much can be achieved using those on-chain scaling methods, but that wasn't the point. I'm proving that different ways to scale exist that do not carry the dangers that blocksize increases do, and that also constitute actual scaling, instead of just using more resources at the same scale.


Again: the sensible engineering approach for a peer-to-peer network is to use sensible margins of safety and precaution, IN PARTICULAR when it comes to the resources the network needs to operate



Prove it.

I'm suggesting, without stating opinions as fact, that Segwit's 4MB IS the compromise solution. You're just using circular reasoning, yet again.




You're not getting the broader point here: there are several ways (and likely several more we haven't thought of) that could be employed to get that kind of transaction density with 4MB Segwit blocks, bigger than that is unnecessary when there are other options.

You're just desperate to keep the conversation on the track of "bigger blocks = only method to increase tx rate possible", when it's demonstrably provable that it's the WORST WAY TO ACHIEVE THAT because it carries the MOST SIGNIFICANT RISKS WHEN DEALING WITH PEER TO PEER NETWORKS.



Please, respond to the actually argument I'm making, not derailing back into defending x=y linear growth in blocksize. It's indefensible, when the same rate of growth could be achieved a less dangerous way, using actual scaling paradigms that multiply the utility of EXISTING CAPACITY, not adding extra burden to the capacity at the same scale.

You didn't prove anything still, you only mentioned very vague points, that could be interesting but are not very thoroughly discussed in the actual debate. So if you want to continue this discussion (otherwise, I'm out), then please link me to sources that prove that these are real possibilities to achieve a significantly higher  transaction capacity.

And you seem to have STILL not read the following sentence:



That's called maximalism. It's one of the two extremes of the positions in the actual debate (if we exclude Luke-Jr with his 300 kB blocks). Even many Core devs are open to block size increases after Segwit. Addition: Remember the Hong Kong Consensus?


Again: More precision please. We aren't advancing here. I, for myself, would be perfectly well with a solution like that:

- Segwit
- 50% TX density improvement by better encoding
- Block time reduced to 5 minutes (again, I would be in favour, but I don't think it will come)
- 1 MB base / 4 MB weight.


I'm interested in LN and sidechains like Rootstock, but I have already pointed out that even with a well-functioning LN we need more on-chain capacity. If the solutions you mention (TX encoding, block time) are providing them, then why don't you link me to the relevant discussions of it?

But again, you're missing the point (read the bold sentence again!). The goal was to achieve a solution that could be supported by the hardcore BU miners AND Segwit supporters. I think we've already failed anyway. Fork will come, because of maximalists on both sides (you are one of them, it seems), and it won't be good for Bitcoin. (It won't kill it, though).

I have. Have you?

I don't think you understand the politics here: the inconsistencies in the position of the miners blocking Segwit/promoting BU are obvious; they're saying "but we want big blocks!" when they're being offered big blocks. It's a bit like the way you're arguing, really ::)

The obstructionist miners are doing so to add to the conflict, they're not interested in being constructive, it's incredibly transparent that's their intention, to those that aren't completely naive of course



gmaxwell posted on Bitcointalk about the tx encoding efficiency hard fork a few weeks ago. He mentioned a factor of improvement, why aren't you motivated to find out for yourself what it is, instead of taking a demonstrably controversial, fruitless and very naive route?

Again, if you're really interested in actual scaling paradigms and not dangerous non-scaling resource use increases, you would be sufficiently motivated to look for yourself.

I've read it and don't need to read it again. You sound interested, so what's the problem? Are you interested and motivated, or not?



And AGAIN please, respond to the actually argument I'm making, not derailing back into arguments defending x=y linear growth in blocksize. Using actual scaling paradigms that multiply the utility of EXISTING CAPACITY is far more valuable and sensible than your idea of adding extra burden to the capacity at the same scale.

So your position is basically: The miners are totally wrong. So let's ignore the miners. Not very constructive.

I'm not saying that block size is the only way and not even the best way to go, that is an invention of yours, so your last phrase is totally dishonest and wrong. I've only said that in the actual conditions (~3 tps at 1MB blocks) a Segwit + 1 base/4 weight MB capacity very probably won't be enough in five years, even with LN and sidechains, if we really want mass adoption (> 50 million users).

I don't care if a transaction capacity increase is achieved with bigger blocks or other measures. So I'll investigate Gmaxwell's transaction encoding proposal but it's not easy to find. So really, if you are interested in continuing a constructive discussion, please provide me a source.

The "smaller block interval" proposals (with coinbase blocks separated or not), anyway, only would improve one side of the scaling problems: block propagation. IBD and storage space would not be affected.

TestNet was called Litecoin at 2½ minutes and multiple alts.
G.Maxwell is blowing smoke, if BTC can't do your 5 minute block speed then the whole thing should be scrapped and written from scratch.
(maybe copy litecoin source code that has 4X the transaction capacity of BTC without deadwit.)

What lie did he make up to explain why BTC sucks more than every other coin in existence in regards to blockspeed?

 8)

FYI:
Have you Noticed that BTC is unable to do anything else to fix transactions capacity issues except segwit if you talk to G.Maxwell.
Answer is simple , Talk to someone that won't lie to you.  ;)

You're a dirty little exaggerater when you have no real argument, huh

I said nothing of the sort. SOME of the miners are behaving irresponsibly as they are not respecting what their actual responsibilities are. Bitcoin 13.1 was the Segwit soft fork implementation only, and the users overwhelmingly demonstrated they are ready for it and supportive of it, even now 13.1 is actually more numerous on the network than the release that came immediately after it.


DON"T YOU DARE SUGGEST I'M DOING SOMETHING WRONG BY POINTING THAT OUT. You're a disgrace, the sort of fool who will not back down in an argument beacuse of your precious little ego.

You're wrong, you're suggesting something staggeringly foolish and I will not be brow-beaten by someone who cannot swallow their misplaced pride on such an important issue




Dedicating a huge thread, labelled as BIP 102, but is actually BIP 102 on Schwarzenegger doses of steroids SURE AS HELL DOES LOOK LIKE SOMEONE PUSHING BIGGER BLOCKS AT ANY COST.

If you're not dismissing on-chain scaling improvements in favour of just flat-out increasing the resources the Bitcoin network needs to run, then why are you:

• Dismissing on-chain scaling improvements
• Heavily promoting increases in the resources the Bitcoin network needs to run

Well, you could've fooled me.



NO.

I don't want to hear another word from you or anyone else about blocksizes until you can demonstrate that you've investigated anything else but, and that you understand it's the worst and most dangerous way to increase capacity, and most of all that it DOES NOT CONSTITUTE A SCALING PARADIGM AT ALL. There's not much point in trying to argue otherwise, it's an incontrovertible fact.

If you don't want to hear it then you're probably in the wrong thread.  Feel free to join another discussion more befitting to your hardline sensitivities.  

Or better yet, maybe learn how human interaction works and think before you bark.  Most people are on board with SegWit, but many are still concerned what comes after that.  Even if you can't accept the fact that not everyone wants to be pressured into using Lightning, or whatever off-chain solution ends up being proposed, you should still get used to the fact that they're going to keep talking about the blocksize, because it's not going away.  I think it's highly unlikely that the pressure will dissipate in that regard.  People see this arbitrary and temporary bottleneck which wasn't part of the original design, so it's hardly unreasonable to question it (despite your obvious opinion to the contrary).

So what you have to consider is, the more you tell people not to discuss it, the more you isolate yourself and make people think there's no point engaging with you, when all you're going to do is tell them how wrong they are because they don't see things as you do.  I'll phrase it as politely as I can here, but you don't exactly have a winning personality.  Maybe you feel like you've justified your view enough in the past and you're just repeating yourself at this point.  But whatever your reasons are, if you can't even be bothered to explain why you think anyone who wants to look at the blocksize is basically the devil, and just scream at people that they're wrong, you're not going to win many people over.

Just a suggestion.  But if you like being seen as the mindless attack dog, keep up the sterling work!   ::)

i do have to say this...

though litecoin and other coins may have lower blocktimes.. they also have lower node counts (~700ish active nodes).

once you start thinking of the time to download, verify and then send out a block. .. the more nodes there are, the more 'hops' each relay layer of nodes needs to do. and the more total time needed for the entir network to get the block before it should be happily ready to get the next block

EG
imagine a coin with just 8 nodes..
one node can send a block to all 8 nodes in 1 hop

but imagine there were say over 4000 nodes

=1*8*8*8*8
=1+8+64+512+4096=4681
thats 4 hops to gt to all 4000 nodes (bitcoin needs about 5 relays/hops due to having ~7000ish)

now thats 4 times the time it takes for everyone on the network to get and verify the block before the next blockheight gets sent.

reducing the time between the next block height means less time for the previous block height to get around and everyone agree on it. which can lead to more orphans if some have not got the data to agree on block X+2 if they have not even got x+1 yet

---

based on say a download, verify and relay out to all 8 peers takes less than 30 seconds...EVER
in a network of say 9 nodes (1pool node and 8 verifying nodes) you could get away with blocks being built every 30 seconds and have nice wiggle room
in a network of say 73 nodes (1pool node and 72 verifying nodes) you could get away with blocks being built every 60 seconds and have nice wiggle room
in a network of say 585 nodes (1pool node and 584 verifying nodes) you could get away with blocks being built every 1min30 seconds and have nice wiggle room
in a network of say 4681 nodes (1pool node and 4680 verifying nodes) you could get away with blocks being built every 2min and have nice wiggle room
in a network of say 37449 nodes (1pool node and 37448 verifying nodes) you could get away with blocks being built every 2min 30seconds and have nice wiggle room

but thats on the bases of download, verify and relay out to all 8 peers takes less than 30 seconds...EVER
if the average propagation was say 1minute. then suddenly bitcoin wouldnt cope with 5min blocks..
if the average propagation was say 2minute. then suddenly bitcoin wouldnt cope with 10min blocks..

so its a cat and mouse game between propagation times. node counts.

yep its not just about blocksize harming node counts. its also node counts can cause delays and orphan risks to blocks (but at just 1mb it would take a hell of alot of nodes to do that)

There is one situation in particular where I reserve the right to be belligerent; when people are doing something dangerous

.

Play the ball, not the man. Any personal criticism coming from me relates specifically to your behaviour in this thread, not wholesale attacks on character.


And you STILL have yet to provide actual reasoning for your x=y linear blocksize growth proposal, you still have yet to provide logical refutations to my insistence that blocksize should be the last resort, not the first.

You're the bad actor here, you cannot accept that you are wrong, and have only unbacked assertions to prosecute your position, what you're suggesting is bad engineering practice, and actual engineers know this full well. You have presented zero evidence to the contrary, and are only continuing because your pride is hurt, otherwise you would accept reasonable reasoning. Instead you try to discuss anything but the points I have raised.

You're campaigning on blocksize for it's own sake only, deaf and blind to any alternative, which exist. You are the bad actor, the poor debater, the intransigent. To attack me because of your own panoply of short comings is a total disgrace, you have no place debating any technical matters whatsoever.

Consider the pool installing a node that can have 20 000 outgoing connections.  Like a small data center.

All non-mining nodes connect directly to this one.  Like you connect to Facebook's servers.

You scream: decentralisation !  But you have in any case only one single data source: your single pool. No other entity is making a block chain.  So you can just as well connect to your single source of data.

In your story, replace 1 pool by 10 pools.  Well, any of these pools is a reliable source of data, and ONLY these 10 pools are the source of their (common) block chain.  There's no other source.  If they hold it back, they are hurting themselves.  EACH of these pools can serve all the other nodes.  Nodes can chose which node(s) they want to connect to.  No need to connect to proxy nodes. 

@Carlton Banks: You have just demonstrated that you are the wrong person to discuss about a "compromise". You haven't brought in anything constructive into the discussion, only destructive ad hominem, so I will ignore your input from here on. You never proved NOTHING.

So don't blame me and others trying to find a intermediate position if the fork comes and Bitcoin's eternally split. This thread is an intent to avoid a fork. I know that some from the hardcore-Core (;) ) fraction is totally OK with a fork, but it could harm Bitcoin seriously - If you don't see that, it's not my problem. I can also switch to an altcoin then, as I'm currency-agnostic.

no
id scream centralisation..
one source one brand.. is still centralisation.
in other topics and for many months and years i have said.. distributed centralisation is NOT decentralisation..
a network of only core, whether it be 3000 nodes, 8000 or 80000 is meaningless if all the code was the same. especially if a bug popped up, they would all be affected.
however.
diversity(different code bases and even wrote in different languages (go, ruby, java, c#))  and more than one option is decentralisation..

i would rather there be 10 different codebases for node users to freely choose. not 2 and not 1
core wanting domination and also wanting the fibre ring fencing the pools as the upper upstream filter.. is not about decentralisation.. just distributing.. but still centralising..

d5000, you have the same problem as all dishonest debaters trying to throw up smokescreens and diversions to cover their tracks:


People only need to read the posts to see that you were being evasive and squirming, and I was being direct and clearly replying to you. All anyone has to do is read, to see you're the one using dishonest playground tactics. You will be exposed again and again, if you continue in this way. You can't convince people with dishonesty.



It's pretty extremist to want to do something extremely stupid in the light of contrary evidence if you ask me.

If you only have 1 pool (in your example) then there is only one source of block chain data.  So whether you get it DIRECTLY from them, or from someone who copied it from them, there's no "decentralization" in that story.


That doesn't change the fact that if you have only one pool, making one single block chain, you either accept it, or you don't have a block chain.

Even if you have 10 pools, connected together and agreeing (building on one another's blocks), there is STILL only one block chain, but now, 10 different pools have it and can send it to you.  All the others can simply copy from one of them, and send it to you too.

agreed. never said the opposite

???
...
i see your using my simple explanation of relay timing example..
arbitrary numbers..
but yea in a 1*8*8 vs 1*8*8*8*8*8*8 would still be centralised.. but distributed.
where as 20*8*8 vs 20*8*8*8*8*8*8 would be more decentralised.. especially if those 20 pools had different code bases and the different nodes(layers of 8 ) had differing code bases.

which was mentioned before:

Said the weaseliest weasel that ever weaseled in all of weaseldom without a hint of irony.   ::)

So, Carlton, do you think there should be a cut off point where coins not moved to a quantum proof key are frozen by the network? (https://bitcointalk.org/index.php?topic=1753893.msg17532379#msg17532379)  :D


Looked in a mirror lately?  I mean... it's like you don't even see it.

Where are your technical arguments?


If I'm so lacking in value as a source of truth, why do you need to attack nothing but my character? Why do you need to attack at all, surely I'm ssssssso transparent that anyone can see it without your "help"?


You can't make any actual arguments, or defend your own nonsense, and so you must attack nothing but me.

Let's see what people really think (and oh look, no-one's interested in reckless blocksize hard-forks, as usual)

My point was that the argument of "the more nodes, the more time it takes" is not correct.  There is no reason for nodes not to connect directly to one of the mining pool nodes (which can afford to have a datacenter-type node).  Then, all non-mining nodes are one single hop away from the pool-datacenter and are served directly.  No need for a P2P slow network.

This has nothing to do with decentralisation.  There is only one SOURCE of the block chain: the minerpool network.  If there is only one pool, well, this sole pool is the block chain source.  If there are 20 of them, they are well-connected between them, and all of them, most of them, or some of them will set up a data center to serve the non-mining nodes.  In any case, each of these miners is a good, primary source of the block chain, cannot cheat (if it withholds blocks, it will orphan its own blocks, it cannot make fake blocks - wasted hash rate - and they are eager to get the latest blocks from their co-miners), has no incentive to cheat and wants good connections to customer nodes to get to their transactions first, so that they can get hold of the most interesting fees first.

Whether you get the block chain directly from the source, or after several P2P hops, doesn't matter if you're not in a hurry, but if you are, then you better get it directly from a minerpool server.  And then, it doesn't really matter how many of the other nodes are also being served by that same data center.

Also, if the network interface on the network is well defined, whatever software you actually run on your client node, doesn't really matter.  If you are happy with it, that's fine.  People can use firefox or internet explorer or chrome or whatever as a browser ; so your node software, which is a "block chain downloader and browser/checker" can also be of various brands.  Doesn't matter, as long as it understands the (sole) block chain that is being served.

Cute Book.  :D


Segwit would open up many attacks on the Time Locking System , included in deadwit,
say a hacker finds a way to break the time lock early , they will be able to steal BTC like crazy and it could be months before anyone knows they were robbed.  ;)
Hacking an LN hub, to steal BTC is a matter of time, nothing else.

 8)

I would like to see adaptive block size: make it once and for ever. Raise to 2MB now, and what, another HF in 2 years or less?
https://github.com/bitpay/bitcoin/issues/42

That is not Segwit, that is LN. You are confusing two completely different things.

That version didn't gather much support if any. Bitcoin scales very inefficiently on the first layer, that's why it requires a secondary layer.

This is why I propose to use BOTH SegWit and Adaptive Block Size (Bitcoin ABS? XD )

I think only the following client implementations make sense for *compromise*, *consensus* or whatever:
Core: Segwit
Bitpay: SegWit + Adapative Block size - although I don't know how resistant it is to being gamed.
BitcoinEC: SegWit + Emergent Consensus - Already *praised* by ViaBTC (see here: https://twitter.com/ViaBTC/status/842748341767290880) [1].

---

[1] - Client not released yet.

bitcoin needs to remain decentralised. multiple pools. and also the NODES killing off blocks it doesnt like. that way the pools are not just reliant on each other but the nodes too.

if we start going down the rabbit hole of one codebase of nodes
then
one pool

then we might aswell just be using fiat.

bitcoin is different and revolutionary due to diversity where there is not nor should not be any point of failure or control.
EG if one pool drops off the other pools continue.
if one codebase has a bug the others continue while the issues are being sorted by those affected.

consensus is the mechanism that self regulates the network by majority consent .
as long as the majority is not a sybil/shill corporate party, all running the exact same thing(making bitcoin weaker)..
but instead diverse independent consensus. then bitcoins revolution can continue. and bitcoin becomes stronger.

core wanting to split the network or baiting and switching to falsely state all non-core will do it. where by what core have left is their software and using BTCC & slush (their DCG partners) as pools. is centralisation..

it wont matter how good or bad the code is.. by being all part of the DCG portfolio. bitcoin loses its ethos of being revolutionary and will just turn into something like paypal/banking system.

bitcoin should rise above the greed of the banking sector corporate control and stick with consensus by independent diverse community.

bitcoinEC.. lets just see

hmm
i wonder..
yep another DCG portfolio

oh look bitcoinec maintained by blocktracker.... https://keybase.io/blocktracker/ oh Barry silbert.. of DCG sems to be a follower (edit: now not)
let me guess lauda is ok with..
core (->blockstream ->DCG)
KNots? (luke JR->blockstream ->DCG)
bitcoinEC(silbert->DCG)

i find it funny how lauda shouts loudly in favour of all these DCG portfolio corporations/teams. yet hasnt read the lines of code yet of any implementation

though bitcoinEC is a 'in concept' a step in the right direction wise to move bitcoin forward. by having dynamics. im shocked at the ones jumping in advocating it without peer reviewing first

While the code is not released yet, for those not following up to date news, it seems to be latest Core client patched with BU Emergent Consensus concept:

EB (Excessive Blocks): user is able to set easily how big blocks to accept maximally, default value 1 MB
AD (Acceptance Deepth): BitcoinEC set it always to infinite, so your node can not automatically fall back to bigger blocks than your EB setting. But the BitcoinEC going to monitor where the longest proof of work (PoW) chain is and providing a warning when your not following longest PoW chain anymore because of your low EB setting.

Personally I see it step in the right direction as well.

https://bitcoinec.info/

i still think that non-pool nodes should really utilise policy.H more..

EG Consensus.h node hardwarelimit = something set by the nodes performing its own speed test of what it is physically capable of
for example 8mb
 then policy.h is the PREFERED size the network should work with.
EG 1mb today and maybe 2mb on activation day.

whereby pools see all the policy.h (prefered) in the node useragents.
and pools then
set their own policy.h just below what the majority of nodes prefer.
EG 0.999 today and 1.000250 day of activation. and pools then test the water of orphan risk and other unforseen bugs and increment up to 1.999 before the 'majority/minority' preferences kick in
thus a minority would accept the block but have their policy.h altered by warning system

What makes you think 'blocktracker' is Barry Silbert? That's a weird statement.

There's nothing to peer review yet. People are advocating for the idea.

As usual, not capable of giving any reasoned argument against what I'm telling you.
Why would a POOL be "reliant" on nodes to get them their competitors' blocks on which they decide to build or not ?
What use does another node have for that pool ?  The pool can find out for itself whether that block satisfies its own criteria, doesn't need other blocks to verify that for him.  On the other hand, that pool wants to know that block as fast as it can, in order not to waste hash rate on an orphaned block.  So there is not one single reason why a pool would not connect DIRECTLY to its competitor's nodes.

Yes, but that is an "inter-pool" affair only.


Majority of proof of work.


But then you bloody don't need proof of work !  Why not simply have the nodes keep a big mempool and call that the block chain ??  And each time there's a difference, we let the nodes vote, and the majority is right ?

Why do you think Satoshi introduced proof of work do you think ?  To come to a consensus !  Because if you rely just on nodes, which you could, then this is not secure against a Sybil attack: everyone can fire up 100 000 nodes.  Now, if there is a mechanism to DETECT a Sybil attack and not take it into account, you've just found a new consensus mechanism.  But it is not bitcoins.  Bitcoins consensus mechanism is proof of work.  Not "number of nodes voting".

I agree with that. I think the scaling should be flexible, adapt to the block size at the time. That is similar to the Monero.

your not seeing the bigger picture..

you think because pools can make their blocks that they dont need nodes.. well lets word it this way

you design a new bank note. you include all the security features.. but then you find that although you have a huge stack of bank notes.. no one likes them. they would prefer purple bank notes.. not green.

you could keep making green bank notes and thinking your making money..  but if no one is accepting them... your wasting your time. you cant spend them anywhere

now you start to realise about community consensus. if they dont like your blocks. your wasting your time making them.

Essentially, yes.
Well, they do need customers (people paying good money for the coins on their chain).  These customers need wallets.  So pools do need customers with wallets.  These wallets can connect directly to the pools' nodes ; or they can connect to those nodes that serve as proxy servers too.  Things like exchanges will probably run a full node, so pools would like these exchanges to take a copy of the block chain they make.


You're confusing users and nodes again.  Of course pools need users that pay good money for the coins the pools dump on the users.  But for that, the users need to have a choice.

With alt coins, that's not difficult.  There are other alt coins.  If the alt coin chain doesn't please alt coin users, they simply sell their coins, and buy others.

But with bitcoin it is different because the only thing bitcoin has going for it, is its brand name, its "first mover" image.  So if bitcoin miners only make one bitcoin chain, well, that is bitcoin.  And users have no choice, because there's no OTHER chain to prefer that has this brand image.

But in any case, it is a matter of miners and users, not of nodes. 

Your example of bank notes is also between those printing the notes, and those using it.  Whether the notes come by you through several different postal services (nodes) or they come to you as a user because you go and get them directly where they are printed, is the right analogy.  If the postal service refuses to carry the notes to your place, but you, as a user, want them, then you will go and get them directly where they are printed.

On the other hand, if the only notes that are printed, are green ones and nobody is making purple notes, well, you will still have to use the green ones if you want to use bank notes.   There aren't purple ones, EVEN if the postal service only wants to transport purple notes (that do not exist), and refuses to transport green ones.  You will have to go and get the green ones at the printer's site, if you want bank notes.  Even if you, and the postal service ,prefer purple ones.

your still not understanding bitcoin.
your looking at things too two-dimensionally.

users are not slaves to pools. just taking what pools hand out. users want to have a say in what is created. and thus they become nodes.
they then via majority consensus and rejecting blocks they dont like, cause pools to form a single chain (stack of bank notes) that the majority accept and are happy to use as currency.

those that object to the majority. can either stay with the network. objecting (orphaning what they get) and being left unsynced because they choose not to keep any blocks.
or
give in to majority and decide to match the majority of nodes choice and use the currency.
or
ban all communications with the ugly nodes and pools to avoid the orphan drama. and find a pool that will make the blocks they prefer and start their own altcoin.

yea there are some users that set themselves up as wallet services for random users that dont care much about the big decisions, and those uncaring users can just use the popular currency via third parties because they trust the third party shares their same basic desire to not need to run a node themselves.
but others want a more active role so become nodes to be part of consensus. knowing the more people voting for a certain thing the less chance some strange lobbied group cant just come in and vote to create something different and force a change.

and thats where majority consensus comes in..
securing bitcoin from random changes and only changing if there is majority consent of the community.

You are clearly missing the point.  Miners don't need the other nodes to get their blocks and make their chain.  They only need to connect amongst themselves, and they have all reasons to do so for matters of speed.  If miners make one single chain, whether other nodes don't like that chain or not, doesn't matter.  There is only one chain out there.  Nobody's making another one.

If tomorrow, there is consensus between all miners and they ONLY make the segwit chain, then that's it, and whether users like it or not, they have no choice.   If tomorrow, there is consensus about BU between all miners, and they only make the BU chain, then that's it, and users have no choice.  And if tomorrow (like today) miners have consensus and only make the standard chain, that's it, users have no choice.

You are talking about the case when there is no consensus between pools, and when pools make different chains.  Then nodes can pick one of the two (or three or four) chains that are available.  

But non-mining nodes have nothing to say to the blocks that miners put on the chain they build.  They can simply download them, and accept them or not.  That's all non-mining nodes do: download blocks from miners.  They can't stop miners from building chains.

And now we come to users: if miners only make one chain, users have no choice: that's the chain they have to use, there isn't any other.  But of course, users can decide to sell their coins and leave the thing, which is bad for miners, who need users to buy their coins.  So with one chain, users HAVE TO use it, but they can set the absolute market cap.

If there are more chains, users can use the different chains to buy and sell, and DETERMINE THE RELATIVE MARKET CAPS.  But in order for users to be able to do so, miners have to make different chains in the first place (with hard forks).  When  users set different relative market caps, miners will follow these ratios.

So again: miners make block chains, which nodes can download if they like it.  Users can only use the chains that miners make.  But they set the market cap of these chains, which is the ultimate thing miners are after.  If miners are in disagreement, and make hard forks, they leave the choice to the user.  If miners are in consensus and make only one chain, the user has only the choice to stay or to leave.

But, apart from the case of a hard fork and setting the relative market caps, users have nothing to say about WHICH chain(s) miners can make.  And nodes in all this story don't matter AT ALL.

No offense

But this thread may be 'redundant' in that as far as I can tell. Bitcoin Unlimited and Bitcoin Core are not in any negociations anymore.

Bitcoin Unlmited wants a hard blocksize increase,  first before seg witness (if at all) or other measures

Bitcoin Core wants NO hard blocksize increase under any circumstances...don't even mention it

Hard to get anywhere ..if no one will get out their chairs to come to the negociation table

So looking to me like if BU gets 51% they will simply FORK right away to solidify their postion on this as a lever

ie 400 usd btc at that point..imho..and likely some other alt (dash?) will fork over 300 bucks at that point in time

what a cluster


I like the ideas on this thread...but don't seem like it is gonna happen if no one is talking

I'm absolutely not convinced that miners showing support for BU actually want BU.  I think they simply don't want segwit, and they need something to block segwit.  BU or any other thing will do.   This is why they weren't affected by the bug in BU.  Because they don't care, it is not what they really want.  Miners want status quo because that's most profitable for them.  So the good old bitcoin protocol with 1MB will be with us forever.

Also, forking at 51% would be extremely risky, because once the two bitcoins are in the market, you give the choice to the market.  You might very well get seriously punished.  Why on earth would a miner want a bigger block and relieve pressure on the fee market ?  What miner is going to do a silly thing like that, and even risk bitcoin over that ?  

No, nothing of all this is going to happen: the bitcoin you know now, is the same bitcoin that will be running 10 years from now in my opinion.  Apart from the fact that there will maybe only be 1 mining pool :)  That mining pool can also serve as the big, single Lightning network hub if it wants to.  The LN fees will be identical to the block fees then.

Certainly plausible, but it seems doubtful to me. What evidence leads you to conclude this?


Agreed. Good thing the most-widely-distributed 'plan' for BU cutover is 75%. That would be amongst all compatible clients. Including BU, simple 8MB, the upcoming BitcoinEC, and others. Today's support is at 43.8% + 6.9% - looks like we are well on the way to an end to this war. Some will lick their wounds, but I like to think that the victors will be welcoming of all.

Of course I would agree with such a proposition. Any sane person would do the same as a split could be the worst thing that could happen to us, and this, people do not understand it.

When the largest ASIC manufacturer is making threats like this -

https://twitter.com/JihanWu/status/843341104531427336


This is symptomatic of a far greater problem in bitcoin and possibly Jihan is under duress to force a hard fork through. There is no negotiation with hostile cartels trying to attack users without consensus, instead we must further test and develop backup plans for worst case scenarios--

Website: btcpowupdate.org
https://bitcointalk.org/index.php?topic=1833391.0

I very much agree with this, but now it can not happen, segwit has not been accepted by everyone, and now it's split into two branches, I do not know if this is good or bad, But it is affecting the bitcoin market, bitcoin is outdated by others, its value is falling sharply. Meanwhile, a lot of alt is growing vigorously. ETH is a typical example, it has taken breakthrough development, which is essential for bitcoin. I am looking forward to this change will bring many benefits to bitcoin. Bitcoin is not allowed to crash

https://medium.com/@aantonop/i-just-spent-the-last-8-months-working-on-the-second-edition-of-mastering-bitcoin-and-i-couldnt-c63bfdae248d#.wxal6cyyp

Both parties have their own side which they want to protect and defend. They are all biased and have their own personal intentions to satisfy. They would not give up their pride and tried to make a merger to settle the issues. That is why the exchanges have made a move to just make the production of Bitcoin Unlimited as an altcoin and it was named BTU. Maybe segwit won this round and there will be no more compromises to be made.

For anyone who may have missed it, BitPay are also weighing up the pros and cons of an adaptive blocksize (https://medium.com/@spair/a-simple-adaptive-block-size-limit-748f7cbcfb75#.s764hrull).  There is increasing momentum behind this idea, so let's do something positive with it.  It will likely need more safeguards and improvements before we can move forward with the idea.  Everyone needs to think long and hard about potential attack vectors and ways to game the system and, if possible, provide some solutions to those issues.  I'm confident that if we can bolster a few weaknesses and minimise the incentives to carry out spam attacks to artificially inflate the blocksize, we can come up with a good overall compromise.

Actually segwit will eventually force everyone including Satoshi to move their coins into segwit keys to move the entire system up to a new level of security and flexibility, think about it if segwit is a bad thing and can destroy bitcoin why would they want to turn their own gold into iron or just dust?
that doesn't make any sense even if they manage to take control over the network which they already have(%85 of miners are running Core nodes) it is something that we need to check and study for ourselves, why did you enter bitcoin? did you go and read the code line by line?

Most users will probably be happy with any proposal that increases the block size, the BIP100 revision also seems sensible.

The BU group are anti-segwit/ln (for obvious reasons) but may also be against their own proposal, IE it's just a blocking and/or leverage position.

The core group are very unlikely to roll back back their position either as too much time and money has been 'invested' in their solution.

Supporters of both groups are quick to blame the other for the downturn in the current BTC price, but they are both to blame IMHO, the fact that no solution is currently likely is just a plausible a reason, but unless you talk to all the people selling there is no way to know for sure.

Status Quo, seems the likely winner, and Bitcoin will continue to suffer as a result, maybe it will take that suffering for a consensus to emerge.

That's an argument for sitting back and watching Bitcoin fail when the ECDSA signature scheme (which Bitcoin uses) is threatened by future cryptographic advances.

The keys and signatures are the weakest crypto in the Bitcoin system, all the honest experts agree that external attacks using new crypto will force us move to new keypairs eventually. In that situation, Satoshi will have to move his coins just like anyone else, or the new crypto methods that break the current key scheme can and will steal their BTC held at addreses using the old keypairs whatever they do or do not want.


And besides which, you're confused. Segwit is a soft fork, that respects the ability of users who want to carry on using P2PKH and P2SH keys. No-one is being forced to do anything, although it's going to be cheaper once the non-nested P2W key scheme is instituted (sipa made a new proposal for those new key types fairly recently)

Wonder whether people consider this to be a good compromise solution:

https://bitcoinec.info/

You still have some time :)   Bitcoin will fail in much more mundane ways long, long long before that will happen. 

It is much simpler to use other crypto whenever that comes, than to try to repair a broken car.  But for the moment (and many many years to come), it isn't broken.  Forget the idea that a crypto currency is "for ever".  It has a life cycle, like any product.  And really, bitcoin will reach the end of its life cycle long, long before that cryptographic system breaks down.   There's nothing wrong with systems reaching the end of their life cycle.  You simply switch to better systems in that case.
It means you stop buying bitcoin and selling bitcoin, and you start buying Xcoin and selling Xcoin.  Nothing dramatical.  But don't dream that bitcoin is forever.  Nothing is.  Especially nothing that is in this technology.  Even today, bitcoin tech is oldfashioned and clunky, where it was brilliant and shiny when it came out.  It will still last a while.  But not as long as elliptic curve crypto.

Thinking about this myself, wouldn't it just make a lot of the core code 2 tier network backwards compatibility solution redundant technical debt?

That was an example to contrast with the "Segwit address format = stealing Satoshi's BTC" argument


Please read the whole post in context before replying, you're wasting alot of space with your ill-conceived replies

I read your post.  The point is, that there is no reason to "repair" a coin.  A coin is meant to be what it is, according to its protocol (not its *software*).  If that protocol fails in one fundamental way or another, one should move to another coin (that is, another protocol).

So every time a bug arises, hard-fork it, right? It's a good thing you're not project managing any cryptocoins, no-one would ever buy in to begin with faced with that prospect

Not a bug.  A bug is a thing about software.  I'm talking about a protocol error.  A mathematics or cryptography error, an error in the economical dynamics.  Software can change, software only IMPLEMENTS (correctly or not) the protocol.  But the protocol IS the coin. 

For instance, it is part of the protocol of bitcoin that just ANY UTXO from any block can ALWAYS be used as an input to a transaction, using your private key in a way that was written down long ago.  If you leave your private key to your kids, and they leave it to their grand children, .... and 500 years from now, that private key should still be usable if that coin still exists.  If that's not the case, then that's not bitcoin. 

Now, if the cryptography breaks down and that private key can be deduced by cracking 2 hash functions and elliptic key signatures, then bitcoin is simply done.  There's no point in trying to fix that, if by fixing that, you break the original protocol.

Now, imagine that there was software that had bugs in the crypto software and accepted erroneous signatures.  That is simply a bug.  It means that maybe 1000 blocks have been generated that were INVALID according to the protocol, even though the buggy software accepted it.

The right thing to do is to orphan these 1000 blocks, because they are simply not valid according to the protocol, and were ERRONEOUSLY considered valid blocks by faulty software, and to start mining again from the point where the last valid block (according to the written protocol) was made.

If not, then whatever thing is being used, is not bitcoin.  Because bitcoin was an immutable protocol. (not unmodifiable software, that *implements* a protocol).  A protocol is a white paper with all details of it.  Not a piece of software.

I disagree, if there's a bug in the protocol, why bail-out the ignorant people who didn't discover the bug before they bought the coin ;)


Your principle is flawed, and even if it isn't, what are you going to do about it? There's no way to force your idea on anyone, and so we'll just have to wait and see whether or not reality can demonstrate that you're either right or wrong....


......and oh look, the Bitcoin design and protocol have both been upgraded many, many times, and we're reaping the benefits of that right now.

Meanwhile, back in your own personal TheoreticalLand, you've got more tedious waffle for us, do go ahead ::)

Since Satoshi hadn't considered ASICS, but wrote about CPU, anyone wanting to be as true as possible to the original vision would likely want SegWit+LN for an equitable distribution of the work between all volunteers (perhaps 50,000 plus users from all of the users - i.e dedicated hashing devices rather than clients like phones), which would be bad news for heavily invested mega miners, but better for the network and distribution to be in almost all time zones (and possible BTC rewards to lots of different people rather than just a couple of outfits earning all the coin.  Hashing power will come down drastically initially but so what? - we're getting back to the 1%er syndrome and I'm sure the intention was to avoid exactly that).

Personally I'm prepared to wait a couple of weeks for recalibration of the difficulty if they all dropped out on the same day (highly unlikely since having consensus would likely make price go up and they still get their 12.5 lottery drops, and LN wouldn't be an immediate release anyhow), but it will once again allow average users to be participants in BTC to contribute out of their own electricity bill a little hashing power (maybe just a USB miner).

The rational holder of BTC who wants to see it going up and add more stability for the cost of a USB stick plus electricity, minus a few dollars a year in fee earnings and feel it's for a good cause, I'm sure there would be many that would volunteers.  I would for one.

I'm not proposing to bail out anyone :)  I'm just saying that whining about a crypto because it doesn't have the right features and "should evolve" is not the right attitude: changing to a better crypto is.  The only thing where this hurts, is in the monetary belief in eternity, but things are never eternal. 


I think my principle is right.  Not "morally right" but "factually right".   And yes, I don't think that bitcoin will change unless it is totally centralized and that central authority (a cartel of 5 miners for instance) decides upon whatever should happen to bitcoin.

My conviction is that as long as bitcoin is decentralized, the protocol is protected by the dynamics of immutability.  And all the animosity we see is nothing else but that dynamics at work: the fact of sufficiently diverse antagonists (decentralisation) not being able to agree over anything but status quo, because all change can be done in 10 different ways, and each antagonist has HIS way.  So I think that we are now stuck with the bitcoin protocol as it is, and 1 MB blocks.  For ever.  Unless a cartel of 5 miners (and maybe a Chinese government official) in a room somewhere decide otherwise.


Apart from the very early years, I would doubt that.  I don't think that there has ever been a hard fork in bitcoin.  Soft forks are protocol restrictions, so in as much as 51% of PoW decides, imposing soft forks is not really a protocol modification ; going back however, is.  Can you give many examples of protocol upgrades ?  The block format is the same, the block header is the same, the signature scheme is the same, the bitcoin instruction set is the same as far as I know, .... I really wonder what has changed in the bitcoin protocol, that is, in the way to write valid block chains ?  (apart the very first beginnings when bitcoin was worth zilch and no mechanisms were locked in by profit and antagonism yet)

(the network protocol is much less important as it is volatile: what remains is the block chain).

You know of many hard forks of bitcoin in the past ?


It is my way to build my own understanding.

Significant changes to the Bitcoin protocol were soft-forked into the coin only last year, and in 2015, and in 2014


That completely contradicts your argument, 100%. Spare us your bloviated replies, you're talking nonsense.

I think you're being very naive about LN, much more so that Satoshi's naivity about proof of work.  The LN only makes sense when there are VERY BIG hubs to which normal users connect.  The reason is that in order to be able to pay a random person over the LN you need to find a series of nodes that can propagate your payment to destiny before settling on that path.  Settling costs a fee.  In order for the LN to be competitive with direct on chain transactions, a LN channel needs on average to transact AT LEAST a number of transactions, equal to the number of hops between sender and receiver.  In other words, if on average, a transaction takes 20 hops between a sender and a receiver, that means that on average, each LN channel must transact 20 transactions before settling, or direct on chain transactions would be cheaper.

This means that you have to "lock in" on average 20 times the amount of a single transaction in each of your LN channels to your neighbours EVEN TO BREAK EVEN, if you charge the same fee to your customers, than an on chain fee.
The more you can keep your LN channels open before settling, the better your margin becomes (between the fees you can charge for a LN transaction, and the block chain fee).  But you are not alone in settling: your counterparty can settle too !

The economies of scale in this system are evident: the most profitable LN nodes, that can offer the most competitive LN fees, and can guarantee the best probability to reach destination, are BIG HUBS that connect amongst them, with very large amounts locked up in their channels.  Small players are CUSTOMERS, that have to open a channel to their BANK/hub and keep it open to process at least say, 20 transactions before closing and having to pay an on-chain fee.

The economies of scale in the LN are even much more pronounced than the economies of scale in proof of work.  So the centralization will go even faster.  Bitcoin is now in the hands of 5 people (the 5 mining pools that make up more than 51%), and for sure in the hands of 14 people (controlling more than 90% of the hash rate).

Bitcoin is hence a large majority 14 people oligarchy.  But it took several years for this centralisation to take place.   The LN will do this much faster.  Probably 10-15 "banks" of hubs will form rather quickly if the LN is to function.