Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: d5000 on March 07, 2017, 08:07:34 PM



Title: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 07, 2017, 08:07:34 PM
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/)

Quote from: Reddit user ecafyelims
Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) into a single HF (with overwhelming majority consensus).

Since Segwit changes how the blocksize is calculated to use weights, our goal with the merger would be 2MB of transactional data.

Segwit weighting system measures the transaction weight to be 3x(non-witness base data) + (base data with witness data). This weight is then limited to 4M, favoring witness data.

Transactions aren't all of base or witness. So, in practice, the blocksize limit is somewhere between 1MB (only base data) and 4MB (only witness data) with Segwit.

With this proposed merger, we will increase Segwit weight limit from 4M to 8M. This would allow 2MB of base data, which is the goal of the 2MB HF.

It's a win-win solution. We get 2MB increase and we get Segwit.

I know this compromise won't meet the ideals of everyone, but that's why it's a compromise. No one wins wholly, but we're better off than where we started.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: DooMAD on March 07, 2017, 08:17:16 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 07, 2017, 08:22:56 PM
@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).



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Gimpeline on March 07, 2017, 08:28:58 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Sundark on March 07, 2017, 08:29:11 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AgentofCoin on March 07, 2017, 08:35:14 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: -ck on March 07, 2017, 08:44:34 PM
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.)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 07, 2017, 09:19:17 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: hv_ on March 07, 2017, 09:50:54 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AgentofCoin on March 07, 2017, 10:15:44 PM
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 ...

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 07, 2017, 10:29:13 PM
BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AgentofCoin on March 07, 2017, 10:44:25 PM
BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization).
...
How decentralised is LN?

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


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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: tbonetony on March 07, 2017, 10:51:51 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Swimmer63 on March 07, 2017, 11:08:22 PM
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. 


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 07, 2017, 11:21:52 PM
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.

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 07, 2017, 11:32:22 PM
BU's fundamental purpose is Semi-Unrestricted block building (accelerates network centralization 1).
CORE's fundamental purpose is Semi-Restricted block building (preserves network decentralization 2).

1 Bigger blocks tend toward network centralisation,
3 but decentralises the user base (more people can afford to send bitcoin).

2 Small blocks allow greater network decentralisation,
4 but centralises the user base (only a few big actors can afford to send bitcoin).

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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: BitUsher on March 07, 2017, 11:41:27 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AgentofCoin on March 08, 2017, 12:01:35 AM
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.

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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 08, 2017, 12:14:55 AM
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.
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AgentofCoin on March 08, 2017, 12:19:03 AM
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.
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 08, 2017, 12:27:48 AM


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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 08, 2017, 01:32:02 AM


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

BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% under the old approach.  basically when it activates, the 95% will have to be willing to potentially orphan the blocks of the 5% that remain
If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AgentofCoin on March 08, 2017, 02:28:37 AM


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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: kiklo on March 08, 2017, 06:03:27 AM
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/)

Quote from: Reddit user ecafyelims
Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) into a single HF (with overwhelming majority consensus).

Since Segwit changes how the blocksize is calculated to use weights, our goal with the merger would be 2MB of transactional data.

Segwit weighting system measures the transaction weight to be 3x(non-witness base data) + (base data with witness data). This weight is then limited to 4M, favoring witness data.

Transactions aren't all of base or witness. So, in practice, the blocksize limit is somewhere between 1MB (only base data) and 4MB (only witness data) with Segwit.

With this proposed merger, we will increase Segwit weight limit from 4M to 8M. This would allow 2MB of base data, which is the goal of the 2MB HF.

It's a win-win solution. We get 2MB increase and we get Segwit.

I know this compromise won't meet the ideals of everyone, but that's why it's a compromise. No one wins wholly, but we're better off than where we started.

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

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:
LN Does Needs Segwit so that LN can be trust less.
Otherwise LN requires a separate Trust system in place or very long extensive Time Locks , Both of which LN Devs don't want.

https://www.reddit.com/r/Bitcoin/comments/5eqm2b/can_ln_work_without_segwit/?st=izzovrzk&sh=b2fe8b0a
Quote
Yeah you can do LN without segwit. It's less efficient, and there are some features you won't be able to do.

With segwit, you can have a 3rd party "watch" your channel for you in case your counterparty tries to broadcast an old, fraudulent transaction.
The 3rd party can automatically grab your money back for you. And the watcher doesn't even know about your transactions or your balances while watching.

That whole feature is pretty much gone without segwit.
You'd have to tell the watcher everything about your channel, and the only thing they'd be able to do is e-mail you to let you know if fraud occurred.


The other main disadvantage to segwit-less LN is that channels would have a preset duration. That's a pretty big downside.

If segwit doesn't activate after a long time, we could re-program some of the current code to work without segwit.
I think everyone's hoping we don't have to as that'd be a bit disappointing, but doable.
As I meme'd at scaling HK, there are levels of LN we are prepared to accept


In Short , without Segwit any version of LN is going to be Crap and No threat to the Miners at all.   ;)

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.

https://www.reddit.com/r/btc/comments/5vbofp/initially_i_liked_segwit_but_then_i_learned/

Quote
You wanted people like me to support you and install your code, Core / Blockstream?

Then you shouldn't have a released messy, dangerous, centrally planned hack like SegWit-as-a-soft-fork - with its random, arbitrary, centrally planned, ridiculously tiny 1.7MB blocksize -
and its dangerous "anyone-can-spend" soft-fork semantics.

Now it's too late. The market will reject SegWit - and it's all Core / Blockstream's fault.

The market prefers simpler, safer, future-proof, market-based solutions such as Bitcoin Unlimited.

Quote
The damage which would be caused by SegWit (at the financial, software, and governance level) would be massive:

    Millions of lines of other Bitcoin code would have to be rewritten (in wallets, on exchanges, at businesses) in order to become compatible with all the messy non-standard kludges and workarounds which Blockstream was forced into adding to the code (the famous "technical debt") in order to get SegWit to work as a soft fork.

    SegWit was originally sold to us as a "code clean-up". Heck, even I intially fell for it when I saw an early presentation by Pieter Wuille on YouTube from one of Blockstream's many, censored Bitcoin scaling stalling conferences)

    But as we all later all discovered, SegWit is just a messy hack.

    Probably the most dangerous aspect of SegWit is that it changes all transactions into "ANYONE-CAN-SPEND" without SegWit - all because of the messy workarounds necessary to do SegWit as a soft-fork. The kludges and workarounds involving SegWit's "ANYONE-CAN-SPEND" semantics would only work as long as SegWit is still installed.

    This means that it would be impossible to roll-back SegWit - because all SegWit transactions that get recorded on the blockchain would now be interpreted as "ANYONE-CAN-SPEND" - so, SegWit's dangerous and messy "kludges and workarounds and hacks" would have to be made permanent - otherwise, anyone could spend those "ANYONE-CAN-SPEND" SegWit coins!

    Segwit cannot be rolled back because to non-upgraded clients, ANYONE can spend Segwit txn outputs. If Segwit is rolled back, all funds locked in Segwit outputs can be taken by anyone. As more funds gets locked up in segwit outputs, incentive for miners to collude to claim them grows.



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: freedomno1 on March 08, 2017, 07:42:06 AM
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.)

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/




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.


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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Anon TumbleBit on March 08, 2017, 08:19:58 AM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: kiklo on March 08, 2017, 08:24:10 AM
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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 08, 2017, 08:20:34 PM
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.

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

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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 08, 2017, 08:28:21 PM
It most likely will not work. As I have outlined in a recent post, there are too many different and "entrenched" camps.

There are a lot of different "camps":
1) BU only.
2) Core only.
3) Soft-fork only.
4) Hard-fork only.
5) Only block-size increase.
6) Only block-size decrease.
7) No hard-fork at any cost.
8.) Other?
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 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.
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.

That certainly sounds like a good idea, if the community decides to support this proposal. Would Core allow that kind of compromise?
Core can not stop community/miner consensus. Let me see a viable BIP + code first, then we can talk about that.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AgentofCoin on March 08, 2017, 08:49:31 PM
It most likely will not work. As I have outlined in a recent post, there are too many different and "entrenched" camps.

There are a lot of different "camps":
1) BU only.
2) Core only.
3) Soft-fork only.
4) Hard-fork only.
5) Only block-size increase.
6) Only block-size decrease.
7) No hard-fork at any cost.
8.) Other?
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 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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 08, 2017, 09:53:56 PM
Core can not stop community/miner consensus.
firstly core bypassed community consensus using bip9 by going soft..

Let me see a viable BIP + code first, then we can talk about that.

secondly read bip 9, yep it can be changed. even gmaxwell admits this.
BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% (C) under the old approach.  basically when it activates, the 95% will have to be willing to potentially orphan the blocks of the 5% that remain(B)
If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.(A)

^ 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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: -ck on March 08, 2017, 10:56:49 PM
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.)

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 08, 2017, 11:26:35 PM
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?



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 09, 2017, 01:09:57 AM
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jonald_fyookball on March 09, 2017, 02:14:42 AM
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?



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 09, 2017, 02:22:12 AM
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.

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 09, 2017, 03:06:09 AM
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.

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 09, 2017, 04:43:12 AM
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 ::))

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

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

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
though segwit doesn't change the sigops included in regular transactions,


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 09, 2017, 07:07:17 AM
firstly core bypassed community consensus using bip9 by going soft..
No.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 09, 2017, 07:38:33 AM
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


Always assume that if a malicious vector exists then someone will try and exploit it


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 09, 2017, 04:52:22 PM
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 ::))
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!!

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 09, 2017, 05:32:06 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 09, 2017, 05:37:35 PM
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 ::))
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!!

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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 09, 2017, 06:09:04 PM
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 ::))
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!!

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.

but this is where the rules need to be defined.

No new rules need be defined.

Quote
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'.

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

Quote
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

Yes - now you're getting it.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 09, 2017, 08:49:31 PM
I have read DooMAD's proposal now (https://bitcointalk.org/index.php?topic=1801057.msg17965476#msg17965476) and I like it a bit. [...]
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.

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

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 09, 2017, 09:07:31 PM
Quote
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

Yes - now you're getting it.

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'


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 09, 2017, 09:39:16 PM
Quote
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

Yes - now you're getting it.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: -ck on March 09, 2017, 09:43:26 PM
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


Always assume that if a malicious vector exists then someone will try and exploit it
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 09, 2017, 10:12:47 PM
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 09, 2017, 10:30:48 PM
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.

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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Hexadecibel on March 09, 2017, 10:50:53 PM
No compromise.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AgentofCoin on March 09, 2017, 11:05:21 PM
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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 09, 2017, 11:34:01 PM
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.

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

are you sure

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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: -ck on March 09, 2017, 11:37:46 PM
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.
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: unamis76 on March 09, 2017, 11:48:32 PM
This and other similar mix of BIP's has been suggested... If it scales, I'm down for it or pretty much anything else.

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.

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.



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 09, 2017, 11:50:11 PM
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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 10, 2017, 12:02:52 AM
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.
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: -ck on March 10, 2017, 01:03:17 AM
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.
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 10, 2017, 01:11:41 AM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 10, 2017, 01:37:55 AM
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.
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.

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.

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

For those unwilling to click through:

Quote
BUIP033: Parallel Validation
Proposer: Peter Tschipper
Submitted on: 10/22/2016

Summary:

Essentially Parallel Validation is a simple concept. Rather than validating each block within the main processing thread, we instead create a separate thread to do the block validation. If more than one block arrives to be processed then we create yet another thread. There are currently up to 4 parallel block processing threads available making a big block DDOS attack impossible. Furthermore, if any attacker were somehow able to jam all 4 processing threads and another block arrived, then the processing for the largest block would be interrupted allowing the smaller block to proceed, unless the larger block or blocks have most proof of work. So only the most proof of work and smallest blocks will be allowed to finish in such
as case.

If there are multiple blocks processing at the same time, when one of the blocks wins the race to complete, then the other threads of processing are interrupted and the winner will be able to update the UTXO and advance the chain tip. Although the other blocks that were interrupted will still be stored on disk in the event of a re-org.

...


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 10, 2017, 01:40:11 AM
im starting to see what game jbreher is playing.
...

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: -ck on March 10, 2017, 02:04:32 AM
https://bitco.in/forum/threads/buip033-passed-parallel-validation.1545/

For those unwilling to click through:

Quote
BUIP033: Parallel Validation
Proposer: Peter Tschipper
Submitted on: 10/22/2016

Summary:

Essentially Parallel Validation is a simple concept. Rather than validating each block within the main processing thread, we instead create a separate thread to do the block validation. If more than one block arrives to be processed then we create yet another thread. There are currently up to 4 parallel block processing threads available making a big block DDOS attack impossible. Furthermore, if any attacker were somehow able to jam all 4 processing threads and another block arrived, then the processing for the largest block would be interrupted allowing the smaller block to proceed, unless the larger block or blocks have most proof of work. So only the most proof of work and smallest blocks will be allowed to finish in such
as case.

If there are multiple blocks processing at the same time, when one of the blocks wins the race to complete, then the other threads of processing are interrupted and the winner will be able to update the UTXO and advance the chain tip. Although the other blocks that were interrupted will still be stored on disk in the event of a re-org.

...

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: nillohit on March 10, 2017, 10:57:16 AM
I support SegWit  ;D


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 10, 2017, 11:45:35 AM
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.
I don't understand that statement. Are you talking about DooMAD's idea (modified BIP100+BIP106) or the compromise proposed by "ecafyelims", or both?
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".
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

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.
That's not how this works.

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

For those unwilling to click through:

Quote
BUIP033: Parallel Validation
Proposer: Peter Tschipper
Submitted on: 10/22/2016

Summary:

Essentially Parallel Validation is a simple concept. Rather than validating each block within the main processing thread, we instead create a separate thread to do the block validation. If more than one block arrives to be processed then we create yet another thread. There are currently up to 4 parallel block processing threads available making a big block DDOS attack impossible. Furthermore, if any attacker were somehow able to jam all 4 processing threads and another block arrived, then the processing for the largest block would be interrupted allowing the smaller block to proceed, unless the larger block or blocks have most proof of work. So only the most proof of work and smallest blocks will be allowed to finish in such
as case.

If there are multiple blocks processing at the same time, when one of the blocks wins the race to complete, then the other threads of processing are interrupted and the winner will be able to update the UTXO and advance the chain tip. Although the other blocks that were interrupted will still be stored on disk in the event of a re-org.
Which effectively.. solves nothing.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: DooMAD on March 10, 2017, 03:11:46 PM
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".
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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 10, 2017, 03:44:17 PM
I support SegWit  ;D
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 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 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'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. 
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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: DooMAD on March 10, 2017, 04:07:54 PM
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. 
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 10, 2017, 05:03:37 PM
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. 
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 10, 2017, 07:40:37 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 10, 2017, 08:35:55 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 10, 2017, 08:52:28 PM
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  ;) )



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 10, 2017, 09:12:25 PM
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 10, 2017, 10:39:55 PM
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).
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?

i even made a picture to keep peoples attention span entertained
What software did you do this in? (out of curiosity)

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 10, 2017, 10:57:33 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 11, 2017, 12:31:40 AM
https://bitco.in/forum/threads/buip033-passed-parallel-validation.1545/

For those unwilling to click through:

Quote
BUIP033: Parallel Validation
Proposer: Peter Tschipper
Submitted on: 10/22/2016

Summary:

Essentially Parallel Validation is a simple concept. Rather than validating each block within the main processing thread, we instead create a separate thread to do the block validation. If more than one block arrives to be processed then we create yet another thread. There are currently up to 4 parallel block processing threads available making a big block DDOS attack impossible. Furthermore, if any attacker were somehow able to jam all 4 processing threads and another block arrived, then the processing for the largest block would be interrupted allowing the smaller block to proceed, unless the larger block or blocks have most proof of work. So only the most proof of work and smallest blocks will be allowed to finish in such
as case.

If there are multiple blocks processing at the same time, when one of the blocks wins the race to complete, then the other threads of processing are interrupted and the winner will be able to update the UTXO and advance the chain tip. Although the other blocks that were interrupted will still be stored on disk in the event of a re-org.
Which effectively.. solves nothing.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 12:43:59 AM

i even made a picture to keep peoples attention span entertained
What software did you do this in? (out of curiosity)


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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 12:47:02 AM
Exactly. There is no problem which requires solving. This merely eliminates the DoS potential that quadratic has time exploits might incur, if there was not this obvious workaround already inherent in the protocol.

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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 11, 2017, 12:49:16 AM
Exactly. There is no problem which requires solving. This merely eliminates the DoS potential that quadratic has time exploits might incur, if there was not this obvious workaround already inherent in the protocol.

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, segwits promise=broke
blockstreamer: quadratics has never been a problem relax its no big deal

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 12:15:32 PM
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'?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 12:33:39 PM
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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Searing on March 11, 2017, 12:38:20 PM
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/)

Quote from: Reddit user ecafyelims
Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) into a single HF (with overwhelming majority consensus).

Since Segwit changes how the blocksize is calculated to use weights, our goal with the merger would be 2MB of transactional data.

Segwit weighting system measures the transaction weight to be 3x(non-witness base data) + (base data with witness data). This weight is then limited to 4M, favoring witness data.

Transactions aren't all of base or witness. So, in practice, the blocksize limit is somewhere between 1MB (only base data) and 4MB (only witness data) with Segwit.

With this proposed merger, we will increase Segwit weight limit from 4M to 8M. This would allow 2MB of base data, which is the goal of the 2MB HF.

It's a win-win solution. We get 2MB increase and we get Segwit.

I know this compromise won't meet the ideals of everyone, but that's why it's a compromise. No one wins wholly, but we're better off than where we started.

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



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

 


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 11, 2017, 01:03:19 PM
just compromise already

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 01:26:03 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: 7788bitcoin on March 11, 2017, 02:01:17 PM
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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: inBitweTrust on March 11, 2017, 02:06:49 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 11, 2017, 02:07:12 PM
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?


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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: naughty1 on March 11, 2017, 02:14:09 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 02:14:22 PM
Which is bigger, 2 MB blocks or 4 MB blocks   ::)

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 02:15:43 PM
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?

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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 02:20:26 PM
for clarity

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

And that 4MB is
1MB of transactional data space, and 3MB buffer space, that only partially fills dependant on the % of segwit users in the base block
(0% segwit in 1mb base=0of the 3mb extra used(1mb total))
(10% segwit in 1mb base=0.1mb of the 3mb used(1.1mb total))
(100% segwit in 1mb base=1.1mb of the 3mb used(2.1mb total))

 the latter of which(atleast 1.9mb) 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.

FTFY


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 04:49:34 PM
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.
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.

segwit is not the compromise
It is.

activating segwit solves nothing.
It does.

because even after activation segwit will still be contending against native key users
Nobody cares. You can't DOS the network with "native" keys post Segwit.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 05:05:19 PM
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.
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.
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

segwit is not the compromise
It is.

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

activating segwit solves nothing.
It does.

go on PROVE IT!! explain it

because even after activation segwit will still be contending against native key users
Nobody cares. You can't DOS the network with "native" keys post Segwit.

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 05:09:46 PM
emphasis >2mb
> (UPTO) 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.. users need to move funds to new keys to attain it.
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'.

lauda compromise meaning lost, sold out, victim 'you left your password on girlfriends phone, now your funds are compromised'
No. That is just one of the meanings, see here: http://www.dictionary.com/browse/compromise

segwit is not an agreed reduced level. its a risk of screwing many over for the fortunes of the corporate elite
This is bullshit and you know it.

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

you can.
native keys still work after segwit activates. otherwise 16mill coins are locked and unspendable!!
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 05:13:27 PM
you can.
native keys still work after segwit activates. otherwise 16mill coins are locked and unspendable!!
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 05:15:41 PM
you can.
native keys still work after segwit activates. otherwise 16mill coins are locked and unspendable!!
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.

lauda please

native keys would fill the 1mb base block so that segwit cant get a chance.. thus there isnt a 2mb block..
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 05:21:41 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 05:31:37 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: European Central Bank on March 11, 2017, 05:39:00 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 05:42:54 PM
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 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
Segwit will definitely deliver >2 MB according to the latest usage patterns.

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"


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 11, 2017, 06:10:31 PM
Which is bigger, 2 MB blocks or 4 MB blocks   ::)

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.

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? :)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 06:14:15 PM
Which is bigger, 2 MB blocks or 4 MB blocks   ::)

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.

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.

Quote from: franky1
for clarity

Quote from: AngryDwarf on Today at 02:14:22 PM
Quote from: Carlton Banks on Today at 02:07:12 PM
Which is bigger, 2 MB blocks or 4 MB blocks   Roll Eyes

And that 4MB is
1MB of transactional data space, and 3MB buffer space, that only partially fills dependant on the % of segwit users in the base block
(0% segwit in 1mb base=0of the 3mb extra used(1mb total))
(10% segwit in 1mb base=0.1mb of the 3mb used(1.1mb total))
(100% segwit in 1mb base=1.1mb of the 3mb used(2.1mb total))

 the latter of which(atleast 1.9mb) 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.

FTFY


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 11, 2017, 06:19:41 PM
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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 06:30:46 PM
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)

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 06:32:40 PM
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?

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 11, 2017, 06:38:08 PM
The challenge is now to find a number for this cap. [...]
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.

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



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 11, 2017, 06:41:42 PM
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)

So is this the extreme case where a large number of inputs is used in a transaction to fill up the segwit space?

The opposite

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



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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 06:45:51 PM
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)
I didn't say that; stop twisting my argument.

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.
Irrelevant. You can spam whatever you want, miners can prioritize Segwit transactions and are incentivized to do so.

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.
Nope. Read the above.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 06:47:34 PM
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)

So is this the extreme case where a large number of inputs is used in a transaction to fill up the segwit space?

The opposite

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



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

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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AliceWonderMiscreations on March 11, 2017, 06:50:49 PM
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).

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 06:59:33 PM
The "drastic" future of which you speak sounds like FUD to me.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 11, 2017, 07:00:06 PM
I've never used multi-sig, so it is a gap in my knowledge. Perhaps if pro-segwit people would stop hurling insults around and explain things better I might change my mind on what I think the best way forward is. So please explain this test case, and how it would work without segwit.

I'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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 07:03:32 PM
No, bandwidth matters more than threads.
I don't think downloading 1 TB over 1 year is a problem. The upload side though would be.

The "drastic" future of which you speak sounds like FUD to me.
No. It is research, and you can try to find the video yourself.

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.
Oh yes, let's make nodes expensive to run. That is good for decentralization!

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
Nobody is talking about 20 MB blocks tonight; you have reading comprehension problems.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 11, 2017, 07:10:41 PM
@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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 07:11:27 PM
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)

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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 11, 2017, 07:17:18 PM
You can't expect good will from those to whom you demonstrate bad will, Dwarf


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 07:24:58 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 11, 2017, 07:32:53 PM
If you name is inherently insulting to you, you should take responsibility for choosing it


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 07:43:21 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 07:50:12 PM
@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 ;) ).
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.

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

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

Edit: What upper limit would you consider realistic?
In what time frame? Next 5, 10 years?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 08:02:17 PM
You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security.

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.



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 08:13:11 PM
You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security.
then stop throwing speculations of things like 20mb blocks... or ur gangs other fake doomsdays of "gigabytes by midnight" "visa by tomorrow"
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.

8mb upper limit and 2mb lower (dynamic) limit.
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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 08:17:12 PM
You shouldn't be optimistic nor relying on speculative predictions of the future when it comes to Bitcoin's security.
then stop throwing speculations of things like 20mb blocks... or ur gangs other fake doomsdays of "gigabytes by midnight" "visa by tomorrow"
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.

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

8mb upper limit and 2mb lower (dynamic) limit.
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?

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 08:20:26 PM
if you want a private conversation between 2 people then go to Private message with them
You need to visit some courses in order to improve your faulty comprehension skills. We can discuss whenever we want and wherever we want.

even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.

are you forgetting the example of dynamics . i even drew you a picture to keep your concentration span open
No. I'm asking you for the specifics of your proposal, but there are none apparently.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 08:22:20 PM
even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 08:23:52 PM
even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
Core deemed "8 MB network safe"? Where?
Segwit 8 MB weight safe != 8 MB block size limit safe.
So what is the technical reason for this to be the case?
For one (ignoring everything else): Linear sigops validation vs. quadratic validation.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 08:29:23 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 08:35:44 PM
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.
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).

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
That.. doesn't actually solve it IIRC. Have you actually proposed this somewhere/done calculations or did you pull 16k out of thin air?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 08:38:28 PM
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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 08:39:46 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 08:43:43 PM
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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 08:47:51 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 08:52:22 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 08:53:55 PM
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 08:56:01 PM
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).

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 08:58:22 PM
-snip-
nothing stops a native tx from sigops spamming
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.

If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good.
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 09:00:26 PM
-snip-
nothing stops a native tx from sigops spamming
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 09:12:44 PM
-snip-
nothing stops a native tx from sigops spamming
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.

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?

If segwit was implemented as a hard fork, could the transaction malleation and quadratic sigops spam attack be solved for good.
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.

So does this mean a soft fork bypasses consensus?

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

Does flextrans require a new address key type as well?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 11, 2017, 09:14:39 PM
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.
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. ;)

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. [...]
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.
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.

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

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).
Edit: What upper limit would you consider realistic?
In what time frame? Next 5, 10 years?
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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 09:31:54 PM
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
Are you trying to say that Bitcoin can be DOS'ed at 1 MB now? ::)

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?
No. You can refuse to use Segwit if you do not want to.

So does this mean a soft fork bypasses consensus?
No. Soft forks are backwards compatible, therefore mitigating the risk of a network split.

Does flextrans require a new address key type as well?
Yes.
I believe Bitcoin's value comes mainly from its usability ....
 But that could lead to a long discussion, so here in this thread, let's focus on the block size issue. ;)
It sounded like I was talking to Roger Ver for a second, but okay.

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.
Then encourage it, but don't spread it around like it is trivial until we know for 'sure'.

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).
Noted. My bad.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 11, 2017, 09:38:51 PM
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?

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 11, 2017, 09:45:37 PM
So does this mean a soft fork bypasses consensus?
No. Soft forks are backwards compatible

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 10:15:09 PM
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.
I've asked for a refreshment about 'parallel validation':
Quote
<harding> many miners currently mine empty blocks on top of unvalidated (but PoW-correct) new blocks.  There's no reason to expect them to behave differently under BTU, so most miners would probably extend the chain with the high-validation-work block rather than create an alternative block at the same height.
<harding> Thus parallel validation doesn't get you anything unless a low-validation-work block is coincidentally produced at the same time as a high-validation-work block.
<harding> parallel validation only helps you in the rare case that there are two or more blockchains with the same PoW.  Miners are disincentivized to create such chains since one of them is certain to lose, so the incentives probably favor them extending a high-validation-work block rather than creating a competing low-validation-work block.
<harding> Imagine block A is at the tip of the chain.  Some miner than extends that chain with block B, which looks like it'll take a long time to verify.  As a miner, you can either attempt to mine block C on top of block B, mining without validation but creating chain ABC that certainly has the most PoW.  Or you can mine block B' that is part of chain AB' that will have less PoW than someone who creates chain ABC.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 10:18:52 PM
So does this mean a soft fork bypasses consensus?
No. Soft forks are backwards compatible

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 11, 2017, 10:19:48 PM
Let's say 5 years, 10 years maybe is too far away.
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 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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 10:25:23 PM
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
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.  ::)

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 10:28:23 PM
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
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 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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 10:33:48 PM
So does this mean a soft fork bypasses consensus?
No. Soft forks are backwards compatible

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 10:35:53 PM
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.

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
check the code
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 10:37:42 PM
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 11, 2017, 10:39:25 PM
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.
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. ::)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 11, 2017, 11:02:17 PM
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 11, 2017, 11:14:06 PM
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

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
Quote
Treat high-sigop transactions as larger rather than rejecting them

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 11, 2017, 11:20:02 PM
So does this mean a soft fork bypasses consensus?
No. Soft forks are backwards compatible

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.

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 11, 2017, 11:30:33 PM
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 11, 2017, 11:44:17 PM
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.
I've asked for a refreshment about 'parallel validation':
Quote
<harding> many miners currently mine empty blocks on top of unvalidated (but PoW-correct) new blocks.  There's no reason to expect them to behave differently under BTU, so most miners would probably extend the chain with the high-validation-work block rather than create an alternative block at the same height.
<harding> Thus parallel validation doesn't get you anything unless a low-validation-work block is coincidentally produced at the same time as a high-validation-work block.
<harding> parallel validation only helps you in the rare case that there are two or more blockchains with the same PoW.  Miners are disincentivized to create such chains since one of them is certain to lose, so the incentives probably favor them extending a high-validation-work block rather than creating a competing low-validation-work block.
<harding> Imagine block A is at the tip of the chain.  Some miner than extends that chain with block B, which looks like it'll take a long time to verify.  As a miner, you can either attempt to mine block C on top of block B, mining without validation but creating chain ABC that certainly has the most PoW.  Or you can mine block B' that is part of chain AB' that will have less PoW than someone who creates chain ABC.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: LazyTownSt on March 11, 2017, 11:45:17 PM
This is a massive issue. Im surprised at the lack of votes so far


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 11, 2017, 11:59:29 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 08:14:23 AM
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)
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).

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.
No. It does not destroy fungibility.

End result: Harding's concern is irrelevant. The quadratic hash time problem solves itself. No change to the protocol needed.
Definitely; everyone is a honest actor in this network and we are all living on a rainbow. ::)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 12, 2017, 09:08:33 AM
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.
No. It does not destroy fungibility.

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

Quote
End result: Harding's concern is irrelevant. The quadratic hash time problem solves itself. No change to the protocol needed.
Definitely; everyone is a honest actor in this network and we are all living on a rainbow.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 09:19:03 AM
Do you understand that 'fungibility' is the property that no units of a thing have differing characteristics from other units?
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?

Way to make a technical rebuttal, Lauda. You're certainly on your game tonight.
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AliceWonderMiscreations on March 12, 2017, 09:24:44 AM
Do you understand that 'fungibility' is the property that no units of a thing have differing characteristics from other units?
So for you, being part of UTXO vs Segwit UTXO is an adequate characteristic to destroy fungibility?

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 12, 2017, 09:29:22 AM
Do you understand that 'fungibility' is the property that no units of a thing have differing characteristics from other units?
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 think you are on the verge of understanding that issue.

Quote
Way to make a technical rebuttal, Lauda. You're certainly on your game tonight.
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.

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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 09:32:34 AM
That isn't disputed by most SegWit supporters.
Source?

I think you are on the verge of understanding that issue.
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. ::)

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 12, 2017, 12:27:45 PM
-snip-
nothing stops a native tx from sigops spamming
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.

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

Code:
/** The maximum weight for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_WEIGHT = 400000;

policy.cpp

Code:
   // Extremely large transactions with lots of inputs can cost the network
    // almost as much to process as they cost the sender in fees, because
    // computing signature hashes is O(ninputs*txsize). Limiting transactions
    // to MAX_STANDARD_TX_WEIGHT mitigates CPU exhaustion attacks.
    unsigned int sz = GetTransactionWeight(tx);
    if (sz >= MAX_STANDARD_TX_WEIGHT) {
        reason = "tx-size";
        return false;
    }

net_processing.cpp

Code:
   // Ignore big transactions, to avoid a
    // send-big-orphans memory exhaustion attack. If a peer has a legitimate
    // large transaction with a missing parent then we assume
    // it will rebroadcast it later, after the parent transaction(s)
    // have been mined or received.
    // 100 orphans, each of which is at most 99,999 bytes big is
    // at most 10 megabytes of orphans and somewhat more byprev index (in the worst case):
    unsigned int sz = GetTransactionWeight(*tx);
    if (sz >= MAX_STANDARD_TX_WEIGHT)
    {
        LogPrint("mempool", "ignoring large orphan tx (size: %u, hash: %s)\n", sz, hash.ToString());
        return false;
    }

wallet.cpp

Code:
       // Limit size
        if (GetTransactionWeight(wtxNew) >= MAX_STANDARD_TX_WEIGHT)
        {
            strFailReason = _("Transaction too large");
            return false;
        }

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








Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 12:55:19 PM
I'd like to understand the reason spamming with native keys is useless after segwit activation.
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 12, 2017, 01:01:03 PM
I'd like to understand the reason spamming with native keys is useless after segwit activation.
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.


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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 01:03:07 PM
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) -> No lower risk (quadratic hashing); the same as the first line.

Is that a fair FTFY?
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).


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 12, 2017, 01:06:39 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 01:10:13 PM
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
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.

As core not done any research on this then?
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 12, 2017, 01:15:53 PM
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
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 think I misunderstood the below and thought you was talking about a post segwit block size increase.

Quote
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 01:18:19 PM
I think I misunderstood the below and thought you was talking about a post segwit block size increase.

Quote
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 12, 2017, 01:23:10 PM
I think I misunderstood the below and thought you was talking about a post segwit block size increase.

Quote
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 01:25:34 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Xester on March 12, 2017, 01:26:21 PM
I think I misunderstood the below and thought you was talking about a post segwit block size increase.

Quote
3) 2 MB post Segwit (implies almost 100% Segwit usage) -> No DoS risk (linear hashing).

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 12, 2017, 01:30:00 PM
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 12, 2017, 01:55:41 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AliceWonderMiscreations on March 12, 2017, 02:31:09 PM
That isn't disputed by most SegWit supporters.
Source?

Quote
The existence of two UTXO types with different security and economic properties also deteriorates Bitcoin’s fungibility. Miners and fully validating nodes may decide not to relay, or include in blocks, transactions that spend to one type or the other. While on one hand this is a positive step towards enforceability (i.e. soft enforceability), it is detrimental to unsophisticated Bitcoin users who have funds in old or non-upgraded wallets. Furthermore, it is completely reasonable for projects such as the lightning network to reject forming bidirectional payment channels (i.e. a multisignature P2SH address) using non-SW P2SH outputs due to the possibility of malleability. Fundamentally this means that the face-value of Bitcoin will not be economically treated the same way depending on the type of output it comes from.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: spooderman on March 12, 2017, 03:35:09 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 12, 2017, 03:51:04 PM
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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: -ck on March 12, 2017, 04:12:09 PM
As core not done any research on this then?
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.
https://rusty.ozlabs.org/?p=522


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 12, 2017, 05:34:58 PM
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)

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 12, 2017, 05:40:48 PM
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)
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.





Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 12, 2017, 05:44:56 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 05:47:16 PM
So what is the definition of weight, and how does this relate to data storage requirements?
You should research Segwit yourself. I don't plan on rewriting what is already written in a lot of articles. Use Google.

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

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

thus a native key user can with just 5 tx stop other tx's getting in. and thus all segwit promises cant be met.
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).

so effectively.. what does segwit actually offer that is a real feature that has real 100% guarantee promise
Miners can prioritize Segwit transactions (e.g. 20% vs. 80%). Simple solution.

https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179#.mt4mf9jjh
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.

https://rusty.ozlabs.org/?p=522
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.

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.
Without adequate consensus (this being a economic super majority and 95% of the network), it does harm every part of the ecosystem.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 12, 2017, 05:47:30 PM
That isn't disputed by most SegWit supporters.
Source?

I think you are on the verge of understanding that issue.
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.

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.

Quote
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?
I just quickly went through it and saw your conclusion.

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

Quote
I'm not going to be a messenger between you and someone with clearly superior understanding. Find a way to contact him yourself.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 12, 2017, 05:55:31 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 05:55:50 PM
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)
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.

Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday
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.

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

IOW, you are happy to wallow in your ignorance. ::sigh:: Oh well - it certainly would not be a first.
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 don't need to contact him. You are the one that appealed to his supposed authority.
I barely know who the person is. Stop using logical fallacies when you are clearly not adequately educated to properly do so.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 12, 2017, 06:17:49 PM
Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 06:20:05 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 12, 2017, 06:21:26 PM
https://bitcointalk.org/index.php?topic=1823233.0


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AliceWonderMiscreations on March 12, 2017, 06:27:09 PM
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.

Do you have any scientific research to back this up?

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 07:02:10 PM
https://bitcointalk.org/index.php?topic=1823233.0
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 12, 2017, 07:31:24 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 07:38:40 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 12, 2017, 07:42:36 PM
You've changed your tune

Explain how Segwit makes "everything" worse


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 07:43:48 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 12, 2017, 07:44:40 PM
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)
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).

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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 07:50:53 PM
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.
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).

But for me, we can also modify the scale by:
1) first year, only Segwit + 1 MB upper bound (no modifications)
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 12, 2017, 08:03:16 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 12, 2017, 08:11:16 PM
Oh, you were too fast to answer, I just had edited the post to clarify a bit ;)
Yeah, sometimes I can be quite fast.

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.
Okay so for the first year we only use Segwit and the size it brings on its own.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 13, 2017, 08:09:09 PM
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).


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: hv_ on March 13, 2017, 08:34:01 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 13, 2017, 10:24:37 PM
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:

Quote
BU has no miner threshold for activation
BU has no grace period to allow nodes to upgrade
BU has no checkpoint (AKA wipe-out protection), therefore users could lose funds
BU has no replay attack prevention
https://www.reddit.com/r/Bitcoin/comments/5z6d56/a_summary_of_bitcoin_unlimiteds_critical_problems/


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Searing on March 13, 2017, 11:41:30 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 13, 2017, 11:47:44 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 14, 2017, 12:04:01 AM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Swimmer63 on March 14, 2017, 12:13:18 AM
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 12:15:28 AM
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.
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.

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.

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

this 'effective potential' can be inhibited(prevented) by atleast 5 attack vectors that can stop segwit ever getting any effective increase in tx counts
The SAME can be done with BTU. ::) ::)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 14, 2017, 01:35:05 AM
this 'effective potential' can be inhibited(prevented) by atleast 5 attack vectors that can stop segwit ever getting any effective increase in tx counts
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..


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 06:51:41 AM
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.
I've already told you that you can easily prioritize Segwit transactions over native ones as a miner.

vs BU, classic, xt (and other real-block growth proposals)
2mb baseblock means it requires twice as much effort..
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 07:40:32 AM
What I'm thinking is there will never be consensus.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: mezzomix on March 14, 2017, 07:42:40 AM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 08:14:59 AM
I'm fine with segwit + 2MB.

Which is not what's being proposed


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 08:29:22 AM
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
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.

You can all fuck off with your "2MB" compromise, which has taken less than 12 pages to warp itself into 12MB  ::)
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.

Quote
Lauda in particular, you should know better than this by now, which makes me question your intentions towards the whole issue to begin with
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).


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: RawDog on March 14, 2017, 08:43:14 AM
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.
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.
SegWit is the altcoin


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 08:44:19 AM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: hv_ on March 14, 2017, 08:55:29 AM
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.
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.
SegWit is the altcoin

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 ?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 09:17:02 AM
SegWit is the altcoin
No, that is not the case with a SF.

Your behaviour is being attacked, not your character (seriously, you're now reaching for the bed-wetting "ad-hom" rhetoric)
My bad; still sub optimal at this time of day.

Quote
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".
Saying that X MB is acceptable in Y time frame != aon-chain scaling works. I haven't claimed this to be the case either.

Quote
Now, that's a sudden change in your behaviour, not your character, your character was clearly always prone to hypocrisy and conceit.
And there it is. Is this your way of handling things when someone has a different stance on a matter?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 09:25:16 AM
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


Quote
Now, that's a sudden change in your behaviour, not your character, your character was clearly always prone to hypocrisy and conceit.
And there it is. Is this your way of handling things when someone has a different stance on a matter?

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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 09:28:33 AM
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
Following your own logic, by supporting Segwit (2/4MB maximum) you are stating the same, i.e. saying on-chain scaling works. Sigh.

Proving them wrong? Why yes, when they are wrong, that's what one does
You can do that without attacking character/behavior or whatever.

Quote
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?
Untrue. I am not selling anything. Bitcoin Core roadmap has a dynamic block size/flexcaps down the road AFAIK.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 09:30:34 AM
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
Following your own logic, by supporting Segwit (2/4MB maximum) you are stating the same, i.e. saying on-chain scaling works. Sigh.

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

Proving them wrong? Why yes, when they are wrong, that's what one does
You can do that without attacking character/behavior or whatever.

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

Quote
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?
Untrue. I am not selling anything. Bitcoin Core roadmap has a dynamic block size/flexcaps down the road AFAIK.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 09:33:04 AM
More Franky style lying by omission
Should I rename myself to Franky2? ::)

Quote
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
So your position is what exactly, 2 MB (Segwit) and layer 2 only?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 09:39:12 AM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 09:41:21 AM
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)?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: hv_ on March 14, 2017, 09:46:33 AM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 09:48:37 AM
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)?

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? ::)




Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 14, 2017, 10:40:26 AM
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. 


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 10:43:59 AM
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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 14, 2017, 11:26:36 AM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 11:32:05 AM
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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 14, 2017, 12:14:54 PM
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. 



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 02:09:36 PM
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)?
You're attempting a false premise right off the bat
[/quite]
No, I am merely asking a question.

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
That's not what my question to you is about. I'm asking whether you'd accept a one time increase or some sort of dynamic size with the top limit being what we known is safe at some point in time? I'm not asking about any long term plans.

What happens if the global internet infrastructure deteriorates in bandwidth or connectivity over that timeframe? ::)
What happens if it does so heavily that even Segwit is too much? Hm.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Qatuca on March 14, 2017, 02:12:39 PM
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)?

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? ::)


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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 05:14:27 PM
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)?
You're attempting a false premise right off the bat
No, I am merely asking a question.

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

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
That's not what my question to you is about. I'm asking whether you'd accept a one time increase or some sort of dynamic size with the top limit being what we known is safe at some point in time? I'm not asking about any long term plans.

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

What happens if the global internet infrastructure deteriorates in bandwidth or connectivity over that timeframe? ::)
What happens if it does so heavily that even Segwit is too much? Hm.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 14, 2017, 06:26:50 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 06:28:00 PM
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
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.

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
Why stop there? 1 MB might be way too much as well. I don't like this argument one bit.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 14, 2017, 06:30:29 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 06:48:29 PM
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
Why stop there? 1 MB might be way too much as well. I don't like this argument one bit.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 14, 2017, 07:12:13 PM
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 going to invest in a factory that makes 56kbit line modems.
I'm prepping Enigma 2.0. ::)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 07:17:16 PM
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 going to invest in a factory that makes 56kbit line modems.
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 14, 2017, 08:39:19 PM
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
Why stop there? 1 MB might be way too much as well. I don't like this argument one bit.

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?

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



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 08:47:29 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 14, 2017, 08:55:45 PM
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 ?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 14, 2017, 09:07:54 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 14, 2017, 09:29:39 PM
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 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"


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AliceWonderMiscreations on March 14, 2017, 10:32:39 PM
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.


My slide rule doesn't need batteries.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 15, 2017, 04:49:53 AM
@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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 15, 2017, 06:45:07 AM
@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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 15, 2017, 07:22:45 AM
-snip-
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 15, 2017, 10:13:21 PM
How are we going to use mesh nets to cross the oceans? (which was the crux of my point anyway)

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.

Quote
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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 15, 2017, 10:41:58 PM
How are we going to use mesh nets to cross the oceans? (which was the crux of my point anyway)

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.

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?


Quote
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

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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 16, 2017, 09:40:58 AM
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"

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

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

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

Quote
Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork
Quote
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

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

Quote
Why not explore the possibility of decreasing the block interval target FIRST, which is also a hard fork
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: kiklo on March 16, 2017, 10:04:51 AM
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)?

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? ::)


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

 


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 16, 2017, 10:17:13 AM
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"

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

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



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

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

Quote
Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork
Quote
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

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

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.


Quote
Why not explore the possibility of decreasing the block interval target FIRST, which is also a hard fork
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: kiklo on March 16, 2017, 10:23:45 AM
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)




Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 16, 2017, 06:35:50 PM
My argument is that diplomatic tension is rising between the states that adjoin the South China Sea.

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.

Quote
Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork
Quote
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

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

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

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

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:

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.

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

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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 16, 2017, 06:41:04 PM
-snip-
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: hv_ on March 16, 2017, 07:09:31 PM
-snip-
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 16, 2017, 08:33:48 PM
My argument is that diplomatic tension is rising between the states that adjoin the South China Sea.

OK. I don't believe it will happen

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


Why not improve the efficiency of transaction encoding FIRST, which is also a hard fork
Quote
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

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

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


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


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

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:

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.

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

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.


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

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.


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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 16, 2017, 09:48:41 PM
Quote
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.

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:

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.

Quote
I'm suggesting, without stating opinions as fact, that Segwit's 4MB IS the compromise solution.

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?

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

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.

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 16, 2017, 10:03:51 PM
And you seem to have STILL not read the following sentence:

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.

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


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.

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.

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

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?

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 16, 2017, 11:32:48 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: kiklo on March 17, 2017, 12:05:50 AM
-snip-
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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 17, 2017, 08:44:41 AM
So your position is basically: The miners are totally wrong. So let's ignore the miners. Not very constructive.

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



and I think 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).


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



I don't care if a transaction capacity increase is achieved with bigger blocks or other measures.


Well, you could've fooled me.



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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: DooMAD on March 17, 2017, 03:16:08 PM
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.

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!   ::)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 17, 2017, 03:37:11 PM
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.  ;)

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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 17, 2017, 04:03:10 PM
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.

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.


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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 17, 2017, 04:05:41 PM
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.  ;)

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

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. 


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on March 17, 2017, 04:08:04 PM
@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.




Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 17, 2017, 04:11:57 PM
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.
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..


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 17, 2017, 04:14:32 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 17, 2017, 04:16:22 PM
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.
no
id scream centralisation..
one source one brand.. is still centralisation.

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.

Quote
i would rather there be 10 different codebases of a node. not 2 and not 1

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 17, 2017, 05:25:34 PM
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.
no
id scream centralisation..
one source one brand.. is still centralisation.

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.
agreed. never said the opposite

i would rather there be 10 different codebases of a node. not 2 and not 1

That doesn't change the fact that if you have only one pool,
???
...
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:
diversity(different code bases and even wrote in different languages (go, ruby, java, c#))  and more than one option is decentralisation..


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: DooMAD on March 17, 2017, 05:45:49 PM
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.

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

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.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 17, 2017, 05:59:39 PM
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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 17, 2017, 07:49:18 PM
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: kiklo on March 18, 2017, 04:55:30 AM
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

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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 18, 2017, 01:52:08 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 18, 2017, 02:27:21 PM
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.  ;)
That is not Segwit, that is LN. You are confusing two completely different things.

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 version didn't gather much support if any. Bitcoin scales very inefficiently on the first layer, that's why it requires a secondary layer.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 18, 2017, 03:15:49 PM
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 )


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 18, 2017, 03:29:52 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 18, 2017, 03:38:46 PM
load of waffle about ifs and maybes of a centralised network..
blah blah

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 18, 2017, 03:46:29 PM
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].

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Variogam on March 18, 2017, 04:27:22 PM
BitcoinEC: SegWit + Emergent Consensus - Already *praised* by ViaBTC (see here: https://twitter.com/ViaBTC/status/842748341767290880) [1].
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 18, 2017, 04:52:40 PM
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/
Quote
Will you also have an AD(Accept Depth) parameter like Bitcoin Unlimited?

Instead of Accept Depth we will implement a warning system to alert users if they are not on the longest chain. Implementing AD in the way BU has done appears to be fairly complicated and hard to do correctly, a warning system is simple since we only need the block headers for that.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 18, 2017, 05:23:57 PM
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
What makes you think 'blocktracker' is Barry Silbert? That's a weird statement.

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
There's nothing to peer review yet. People are advocating for the idea.



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 18, 2017, 06:03:56 PM
load of waffle about ifs and maybes of a centralised network..
blah blah

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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 18, 2017, 06:08:21 PM
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.

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

Quote
consensus is the mechanism that self regulates the network by majority consent .

Majority of proof of work.

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

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



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Latreetim on March 18, 2017, 06:14:00 PM
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 18, 2017, 06:50:24 PM
more waffle

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 18, 2017, 07:23:03 PM
more waffle

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

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.

Quote
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'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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 18, 2017, 07:49:04 PM
waffle

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 19, 2017, 04:16:33 AM
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.

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.



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Searing on March 19, 2017, 04:59:15 AM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 19, 2017, 05:23:38 AM
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

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.



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 19, 2017, 08:38:12 AM
I'm absolutely not convinced that miners showing support for BU actually want BU.

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

Quote
Also, forking at 51% would be extremely risky

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Cashew on March 19, 2017, 08:51:27 AM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: BitUsher on March 19, 2017, 11:59:46 AM
When the largest ASIC manufacturer is making threats like this -

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

Quote from: Jihan
I found that the HF future contract of Bitfinex is very unfair against big blocker. 2 support BU supporter, HF should be accelerated.

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



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: paul gatt on March 19, 2017, 12:04:40 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: BitUsher on March 19, 2017, 12:11:18 PM
ETH is a typical example, it has taken breakthrough development, which is essential for bitcoin.

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


Quote from: Andreas M. Antonopoulos
I just spent the last 8 months working on the second edition of Mastering Bitcoin and I couldn’t even scratch the surface of all the innovation that is happening in BTC. You don’t see it? You’re not looking.

The idea that Bitcoin is stale and that Ethereum will come to the rescue without stumbling on all the same milestones of growth that Bitcoin has overcome is a fiction.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Xester on March 19, 2017, 12:11:36 PM
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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: DooMAD on March 19, 2017, 01:18:01 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: freebutcaged on March 19, 2017, 01:37:44 PM
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?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Tigggger on March 19, 2017, 01:46:37 PM
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 19, 2017, 01:53:50 PM
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?

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)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 20, 2017, 01:17:37 PM
Wonder whether people consider this to be a good compromise solution:

https://bitcoinec.info/


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 20, 2017, 01:28:09 PM
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.

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 20, 2017, 01:34:58 PM
Wonder whether people consider this to be a good compromise solution:

https://bitcoinec.info/

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 20, 2017, 02:45:06 PM
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.

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 20, 2017, 03:08:13 PM
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.

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

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



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 20, 2017, 03:21:19 PM
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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 20, 2017, 03:45:29 PM
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.




Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 20, 2017, 04:11:59 PM
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 ::)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Shiver on March 20, 2017, 06:10:50 PM
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.



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 20, 2017, 08:29:20 PM
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 ;)

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. 

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

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.

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

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 ?

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

It is my way to build my own understanding.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 20, 2017, 08:41:24 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 20, 2017, 08:42:45 PM
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

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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 20, 2017, 09:05:41 PM
Significant changes to the Bitcoin protocol were soft-forked into the coin only last year, and in 2015, and in 2014

As I said, soft forks are not protocol changes, but protocol restrictions.  
There is BIP 66, BIP 65, BIP 34, BIP 30 and BIP 16

BIP 34 was about the version number of blocks and from 2012 (still the cheap years of bitcoin)

BIP 65 introduced a new instruction in the bitcoin instruction OPcodes

BIP 66 solved an ambiguity concerning OPENSSL

All these things are just technical aspects, soft forks, and do not affect in the slightest bit the usual way of how people use bitcoin economically.  I even don't think that these aspects are much used.  All of them have only been activated with 95% consensus which was easily established.  You can hardly say that they modify the original protocol in its way of working.

These are technical improvements that don't affect what people actually do with bitcoin, they don't affect the economics of fees, rewards, and so on.

In other words, they were not "significant changes".  Most people would never notice.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: jbreher on March 21, 2017, 01:00:46 AM
But the protocol IS the coin. 

Well, no. In addition to the protocol, the coin is also the ledger.

I don't believe you are right on your immutability claim. Plate tectonics may be analogous. Two forces are working in opposition. As the stresses get higher and higher, eventually something snaps, and a new equilibrium is formed.

Hey - it's an analogy, not a model.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 21, 2017, 10:50:02 AM
But the protocol IS the coin.  

Well, no. In addition to the protocol, the coin is also the ledger.

Yes, you're right.  I meant to say that if you fundamentally change the protocol, you have a different coin.  But of course, if you start a new chain, you ALSO have a new coin, as you correctly point out.

Quote
I don't believe you are right on your immutability claim. Plate tectonics may be analogous. Two forces are working in opposition. As the stresses get higher and higher, eventually something snaps, and a new equilibrium is formed.

My idea is: where does immutability even come from ?  Why should people join a system of which the rules can arbitrarily change ?  Would you buy a coin of which chances are that tomorrow, "a majority" votes that you don't own that coin any more ?  Would you trade value for transactions that can be undone the very next day "by majority" ?

Even though in principle, any consensus mechanism can change just anything, any time, you would EXPECT that the basic rules you subscribed to when entering the system, are "enforced" by some mechanism, no ?

But as that "mechanism" has no centralized leadership, and is to be trustless, it cannot have any "moral decision power".  It cannot distinguish which changes are in fact "good", and which changes are "bad".   So there *must be a mechanism that enforces stability of the rules*.  That mechanism is what guarantees immutability.  If you don't think that such a mechanism is at work, you must presume that there are only 2 possibilities:

1) there is a central form of authority, that will distinguish good from bad ; for instance, a genuine majority vote inspired by charismatic leadership IN WHICH YOU HAVE TO HAVE TRUST

2) anything can happen any moment, and your holdings, transactions, whatever, can and will change in an ARBITRARY way any moment.

In 1) you don't have a decentralized, trustless system.  You have something very similar to normal banking.
In 2), you have a totally arbitrary system that is unstable.  Impossible to generate any reasonable monetary belief.

My idea is that 1) is possible, but that there IS a mechanism at work: decentralized antagonism.  No antagonist is strong enough, and can find enough collusion, to get HIS changes imposed by majority.  No majority can be reached over anything else but status quo on IMPORTANT (economical) aspects of the system, simply because there are different ways to change the system and too many different antagonists which are not colluding and have no common leadership (= my definition of "decentralized").

As such, only status quo can have a majority "vote" by so many non-colluding antagonists.  This is the cause of immutability, and the fundamental property that can make decentralized trustless systems develop monetary belief.

If there is a majority that imposes change, it means that the system was centralized under leadership.

However, you are right that hard forks (new coin creation) can be performed by just any antagonist.  In that case, people vote in the market: but this is not "leadership".  Any antagonist, no matter how small, can do this, and the success of his modification emerges in the market, leaderless.  The old system, however, remains immutable.  (but can die)



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 23, 2017, 01:20:49 PM
There is a pool on biggest Polish bitcoin forum:
https://forum.bitcoin.pl/viewtopic.php?f=2&t=20768

Q: "What road of Bitcoin development you support?"
User can pick up to two options from:
- SegWit
- Bitcoin Unlimited
- one time to 2MB
- one time to 4MB or more
- adaptive block size
- reduce to 0.5MB
- leave 1MB


https://i.snag.gy/WafkUF.jpg


I think, there is clear how it looks there.
Team Core should merge block size raise along witch SegWit. Time is NOW.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 23, 2017, 02:25:53 PM
User can pick up to two options from:
- SegWit
- Bitcoin Unlimited
- one time to 2MB
- one time to 4MB or more
- adaptive block size
- reduce to 0.5MB
- leave 1MB


https://i.snag.gy/WafkUF.jpg


I think, there is clear how it looks there.
Team Core should merge block size raise along witch SegWit. Time is NOW.



I don't think Core will do that.


rav3n, why do you refuse to understand that blocksize is a very dangerous value to change? The world is becoming a more dangerous place every day, we can't rely on the internet growing the same way it did 1990-2015. It might very plausibly become much slower and more restricted, that is a very serious risk, and not just to Bitcoin.

We can achieve on-chain scaling by making the transactions smaller, or other more intelligent ways. Blocksize changes are stupid when those things do more with less blockspace.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 23, 2017, 02:45:32 PM
-snip-
I think, there is clear how it looks there.
Team Core should merge block size raise along witch SegWit. Time is NOW.
This doesn't make sense; Bitcoin is not a democracy and random individuals with no demonstrably relevant knowledge should not be deciding on technological solutions/limitations. How are certain groups unable of understanding something this simple?

I don't think Core will do that.
There isn't a very good proposal for an adaptive block size at the moment (IMO).

rav3n, why do you refuse to understand that blocksize is a very dangerous value to change? The world is becoming a more dangerous place every day, we can't rely on the internet growing the same way it did 1990-2015. It might very plausibly become much slower and more restricted, that is a very serious risk, and not just to Bitcoin.
Whilst I do not like doomsday scenarios, your argument is not without merit. As can be observed, NATO moving forces to Estonia & surrounding area to "combat Russian aggression", China warning US to respect airspace, etc. Things may not be as good tomorrow as they are today.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 23, 2017, 03:01:23 PM
-snip-
I think, there is clear how it looks there.
Team Core should merge block size raise along witch SegWit. Time is NOW.
This doesn't make sense; Bitcoin is not a democracy and random individuals with no demonstrably relevant knowledge should not be deciding on technological solutions/limitations. How are certain groups unable of understanding something this simple?

The Enlightened King.

https://en.wikipedia.org/wiki/Republic_(Plato)



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 23, 2017, 03:05:44 PM
rav3n, why do you refuse to understand that blocksize is a very dangerous value to change? The world is becoming a more dangerous place every day, we can't rely on the internet growing the same way it did 1990-2015. It might very plausibly become much slower and more restricted, that is a very serious risk, and not just to Bitcoin.
Whilst I do not like doomsday scenarios, your argument is not without merit. As can be observed, NATO moving forces to Estonia & surrounding area to "combat Russian aggression", China warning US to respect airspace, etc. Things may not be as good tomorrow as they are today.

Lauda, I'm breathing a sigh of relief over here. You've always been reasonable IMO, and I'm glad you're seeing sense in what I'm saying.


The truth is: who knows what might happen? It's not at all impossible that geopolitical tensions, and the myriad of threats they pose to the smooth running of and accessibility to the internet, could calm right down tomorrow to negligible levels. But if we really want to keep this network alive, we should be as careful as possible, and that means planning for all plausible possibilities.

Bitcoin might be a big part of what solves geopolitical tensions. It can't do that on it's own, more innovations will be needed. But a free & sound money system for all would be the bedrock or the foundation to keeping the world turning in a co-operative and healthy way, the only way to defeat the trends that take us in the opposite direction.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 23, 2017, 03:24:57 PM
Friendly reminder: Satoshi introduced 1MB limit ONLY as PROTECTION form spam attack on network. It was like 10-100x higher than block sizes.
From year+ now this limit is NOT working as protection at all. There is just "too many" transactions to fit in 1MB.
Block transmission is now done by header/gentx/tx list, not as full block data.
Block pruning allow run full node on about 20GB HDD space.
1MBit connection allow to transfer over 100tx/s (1:4 in/out), block can be like 15MB on that connection.
There is NO technological problem to make bigger blocks.
When SegWit start it probably will take another year to popularize SW transactions, LN and/or sidechains.
Think, how it is possible that "better" idea as SegWit have LESS support in miners than "worse" BU? Why over 30% is not decided?
IF Core merge ANY code that raise block limit along witch SegWit, it will get 95% in no time. If not - I (and not only I) see no chance to activate SegWit.
We just run out of time...


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 23, 2017, 03:30:24 PM
We can achieve on-chain scaling by making the transactions smaller, or other more intelligent ways. Blocksize changes are stupid when those things do more with less blockspace.

and once segwit activates with the hope of getting all them 46m UTXO over to segwit keys to get to the possible tx count(without spam attacking to reduce) of ~4500tx/block... then what

you cant resegwit a segwit to double up again..

oh and the 1mb limit was about limiting bloat

but think rationally

segwits 2.1mb of full data is still 2.1mb of data...
its not 1mb data. its 2.1mb data.

(eg if the 'internet cant cope with 2mb' then the internet cant cope with 2mb)

pretending segwit helps FULL nodes by keeping a 1mb block limit. is not the truth a FULL node is handling 2.1mb
the 1mb is for old now lite clients that might aswell just be SPV clients. segwit isnt helping FULL nodes


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 23, 2017, 03:58:23 PM
segwits 2.1mb of full data is still 2.1mb of data...
its not 1mb data. its 2.1mb data.
Exactly.
https://testnet.smartbit.com.au/block/00000000000016a805a7c5d27c3cc0ecb6d51372e15919dfb49d24bd56ae0a8b
Is this block 40kB or 3,7MB? It take 40kB of storage/transmission or 3,7MB storage/transmission?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 23, 2017, 04:00:33 PM
segwits 2.1mb of full data is still 2.1mb of data...
its not 1mb data. its 2.1mb data.
Exactly.
https://testnet.smartbit.com.au/block/00000000000016a805a7c5d27c3cc0ecb6d51372e15919dfb49d24bd56ae0a8b
Is this block 40kB or 3,7MB? It take 40kB of storage/transmission or 3,7MB storage/transmission?
3.7 MB for full nodes. This is why Segwit may also be *too much* in the worst case scenarios. Your understanding is very flawed, therefore saying 'exactly' has zero meaning. I'll address your previous post & others soon.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 23, 2017, 04:03:24 PM
Friendly reminder: Satoshi introduced 1MB limit ONLY as PROTECTION form spam attack on network. It was like 10-100x higher than block sizes.
From year+ now this limit is NOT working as protection at all. There is just "too many" transactions to fit in 1MB.

I have a friendly reminder for you.


Are bigger blocks the only way to increase on-chain capacity? No

Are bigger blocks the most dangerous way to increase on-chain capacity? Yes


Would improving the efficiency of how we use the blocksize that already exists be safe, add more capacity and actually improve Bitcoin's scaling? Yes


@rav3n: Why don't want you want safe capacity increases? Why don't you want true on-chain scaling?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 23, 2017, 04:17:02 PM
Are bigger blocks the only way to increase on-chain capacity? No
But fastest to achieve and easy to code/implement.

Quote from: Carlton Banks
Are bigger blocks the most dangerous way to increase on-chain capacity? Yes
No, can`t agree.

Quote from: Carlton Banks
Would improving the efficiency of how we use the blocksize that already exists be safe, add more capacity and actually improve Bitcoin's scaling? Yes
These is no way to make it NOW. It should be done YEAR ago.

Quote from: Carlton Banks
@rav3n: Why don't want you want safe capacity increases? Why don't you want true on-chain scaling?
It is impossible to make it. It is easy to calculate. On-chain scaling is a myth.

As for NOW upgrade to 2MB block will unload mempool in about week, bot we don`t know how long it last. This why I see adaptive block size as best option. Do once and forget. Like diff is working now.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: David Rabahy on March 23, 2017, 04:26:07 PM
Which is the more desirable outcome; one currency or two?  If two then finish the war and split off already -- I know, I know, who gets to claim the legacy.  If one then a compromise (no matter how dangerous, etc.) will have to be entered; hurry.  Given human nature (righteousness) I have lost confidence in this approach.

To me it seems like maybe three currencies could be the way forward;

1) bitcoin as it is running right now; it gets the legacy but with no development team to love it
2) SegWit, a new wonderful currency with loads of followers and a strong development team
3) the bigger/dynamic/adaptive block guys, a new wonder currency with loads of followers and a spirited development team

There really is only one legacy, right?  We can't have two currencies both considered to be the proper descendent of the original Bitcoin, right?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 23, 2017, 04:34:02 PM
Which is the more desirable outcome; one currency or two?  If two then finish the war and split off already -- I know, I know, who gets to claim the legacy.  If one then a compromise (no matter how dangerous, etc.) will have to be entered; hurry.  Given human nature (righteousness) I have lost confidence in this approach.

To me it seems like maybe three currencies could be the way forward;

1) bitcoin as it is running right now; it gets the legacy but with no development team to love it
2) SegWit, a new wonderful currency with loads of followers and a strong development team
3) the bigger/dynamic/adaptive block guys, a new wonder currency with loads of followers and a spirited development team

There really is only one legacy, right?  We can't have two currencies both considered to be the proper descendent of the original Bitcoin, right?

The point is that no split off is interested in not being bitcoin, because the brand name is what counts.  So we'll stick with JUST 1).


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 23, 2017, 04:56:07 PM
To me it seems like maybe three currencies could be the way forward;

1) bitcoin as it is running right now; it gets the legacy but with no development team to love it
2) SegWit, a new wonderful currency with loads of followers and a strong development team
3) the bigger/dynamic/adaptive block guys, a new wonder currency with loads of followers and a spirited development team

Likely moot, David.


The possibility of BU forking is increasingly unlikely. There is no community support really, despite loud voices screaming there is.

And one of the loudest voices on Bitcointalk (no, not me) has already begun to promote the next contentious hard fork attempt. It's very likely over, for now.


The point is that no split off is interested in not being bitcoin, because the brand name is what counts.  So we'll stick with JUST 1).

No, dino. It wouldn't matter if some successful hard fork coup wanted to use the Bitcoin name to "win", they can't win if their software design or code isn't up to standard. The name doesn't matter, the code does


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 23, 2017, 05:19:50 PM
one day
carlton: forks are bad

next day
carlton: just fork already

next day
carlton: forks are bad

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

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

if people really want to know what will happen if dynamic accepting pools were to rock the boat without consensus
Quote
2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

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

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: K128kevin2 on March 23, 2017, 05:55:02 PM
I don't think that core proponents are specifically against bigger blocks. Personally I am in favor of increasing the block size, but not in an incredibly stupid and irresponsible way like Bitcoin Unlimited, so I voted "Yes" in the poll.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: iamnotback on March 23, 2017, 06:09:02 PM
As many have argued previously, it's merely kicking the can down the road.

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

Seen that way, I agree.  It is a toy system to play with.

One person's permutation toy, is another man's erector set.

Look at the massive level of innovation being unleashed on Ethereum (and Raiden is bringing payment channels to Ethereum very soon, well before Bitcoin will have LN):

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

Bitcoin is mucking around while Rome burns. Meanwhile Ethereum might just land on a killer app and leave Bitcoin in the dust. We'll see...


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: David Rabahy on March 23, 2017, 06:39:29 PM
Ok, suppose there's no bone thrown from Core to the other camp(s).  When the heck does SegWit activate?  And more importantly, how does it activate?  Hmm, the SegWit blocks will be accepted by "original" Bitcoin nodes because they look good.  So, a bunch of blocks end up on the chain with "extra" meaning.  Weird.

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 23, 2017, 06:52:41 PM
Ok, suppose there's no bone thrown from Core to the other camp(s).  When the heck does SegWit activate?  And more importantly, how does it activate? 

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

Hmm, the SegWit blocks will be accepted by "original" Bitcoin nodes because they look good.  So, a bunch of blocks end up on the chain with "extra" meaning.  Weird.

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: David Rabahy on March 23, 2017, 07:11:22 PM
Hmm, if I switch later (sometime after Flag Day = June 14, 2017) to a 0.13.1 or higher version then will my node catchup on all of the witness data blocks?

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: David Rabahy on March 23, 2017, 07:15:23 PM
Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 23, 2017, 07:29:15 PM
Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.

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

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

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

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 23, 2017, 07:30:48 PM
Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.

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

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 23, 2017, 09:40:38 PM
From year+ now this limit is NOT working as protection at all. There is just "too many" transactions to fit in 1MB.
This isn't a valid argument to increase the block size limit. If this was an valid argument, then anyone could push a scenario where it is required to keep raising the block size an *infinite* number of times by creating "too many" transactions (at each upper limit).

Block transmission is now done by header/gentx/tx list, not as full block data.
Whilst this is a very nice improvement, it has zero relevance. If you have a node with open ports, you will be straining yourself with upload bandwidth not download

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

1MBit connection allow to transfer over 100tx/s (1:4 in/out), block can be like 15MB on that connection.
Which leaves us with.. 0 seconds for validation? You really have no idea how Bitcoin works.

There is a technological problem to make bigger blocks.
FTFY.

When SegWit start it probably will take another year to popularize SW transactions, LN and/or sidechains.
Speculation on SegWit. The popularity of Segwit has nothing to do with the popularity of the latter two.

Think, how it is possible that "better" idea as SegWit have LESS support in miners than "worse" BU? Why over 30% is not decided?
Simple: Someone or a certain group of *someones* has been lobbying miners and feeding them FUD how LN would steal all of their fees and how Segwit == LN. Both claims are absurdly false.

IF Core merge ANY code that raise block limit along witch SegWit, it will get 95% in no time. If not - I (and not only I) see no chance to activate SegWit.
No, that is most certainly not the case. From what I understand Ver, he wants to *fork away* from the Core contributors are any cost.

To me it seems like maybe three currencies could be the way forward;

1) bitcoin as it is running right now; it gets the legacy but with no development team to love it
2) SegWit, a new wonderful currency with loads of followers and a strong development team
3) the bigger/dynamic/adaptive block guys, a new wonder currency with loads of followers and a spirited development team

There really is only one legacy, right?  We can't have two currencies both considered to be the proper descendent of the original Bitcoin, right?
No. There will not be three currencies. If the BTU folk fork away, it is highly likely that Segwit would be activated very soon after that (be it with BIP9 signaling or UASF). In the case of two currencies, the latter, also known as BTU, would be an altcoin.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 24, 2017, 11:30:54 AM
(...)
You don't even know what you're talking about and you are making demands! ::)
(...)
You really have no idea how Bitcoin works.
(...)
You take your point. Even two. Very mature.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 24, 2017, 12:55:26 PM
1MBit connection allow to transfer over 100tx/s (1:4 in/out), block can be like 15MB on that connection.
Which leaves us with.. 0 seconds for validation? You really have no idea how Bitcoin works.

Validation requires network bandwidth? Holy cuckoo.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 24, 2017, 12:57:48 PM
(...)
You don't even know what you're talking about and you are making demands! ::)
(...)
You really have no idea how Bitcoin works.
(...)
You take your point. Even two. Very mature.
Cry somewhere else. Fact is, you clearly have a very impaired understanding of Bitcoin and the relevant scaling debate. I'll call you out every time you make demands with psuedo-science.

Validation requires network bandwidth? Holy cuckoo.
What are you on about? Good luck propagating 15 MB blocks through the network and validating them on time. ::)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: hv_ on March 24, 2017, 02:57:39 PM
(...)
You don't even know what you're talking about and you are making demands! ::)
(...)
You really have no idea how Bitcoin works.
(...)
You take your point. Even two. Very mature.
Cry somewhere else. Fact is, you clearly have a very impaired understanding of Bitcoin and the relevant scaling debate. I'll call you out every time you make demands with psuedo-science.

Validation requires network bandwidth? Holy cuckoo.
What are you on about? Good luck propagating 15 MB blocks through the network and validating them on time. ::)

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

No

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Searing on March 25, 2017, 07:19:26 AM
Well looks like from the bitcoin core point of view 30% of this kinda hostile take over bitcoin FUD is to be expected and they are simply going to
ignore it...ie if you don't have the chops to take over from bitcoin core...we are gonna ignore your efforts or concerns....status quo

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

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



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 25, 2017, 09:02:12 AM
Hashing power:
40% for BU
30% for SW
30% undecided.
But.
BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Searing on March 25, 2017, 09:22:11 AM
Hashing power:
40% for BU
30% for SW
30% undecided.
But.
BIP168 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 168 activate in November?

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

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


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

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

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



Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: hv_ on March 25, 2017, 11:01:51 AM
Hashing power:
40% for BU
30% for SW
30% undecided.
But.
BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?

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

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 25, 2017, 11:10:08 AM
And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?
We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality :)


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Lauda on March 25, 2017, 11:47:51 AM
BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?
More like: http://luke.dashjr.org/programs/bitcoin/files/charts/software.html
90% Core
2.5% BU
7.5% others.

If 148 is USER activated soft fork, and majority of USERS want cheap and fast transactions ON CHAIN, is IS possible to make UAHF and raise block size.
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.
You still don't get it, do you? There is no emergent need for a capacity increase HF. As soon as the spam stopped, the mempool is nearly empty. https://tradeblock.com/bitcoin

@Lauda, blocks are NOT verified as whole at one time. Maybe you forget, that every transaction that is received by node is verified on delivery. New block is announced as header (one hash to verify POW) and hashes of transactions included in it - node just need to verify gentx and pull/verify only MISSING transactions. In other words: if node is online and collecting transactions, even 15MB block can be verified in second, because node know and have verified transactions from block.
I am most certain that you don't know how Bitcoin works. You still verify the whole block, not just a partial part of it. ::) You can effectively DoS the network with 2 MB blocks. 15 MB is absurdly large, unsafe,  unneeded and would take down a high percent of our node count.

And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?
How many % are running BTU/altcoin because Ver or his employees were spreading propaganda and/or were lobbying ViaBTC/TopBTC/Jihan? ::)

We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality :)
It is 'user-activated', not 'miner-activated'. Nodes >0.13.1 already support BIP148.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: dinofelis on March 25, 2017, 12:01:53 PM
And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?
We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality :)

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 25, 2017, 12:26:18 PM
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

No it isn't

Schnorr signatures confer scaling on-chain

Transaction encoding improvements confer scaling on-chain



Stop spreading falsehoods, these facts are readily avaliable


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 25, 2017, 12:49:23 PM
I am most certain that you don't know how Bitcoin works. You still verify the whole block, not just a partial part of it. ::) You can effectively DoS the network with 2 MB blocks. 15 MB is absurdly large, unsafe,  unneeded and would take down a high percent of our node count.
(...)
It is 'user-activated', not 'miner-activated'. Nodes >0.13.1 already support BIP148.
1. Looks like you really need catch up code. Node is verifying transaction only once - when arrived.
2. Not a single line about enforcing activation of SegWit in 0.14, so how 0.13.1 is supporting BIP148 (reminder: BIP148 was published 12. march)?
https://i.stack.imgur.com/jiFfM.jpg
I don`t know how bitcoin works, so I never write a single line of bitcoin-related software, I never contributed to Core code, I never make public lecture about Bitcoin... I`m not a moderator of national Bitcoin forum in Poland either.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 25, 2017, 12:51:55 PM
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.

No it isn't

Schnorr signatures confer scaling on-chain

Transaction encoding improvements confer scaling on-chain



Stop spreading falsehoods, these facts are readily avaliable
Link to math please, how much data will take 10`000tps in Bitcoin blockchain using this stuff?
Or how much tps you want to scale to?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 25, 2017, 01:48:27 PM
Link to math please, how much data will take 10`000tps in Bitcoin blockchain using this stuff?
Or how much tps you want to scale to?

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

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


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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: ANHEQIAO on March 25, 2017, 02:25:03 PM
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.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: AngryDwarf on March 25, 2017, 02:29:46 PM
Link to math please, how much data will take 10`000tps in Bitcoin blockchain using this stuff?
Or how much tps you want to scale to?

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

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


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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: rav3n_pl on March 25, 2017, 02:50:08 PM
Transaction encoding improvements: http://people.xiph.org/~greg/compacted_txn.txt

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


On-chain scaling is possible. Blocksizes are not scalable.
Transaction encoding can give 20-30% disk space and reduction of bandwidth. Good, but not good enough.

New signatures need SegWit anyway:
Quote
So the way we could use this to improve scalability in Bitcoin would be to add a OP_GROUPCHECKSIGVERIFY (and perhaps a multi-version of it) as part of a new segwit
script typecode that takes as input sighash flags and a pubkey.
It can give additional 40% capacity and can raise security. Good, but still not enough to scale.

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: hv_ on March 25, 2017, 03:07:07 PM
BIP148 is coming, so lets look on nodes:
90% Core
10% BU
Lets guess, what will happen when 148 activate in November?
More like: http://luke.dashjr.org/programs/bitcoin/files/charts/software.html
90% Core
2.5% BU
7.5% others.

If 148 is USER activated soft fork, and majority of USERS want cheap and fast transactions ON CHAIN, is IS possible to make UAHF and raise block size.
I know, that scaling on chain is impossible, bus as I mention earlier - segwit goodies need time to be up and running, block size works instantly.
You still don't get it, do you? There is no emergent need for a capacity increase HF. As soon as the spam stopped, the mempool is nearly empty. https://tradeblock.com/bitcoin

@Lauda, blocks are NOT verified as whole at one time. Maybe you forget, that every transaction that is received by node is verified on delivery. New block is announced as header (one hash to verify POW) and hashes of transactions included in it - node just need to verify gentx and pull/verify only MISSING transactions. In other words: if node is online and collecting transactions, even 15MB block can be verified in second, because node know and have verified transactions from block.
I am most certain that you don't know how Bitcoin works. You still verify the whole block, not just a partial part of it. ::) You can effectively DoS the network with 2 MB blocks. 15 MB is absurdly large, unsafe,  unneeded and would take down a high percent of our node count.

And how many % are just running SW / core just because of some signed letter politics, hidden or open FED meetings or just uninformed ?  What would it look like if all could decide on really a free and uncensored base?
How many % are running BTU/altcoin because Ver or his employees were spreading propaganda and/or were lobbying ViaBTC/TopBTC/Jihan? ::)

We don`t know. BIP148 anyway need hashing power, or nodes that support it just ban itself from network into no-new-blocks reality :)
It is 'user-activated', not 'miner-activated'. Nodes >0.13.1 already support BIP148.

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Carlton Banks on March 25, 2017, 03:15:33 PM
Good, but still not enough to scale.

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


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

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

Nope.

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: David Rabahy on March 25, 2017, 08:08:33 PM
Have we got your term yet for improving processing?


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: Killerpotleaf on March 25, 2017, 08:11:28 PM
https://www.reddit.com/r/Bitcoin/comments/5y18ub/compromise_lets_merge_bip_102_2mb_hf_and_bip_141
Quote from: Reddit user ecafyelims
Let's merge BIP 102 (2MB HF) and BIP 141 (Segwit SF) into a single HF (with overwhelming majority consensus).


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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: David Rabahy on March 25, 2017, 08:12:29 PM
Is this https://blockchain.info/blocks a good place to watch the block sizes?  If so then it appears to me that very few blocks are less than full.


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: XbladeX on March 25, 2017, 10:02:34 PM
Is this https://blockchain.info/blocks a good place to watch the block sizes?  If so then it appears to me that very few blocks are less than full.

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

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

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

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

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: -ck on March 25, 2017, 10:12:28 PM
AntPool = BTC-U supporter of bigger blocks HAHAHAHAHA fuck them those china miners cartel
they need BIGGER BLOCKS ? Why ? They can't even mine constant 1MB....
AntPool = BTC-U supporter of bigger blocks miner control of the network
There, fixed it for you


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on March 25, 2017, 11:14:11 PM
AntPool = BTC-U supporter of bigger blocks HAHAHAHAHA fuck them those china miners cartel
they need BIGGER BLOCKS ? Why ? They can't even mine constant 1MB....
AntPool = BTC-U supporter of bigger blocks miner control of the network
There, fixed it for you

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

even you know if NODE consensus does not exist, then whatever gets made which does not follow node consensus gets rejected in 3 seconds.
need proof:
Code:
2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

try sticking with facts next time


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on April 04, 2017, 09:07:00 PM
Some of the people that discussed here will already know it, but the original proposal (2 MB + Segwit) has had support from a prominent Core developer (or better, "security auditor") - Sergio Demian Lerner, also one of the people behind RSK. The original discussion is here (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html) at the developer mailing list.

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: franky1 on April 04, 2017, 09:11:38 PM
Some of the people that discussed here will already know it, but the original proposal (2 MB + Segwit) has had support from a prominent Core developer - Sergio Demian Lerner, also one of the people behind RSK.

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

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

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


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: andrew24p on April 04, 2017, 09:49:19 PM
regular segwit is fine for me. People are blocking it not for technical reasons, but because they will lose the ability to ransom for a HF


Title: Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB)
Post by: d5000 on April 06, 2017, 02:59:34 AM
kind of funny
segwit 2weeks grace.
yet anything not blockstream authorized 1year plus grace..

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

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

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