Bitcoin Forum

Ok.

Jhonny's got 3 threads up about mean nasty Core and how they are destroying Bitcoin.

Here is my LAST attempt at explaining 'what is going on' rationally.

1) There is a 'buglet' in Bitcoin that means that you can construct a TXN that uses a lot of time to process / check. Let's not worry about what it is but agree that it exists. The larger the blocks the easier it is to construct this TXN, and IF we had 2MB blocks, right now, you could bring down the network. This issue is fixed with SeqWit. So Core thought, let's introduce SW first, THEN we can make the blocksize bigger. Safely.

2) Soft fork vs Hard-fork. The 'poison pill' Jhonny and Franky keep ranting about is actually because CORE thought that NOT forcing you to upgrade was a GOOD thing. This is a Soft Fork. It means if you don't upgrade - no problem. No Split. We all carry on as before, and all the clever SegWit shit will happen in a way that doesn't affect the old nodes. Safely.

3) Bigger Blocks would ALREADY be here IF we had just upgraded to segwit 6 fucking months ago. This ridiculous stalemate is what is causing this total cluster fuck of a situation.  Once we get SegWit.. oh mama.. ALL the clever things people have dreamed about can START to happen. AND Bigger Blocks!.. Safely.

..

If you are saying - NO! You Bast***ds! We want to jump ship to BU, which has a new consensus model, and software that crashes every 3 weeks, you are NOT acting SAFELY. Fact.

CORE are NOT your enemy.

.. Wake UP! (My New Chant..  ;)) .. before it's toooo late..

Franky has a misleading understanding of Segwit, and jonald is a hired baboon. Franky1 will argue that this isn't fixed with SegWit, and he's partially right. The thing is (post Segwit):
1) You could use native transactions to abuse this quadratic validation time problem. However, you are not able to attack the network this way as using only native keys results in =< 1 MB block size.
2) This is fixed for Segwit keypairs and Segwit transactions as validation time is linear. Meaning, with Segwit transactions you can safely do >= 1 - 4 MB.

---

Pools can and will prioritize Segwit transactions over the native ones if an attacker tries to abuse this. It's a non issue.

You won't wake up if you're paid only to sleep.

not fixed
because
core v0.12  buglet (quadratics) 4k tx limit (10 seconds buglet delay per tx) block limit 20k (ability to have 5tx of the the txsigop limit)
core v0.14  buglet (quadratics) 16k tx limit (8minutes seconds buglet delay per tx) block limit 80k (ability to have 5tx of the the txsigop limit)

the segwit 'activation' itself solves nothing.
even if 99.99% of people move funds to segwit keys to DISARM themselves from causing (your buzzword buglet) quadratics. 1 person can make just 5 quadratic transactions to use up all the sigop limits and cause 40minutes of validation delay instead of 50 seconds.

the solution is not segwit. the solution is maxtxsigops to remain at 4k (less than a couple years ago) or bring it down further... definetly not raise the limit to allow it to become more of a problem/ attack vector

Wow!!!

@Spartacusrex & Lauda

According to you Guys, BTC is really just a piece of shit.   :P

BTC can't support 2mb blocks, but there are Alts going as high as 10 MB per block, (without segwit).

BTC can't move to a faster block speed, but LTC runs at 4X faster blockspeed with zero problems, and other alts even faster.


So either you guys don't know what you are talking about and BTC is able to match the alts if the code is updated.
or
BTC is just an old clunker that should be left in the junkyard.


I'll let the reader decide which they want to believe.   ;)


 8)

this is where lauda misunderstands.

segwit transactions do not wholely sit in the weighted area separate and safe from native tx's. they sit in partly in the base block. along side native tx's where a segwit tx has its ass (the sig/witness) hanging in the extra weighted area..

now if 5 native quadratic spam tx's are in the base block.. nothing else gets in. not even segwit tx's .. in short its used up all the baseblock limits and makes that block take 40 minutes to validate.

You keep saying this but it's just NOT TRUE.

This is why there is a 1MB base blocksize limit.

The old keys can spam away at their 1MB block all they want. The new keys which are 'disarmed' from quadratics can spam away at the 4MB total.

You cannot attack this way, no matter the sigop count, we could remove that limit and we probably should. Sigop limit's are only a bandaid.

You simply cannot craft a tx that takes 10 minutes to validate with only a 1MB block. And segwit isn't quadratically spammy, so 4MB is OK.

It's precisely why segwit+2MB HF was the dumbest proposal in the world. That would be quadratically attackable.

It's also one reason why BU sucks big time. They can't fix quadratics without a new address format like segwit. So they are using 'bandaids' like sigops and a 1MB transaction size limit to try solve it. None of it works, it's still quadratically spammy. When you explain this to the devs, they say that the miners would never attack the network. I beg to differ:
https://bitcointalk.org/index.php?topic=327767.0

The only long term plan they have to fix this is to hardfork in segwit at a later date: https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/

1mb, 4mb is just data limit..
if there was only the 1mb limit. then quadratics could make a single tx of hundred thousand sigops taking HOURS to validate..

this is why there is the maxtxsigop limit.. to reduce quadratic risks.
in recent years it got added and put down to 4k sigop limit and 20k blocksigop limit. meaning quadratic spammers can no longer make a single tx of hundred thousand sigops. but at most 5x of 4000 sigops.. which calculates to 50seconds of validation time instead of hours

your also forgetting that native keys will still be functional even after segwit activation. so the attack still exists.
all sgwit key users are doing is disarming themselves from performing it. but people sticking with native keys can still perform it.
and as my other post mentions.. which most people dont realise is that segwit keys need to be in the base block too.. even if their ass is hanging out in their weight area.
its not like segwit key users are completely separated from native keys, just their ass (the sig/witness)

Op codes are data. You can only fit so many spammy op codes into a block. You cannot attack a 1MB block even if it was completely full of the spammiest OP codes. Sigop's limits are a new thing, we didn't have them before.


*sigh*

On their 1MB BLOCK, which cannot be used to craft a quadratically spammy tx that takes 10 minutes to validate. Sure, native key users can fill a block. They don't need quadratics to do that. Segwit keys can fill a block too. Anyone can fill a block if you got enough money to burn in tx fees and outbid everyone else.

Why on earth did you start a thread trying to dispel the nonsense of the march of the full time anti-core propaganda trolls and not make the thread self-moderated, hence inciting the very same morons back to post here?

come on CK. even you know segwit keys sit in the baseblock too. and if the baseblock has native quadratic spam of 5tx's of 16k sigops each.. thats about 40 minute validation delays. ven after sgwit activates.

cores hope/utopia is that everyone including malicious people will morally move funds to segwit keys. and then the utopian dream of everyone being disarmed 'could' be seen..
but

even you know native key use cant and wont get turned off after segwit activation. otherwise people cant spend their native utxo(16m+coins)
even you know those intentionally wanting to spam wont opt-in to move funds to segwit keys.. so its not solved

Can't fit that many sigops in a 1MB block.

It's interesting that 1MB is the biggest size you can have without it being quadratically spammy (over 10 minutes to validate). Satoshi picked a good limit.

Wow!!

@Kiklo & Franky1!

Nonsensical crap just can't stop spewing out of your Mouths!..  I'd get that seen to.. err.. Staples ?


Coins with the Traffic of Bitcoin ?


{ YAWN }.. I didn't mention block speed..



Yes - I think that would be best.. ;)


LOL.. no.. jesus if this thread was Self Moderated, they'd just start another thread and accuse me of having a Self Moderated thread!..

Sorry, but there are pro-core propaganda trolls too. I don't see the point in making them self-moderated, we would just have pro-core and anti-core self reinforcing propaganda threads, where no one would be able to challenge each others assertions.

I'd rather see hand grenades being lobbed from the two entrenched positions to see whose lines of defense holds up, than have a load speaker battle where those with the most powerful amplifier wins a bad philosophy.

I know, right? But it gave me an excuse to call all the people I have on ignore morons.

Then all you've really done is create yet another thread like all the other ones I'm afraid. They all end up looking the same.

did you not see the whole post
CORE V 0.12 :  txsigops 4k blocksigops 20k = 5 tx of 4k each  (total block validation time if those 5tx were created = 50 seconds)

CORE V 0.14 :  txsigops 16k blocksigops 80k = 5 tx of 16k each (total block validation time if those 5tx were created = 40 minutes)
core v0.14.. is segwit.
https://github.com/bitcoin/bitcoin/blob/0.14/src/consensus/consensus.h

https://github.com/bitcoin/bitcoin/blob/0.14/src/policy/policy.h

yep more txsigop bloat is possible due to NEW limits of 0.14. which is segwit..

You can't fit the data of 80,000 OP codes into a 1MB block. There is not enough space for that data. If there was, then please make a spammable TX and prove us wrong.

Anyway the txsigops limit is enforced by nodes relaying txes, and the blocksigops is enforced by miners. Evil miner can exceed the limit if he wants. It's only a 'bandaid' to the problem.

Which alts have big blocks without segwit?

but mallicious users are not going to move funds to segwit keys and intentionally disarm themselves.. so segwit doesnt 'fix' it
segwit doesnt even force users to move funds to segwit keys either. users can still use native keys.. so segwit doesnt 'fix' it

Fucking hell. The native key users are stuck in a 1MB block. You cannot, no matter what the op code limit is, put in enough op codes into a 1MB block to make a block that takes 10 minutes to validate. The size in bytes of the tx(es) required to do that is bigger than 1MB. They cannot quadratically spam.

If they 'disarm' themselves, then they can use the full 4MB space, and still cannot quadratically spam.

This is what the sigops limit actually do:

Node: I am validating this tx but its taking too long to validate, lets not relay it.
Miner: I crafted this block but it takes too long to validate, lets just craft a new block and mine that one.

Even with sigop's limit a miner can do this:

Miner: I crafted this block but it takes too long to validate, but I am evil so I will mine it anyway!
Nodes: No! this valid block takes too long to validate! I won't be able to validate it before the next one is found, but I have to validate it because it follows all the rules! damn it I'm going to be forked!

using v0.12 rules your right..
but check out 0.14 rules
80k block 16k tx

segwit makes things worse for the 1mb block


by filling the 1mb with spam.. then the other 3mb remains empty. because you cant stick your segwit ass in the 3mb area if you cant even get your head in the 1mb area due to the spam that has filled the 1mb area to stop anything else getting in.

its not about filling 4mb of sigop spam..
its just about being malicious with the baseblock so that the other 3mb is never utilised by only having to mess with the base block

the solution is simple

txsigoplimit 2000.

everyone wins (apart from malicious spammers)
trying to assume the solution is 'lets hope everyone including malicious users use segwit keys' is a laugh

0.12 and 0.14 both have 1MB blocks. Can't make quadratically spammy block that takes 10 minutes to validate with 1MB. Sigops are a fucking bandaid added by Gavin so that he can argue bigger blocks are safe. They don't do ANYTHING. If your an evil miner you can edit the source and change the limit and attack the network, it's not a consensus rule, needs to be forked in to be one, blocks exceeding the limit are still valid, it's the 1MB blocksize limit that protects us from evil miners.


Sigops limit protect us from random assholes quadratically spamming, but not evil miners.
Blocksize limit protects us from random assholes and evil miners crafting blocks that take 10 minutes to validate.
Gavin argued that miners would never be evil, so increasing the blocksize would be safe if we prevented random assholes from quadratically spamming. This is bullshit, miners can be evil.


You can always fill a block if you are willing to outbid everyone else on tx fees.

I'm done arguing with you...

Eh!! If pool don't prioritise segwit then it is an issue. We have no idea how the pools may react in the future.

Default rules in bitcoin core with segwit enabled bias towards segwit transactions by counting the amount of block space they use and since their signature verification is no longer in the block they are substantially smaller than traditional transactions (up to 4x) so if they use the default bitcoin core implementation they will bias towards segwit transactions by default. However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices, so long as the transactions are valid by current rules - most pools run custom bitcoin daemons already and they probably have their own custom rules.

to which i will reply with your own words

yep ill reply with anontroll420's quote

solution
consensus.h
txsigops <4k (forever)

Is this not something developers should sort out? This is an element of centralisation when pools can dictate their own rules on the rest of the network. A truly decentralise bitcoin should by default be the codes that process the rules and protocols.

No. You cannot dictate what transactions are included at all, only what rules they must abide by. To do so would require a hard fork and mandating what transactions will be going in would be an extremely unpopular move and suicide for a cryptocurrency that is trying to be open.

@CK     :-*

Takes one to know one.  :D :D :D


 8)

Miner can currently mine empty blocks right now if they want....



Good luck doing any useful contracts or any large multi output tx with that limit. Good luck having unspendable txes.

yep which also shows that segwit solves nothing. it cannot force pools to only accept segwit keys meaning native keys can still mess with the base block in MANY attack vectors that affect the network.
segwit doesnt 'fix' anything. its just HOPES malicious users decide to disarm themselves

Yes, they can fill a block if they outbid everyone on tx fees. They can do that right now too. They can do that with any blocksize. Segwit users can do that too. Nobody quadratically spam.

Miners can also outbid by giving up the tx fees they earn in a block and mine an empty or full block if they want too. They can always do that

You ? meaning me or miner?

You said, "However there is absolutely nothing that says what any pool must include or how they must bias their transaction choices,." = miner can choose = dictate?

Nonsense. The sigops in Core 0.14.0 are scaled for Segwit and have linear validation time. "40 minutes" is an outright lie.

Do you even algorithm complexity?

---

This was debunked by me long ago, then later also commented on by Maxwell stating the absurdness of your claims.

The developers cannot dictate.

i was actually symplifying things without going into waffle for the benefit of the "one paragraph concentration spam" people of reddit/twitter
so here goes, as condensed as i can make it:
not

plus gmax didnt dbunk anything. he just done what you usually do.. "wrong because word twist + insult"

I was talking about pools when I used the word dictate.

Yes they are.  Their actions speak for themselves.  They've stalled for years and damaged Bitcoin adoption, use-cases, and marketshare with high fees and slow confirmations.   Segwit as SF just allows them to continue to dole out whatever meager on chain capacity improvements they are willing to grant us.

I reject their economic approach entirely and believe blocksize should always be well beyond market demand.  Let off-chain solutions compete FAIRLY with on-chain, without any constraints.  

If you're concerned about decentralization, SPV Fraud Proofs are better than ever:  https://bitcrust.org/blog-fraud-proofs

I had never heard of this fraud proof implementation. Interesting.

I just started reading it and one problem I see is that it requires a fork to Bitcoin that changes the merkle tree. This would break covert ASICBOOST (I'm not joking!) so I don't think Jihan will support it.

It seems like to do what they call 'fraud hints' would require a malleability fix too, so we'd still need segwit or another malleability fix, though I'm not entirely sure about this.

There are also some limitations to it:

Regardless, you are wrong about the sigops.

He did debunk it by making such a statement as your claim is ludicruous. If I were to get the author of Segwit in here to tell you that you were wrong, you'd still write "he didn't debunk anything" nonsense.

This is nonsense, as you'd expect it from a paid baboon. SPV Fraud Proofs are far from being practical and safe enough to alleviate the dangers of SPV wallets.

They are not ready yet. Hypocritically, the BTU supporters bash something that has been extensively tested for months but praise something that is new as safe just because it fits their agenda.  ::)

wow "im ludicrous"
now thats real proof of concept there.
such merit in code and such merit in display of proving wrong by saying "im ludicrous", such detail in explaining it...

now then..
4k vs 16k sigop count, which do you think is worse

You are.

The left one is with the current block size limit & quadratic validation time, the other one is with Segwit and linear validation time. The foremost is worse. Maybe enroll in a CS college?

lol says the guy that doesnt even know and admits to not knowing c++

lol
so go on.. if you really think the 16k is only for segwit key users.. go on show me the limit for native key users
go on showw the code in 0.14 that says basically in laymans
this is line of code for segwit tx type sigop limit
this is line of code for native tx type sigop limit

i now await the usual 'i dont have to prove anything' or ' lets just insult you' or other empty whistling in the wind reply

Download and run Bitcoin Core 0.14.0. Create a transaction with 16k Sigops and provide us with proof here. Once you fail to create such transaction(s), you will come back here complaining about semantics. What happened to the per-block-limit that you kept mentioning until recently? ::)

It is up to you to prove your initial claim, and snipping code out of context != proof.

i snipped code because you were crying the other month that you cant read more than a paragraph
so here you go https://github.com/bitcoin/bitcoin/tree/master/src read the unsnipped version

which file has the sigops limit?  i would like to see

it requires basic elementary/primary school level maths and reading a couple locations wrote in c++ which i know lauda has a hard time dealing with. so i simplified it for him by just using laymans: maxtxsigop=16k

but for those able to read and do basic maths

https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h
and here is where the MAX_BLOCK_SIGOPS_COST exists
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h

rearranged into one line of text is:
 MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
becomes
MAX_STANDARD_TX_SIGOPS_COST = 80000/5 = 16,000
meaning
"The maximum number of sigops we're willing to relay/mine in a single tx = 16k"

---

also worth noting
in short you can use up a base blocks entire MAX_BLOCK_SIGOPS_COST with just 5 tx of 16k sigops

---

also worth noting
thats 3 different spam attack vectors

1. just fill a block of native data to 1mb
2. use up the block sigops limit with say 1000tx of just 80sigops each for example
3. use up the block sigops limit with say 5tx of just 16,000sigops each for example

I wondered why no one still mentioned the following counter-argument:


That is not an argument against "2 MB + Segwit".

Proposals like Lerner's  "Segwit2MB" would activate the 2 MB hard fork after the activation of the Segwit soft fork. Maybe Lerner's 6 months (if I remember right) as "grace period" is too short because maybe until then most people would still use legacy transactions, but 1 year would be surely enough. We would then activate Segwit in mid-to-late 2017 and 2MB in mid-to-late 2018. Jihan as far as I remember mentioned the Hong Kong Agreement several times, so he should be happy with this solution.

What wrong with do both as hard fork? Wouldn't segwit hard fork be better than soft fork?

I assume if hard fork for both then there is a need to allow legacy txs to be converted at a later date. ie. 10 years.

We seem to not be communicating here. You asked "Is this not something developers should sort out" and I'm telling you they can't.

lol

This is an element of centralisation when pools can dictate their own rules... Thus dictate was relevant to pools.

Explain why it would be "extremely unpopular move and suicide for a cryptocurrency"?, when a miner producing an empty block when there is outstanding txs is stupid enough itself.

segwit as a hardfork requires everyone to upgrade node.
but here is the thing.. native key users dont have to move funds to segwit keys.

what happens in reality is that instead of 2 merkle (block inside a block)..
its just 1 base block where the witness and txdata sit together.

and simple ALL share the same room.

its not
base 1mb           || witness <3mb  ||
[IN] [SIG] [OUT] ||                      ||  - native
[IN] [OUT]         ||[SIG]               ||  - segwit

it is
base 2mb
[IN] [SIG] [OUT]                          || - native
[IN] [OUT][SIG]                           || - segwit

thus both tx types benefit and coexist in the same area with no stripping (filtering/bridging) data.. blocks are the same for all nodes of the network because they all upgraded to just the 2mb hardfork

I don't disagree that pools producing empty blocks is stupid; heck I'm one of the BIGGEST campaigners against doing so in the mining world.

As for why developers cant mandate what goes into a block through network rules via a hard fork, bitcoin is an open transaction system and any attempt to strictly specify which transactions must go into a block in the reference core implementation would be futile. Not only does every node have a different mempool consisting of different transactions (it's impossible to sync all nodes to the same set of transactions in time and space), but enforcing certain transactions is actually creating a system with an unintentional censoring, prioritising and filtering of transactions in the world. The current system works off transaction fees as the incentive to choose transactions based on the reward making them more worth mining and indirectly creates a type of consensus without mandating order. Either way, the fact that no 2 mempools will be alike means it would be impossible to mandate anything anyway. Even empty blocks, as much as it pains me to say, must be allowed since theoretically there is a time and place where there are no transactions (though unlikely in bitcoin I agree) but additionally when a bitcoin node is restarted it has no transactions until they're gathered from the network or some are loaded from disk (in 0.14+). Even the ones loaded from disk may be all old and no longer mineable if enough blocks have passed since the node was restarted.

It does not mean what you think it means. Ask any developer that is actually working on the code.

I don't see how 2 MB + Segwit would avoid the quadratic problem on it's own. It needs to have some constraints on native transactions in order to work. Additionally, this creates a possibility of almost 8 MB blocks (if someone wanted to spam the network with this).

I didn't say 'which' but any validated txs. As long there are txs in the mempool, then the block should fill up until there is no txs in the mempool or block is over 95% full, for example. Empty blocks when there are no txs is fine but when there are thousands of txs waiting to be confirmed is madness.

Isn't that what the miners are already doing ?

Surely 4mb would be better?

yep. 4mb single block would be better for everyone..
but the other thing is that the hype about a compromise of 2mb+segwit.. was released on the 1st of april...
so although 4mb block where native and segwit can co-mingle in one merkle block(no block within block) would be better
im taking a pinch of salt as to if 'core' would actually really agree to code such a version of even 2mb+segwit for people to download.

Because of your nonsense, someone actually asked on IRC about this (it wasn't me):

---

Tl;dr; + ELI5: You can't use more than 20k sigops per block using native keys after Segwit.
Bonus: I was right, and franky was wrong as usual.

So it appears that this limit is used in validation.cpp.  Why is Lauda saying its only for segwit?  What a troll.

Which is not something that I've ever said. Learn to read.

---

I'd be very surprised if either one of you would admit to being wrong considering my previous post. Let's see whether we are really talking about "open-minded" individuals or "closed-minded" shills as suspected earlier.

I agree they SHOULD but as I said there is no way to reliably make it so they MUST.

Of course miners are choosing what goes into a block - that's precisely what mining is; mining transactions into the blockchain. You can't mine only "verified" transactions because the process of mining IS the verification.

A soft fork is always better if possible because of the "danger of two competing blockchains", and I don't see how a hard fork can solve the quadratic hashing problem here. (edited, see below) But legacy transactions cannot be permitted in an unrestricted way after the 2MB activation like today, as Lauda correctly points out:


So the "grace period" between the Segwit activation and the 2MB activation must be as long as possible (~1 year) to correctly evaluate the danger of "full block spam" (in this case "4 MB block spam"). Edit: And the 2 MB hard fork should contain also a restriction for legacy transactions. Maybe they can be prohibited and all people owning bitcoins on non-Segwit keys have to transfer them to Segwit addresses. But we don't have to do that already when the Segwit soft fork is activated (so we don't need a hard fork then), the 2 MB hard fork 1 year later would be early enough.

Regarding the possible 8 MB block spam, as I have already discussed in another thread, I would support going forward slower (first go to 1,5 MB/6 MB max. after a year and then to 2 MB after 1-2 years more if everything works right).

interestingly.

a native(legacy) tx of 4k txsigops is treated as 16k txsigops in core v0.14 due to the WITNESS_SCALE_FACTOR (which is 4x)

so to correct myself about worry of propagation delay, native(legacy) tx does not/cannot perform 16k actual CPU intensive sigops. its still only 4000 real CPU intensive operations(just treated as 16k after the fact purely for cludgy mathematics of filling the limit)
yes lauda, cludgy code can lead to semantics games which core devotee's love.

but segwit still doesnt make the native keys disarmed from the 4k CPU intensive time that existed in 0.12 either
so segwit for CPU intensive purposes is no better or worse

---

however there is still the 5tx's to fill the 80k issue
where it doesnt need to be 16k/tx of actual sigops.. only 4k/tx..
that means 5tx's can hold up and prevent even segwit transactions utilising the 3mb weight area because those 5tx's have used up all of the block sigops due to all the cludgy maths of 80/5/4

---

tl:dr;
ok so segwit doesnt make native tx's able to be more quadratically CPU intensive. to cause more propagation delay
but it doesnt make native tx's any less quadratically CPU intensive than v0.12 (still 4k)

it doesnt stop native tx's making just 5tx's to fill a block (cludgy maths sigop count limit)

so to amend it - 3 attack vectors
1. just fill a block of native data to 1mb (data/byte bloat fill attack)
2. use up the block sigops limit with say 1000tx of just 20sigops each for example (cludgy maths sigopcount fill attack)
3. use up the block sigops limit with say 5tx of just 4,000sigops each for example (cludgy maths sigopcount fill attack)

Can't do that.

However maybe...
On an isolated network with full blockchain - do a soft fork. If it works then make multi copies of the blockchain. Required a huge degree of trusted parties.

Do a hard fork as normal and everyone goes seggy.

Those who aren't aware would still be protected based on the multi copies of the blockchain.

Say 10 years time someone pops up and wonder where their bitcoins are. Trusted parties can use one of the multi copies of the blockchain. to allow the person to transfer his legacy coins to seggy hard fork blockchain.

Would that work?

There is no difference between the dangers of a soft fork and a hard fork.

In the event of a soft fork we have:
1.) The old chain exists with a more permissive set of rules.
2.) The new chain exists with a more restrictive set of rules.

In a hard fork we have:
1.) The old chain exists with a more restrictive set of rules.
2.) The new chain exists with a more permissive set of rules.

So they look exactly the same during a chain split.

The only difference is that a soft fork is backwards compatible because its more restrictive set of rules.

However, segwit expands the protocol (the definition of a hard fork), by using software kludges to make old nodes think they are compatible, and so is packaged as a soft fork.


Yes.
1.) We don't know how big a full block might be. It might be anywhere between 1MB and 4MB depending on usage. It is non deterministic. As a hard fork with 1:1 weighting this can be eliminated.
2.) There will be less technical debt by implementing segwit as a hard fork. The software kludges implementing it as a soft fork also creates huge maintenance risks in the future (segwit keys are 'anyonecanspend').
3.) All nodes will be able to perform their job properly. Segwit is not really backwards compatible, it's just an illusion created by the soft fork kludges feeding the old nodes filtered data and creates a two-tier node network.


I would consider it might be possible to make them eventually "send only" addresses after a grace period which allows users to change any known public receiving addresses.

---

I am against segwit as a soft fork. It should be a hard fork by its very nature and sets a dangerous precedent by using software kludges to package it as a soft fork in an illusionary manner. As a hard fork, it is possible that more could be achieved in this extensive protocol upgrade since it would not have design restrictions based on the imposed soft fork illusion.

Everything you said is noise.
True reason is: because CORE wants it this way.

What if nobody attempts to create such block in order to evaluate it? Are "we" going to spam the main network ourselves for testing purposes? In regards to forcing people into Segwit addresses: While everyone using SW keys would be an optimal future, forcing them into doing this may set a dangerous precedent.

I don't see why we'd need a potential 4 MB block (2 MB + SW) for standard transactions. The mempool would be empty for quite a while.

Therefore, you were wrong and I was write.

It is neither "cludgy" code nor "cludgy" mathetmatics, you just don't understand it. That's all.

Nobody ever claimed that it did, which makes this part of your post useless.

No. 5 legacy TX with 4k each fill up the block which is "normal" behavior today, and Segwit wouldn't change that.

---

Learn to admit being wrong, otherwise it's pointless for you to even attempt any kind of discussion.

Thanks everybody for the entertaining discussion in this thread, I learned something new about SegWit (WITNESS_SCALE_FACTOR). Thanks Lauda (and Sipa on IRC) for explaining.

You are wrong here. Exchanges pointed out the need for replay protection for even slightly contentious hardforks a while ago. Replay protection is quite difficult and would cause more technical debt than SWSF. This makes SWSF the currently superior solution.

Absolute bollocks. If SWSF becomes a contentious soft fork, you would still need replay protection. When there is a contentious fork, it makes no difference if that fork is hard or soft. You only need to implement replay protection if you want to cause a bilateral split, otherwise people will eventually unite behind a single chain, the one which has the most proof of work. The uniting behind one chain will happen sooner rather than later otherwise it is a complete clusterfuck.
Segwit has its merits. However as a soft fork it is a dangerous software engineering hack which will burden the protocol forever. It cannot be reversed since it would be an 'anyonecanspend' free-for-all. And the potential for future developers to fuck this up is quite high. That's right, the high lords who developed segwit as a soft fork won't live forever.

You are welcome. You shouldn't believe the Segwit == doomsday propaganda from randoms when the super majority of developers/experts are in full support of it anyhow.

Correct.

BU refused to add that to their implementation, which led us to where we are today. If one is so confident about their position, a bilateral split rather than a hostile split with no replay protection is the right way to go. As it currently stands, without replay protection a split would cause a lot of daamage.

A lot of soft forks are "anyonecanspend" for nodes that haven't updated. Segwit is no different to this. Try reversing P2SH as a comparison (the difference being that SW has another UTXO set); it is not impossible, just *very hard*. This is just related to the propaganda that is exaggerating the downsides of SW, which have been clearly written out on the Bitcoin Core website.

Well said. Just look at LTC and imagine what would happen to BTC price.

LTC is nothing but a pump.

core are the only ones wanting to create a bilateral or contentious split. core have been the ones screaming for anything not core to split away..
so if cores code causes a bilateral/contentious split (BIP9 and UASF has that ability) then core should be the one that adds "replay protection" if core was to decide to pull the split pin. in short core should take the heat. (and yes it is possible)

all other implementations want to stay together as a diverse per network. so why the hell should they be told to add in code and then be the ones that move away to allow core to have a dominant tier network.

ok lets word it this way..
anyone abstaining from segwit by just sticking with 0.12 rules being told to program a new version with replay protection..
yet core who have changed the code refuse to add in code to avoid risks of replay protection. (facepalm)

---

lastly if you dont think core code is cludgy.
ask yourself why the cludgy maths of native sigops is in line 4xx of a .cpp file and not in a header files(.h) such as policy/consensus.
and why the cludgy maths requires reading four different files instead of just having it all in a single header file as a set variable (easy to do)

and when it comes to changing from a 2merkle block to a 1 merkle block (which core pretends to promise later)... its not a simple edit of one file to change the metrics. but requires yet another big rewrite to undo the cludge of creating their 2merkle block

if you done a cs college course it wont teach you how to read the cludge any better. it would teach you how to read c++ and then recognise cludge when you see it.. because devs are not doing the basics of arranging variables in a logical way.

in short if the current devs of core/blockstream jumped over to litecoin or hyper ledger and retired their desire to work on bitcoin (devs are not immortal, their interests do change) the cludge they leave behind makes it doubly as hard to sort out for anyone new coming in.

---

your devotion to devs without knowing c++ reveals more about your lack of understanding bitcoin, but your adoration of a temporary team and trust that their word twisting should be good enough.

P.S im laughing at how you took the glory of 'explaining it'.. yet you were not 'questioner2' in IRC. and if you read the entire conversation then you would see that segwit does not 'fix' things. it just twists things

you try admitting it but prefer to word twist it

"Segwit wouldn't change that." = "segwit doesnt fix that"

so much cludge while keeping spam attack vectors open.

oh and i did admit i was wrong about the quadratic risk not being worse while at a 2merkle implementation(using math cludge). its no better either.
its just a maths game. of faking how many sigops it really does. by multiplying the rule.
i laugh at a 'sigopcount' variable that gets told not to count real sigops but hold a number thats not related to real sigops count, but a math cludge

and when segwit becomes a 1 merkle block. (removing the witness factor would be part of that) it will become a problem. which you have shown a bit of worry over.. but would not outright admit

---

why waste 2 years on the cludge of a 2 merkle with a promise of a 1 merkle within the year after..(3 year wasted)
when they could have done a 1 merkle initially with all the other features users want and have the 1 year grace period.(1 year and united community)

why even threaten the bilateral/controversial split for a 2 merkle and then promise a 1 merkle a year after doing a split. theres just no logic to it relating to keeping a diverse peer network.. but alot of logic when seeing the desire of a dominant blockstream owned tier network

started out as sw pump but when coinbase adopted it, could actually get some more use, that is much more real fundamental value than sw.

this is the only one, pretty new still https://bitcointalk.org/index.php?topic=1883902.0, has segwit and it's a clone of bitcoin in everything with 20MB block

but they don't need that of course their transactions per day can't dream to be on par with bitcoin, and there are no ddos or spam attack there

This is incorrect. There are 4 that already have activated it or are just about to activate it:
1) Groestlcoin: https://bitcointalk.org/index.php?topic=525926.0
2) Vertcoin (will activate in a few days due to pressure via UASF): https://bitcointalk.org/index.php?topic=404364.0
3) Litecoin: Activates in a few days too.
4) Digibyte: https://segwit.digiexplorer.info/

This is a cool explanation.


But there is no chain split on a soft fork.. That's the WHOLE point ?


LOL.. pls.. Give credit where it's due.. Maybe CoinBase added it BECAUSE of SW..  or at least Coinbase were convinced into adding it, becuase of SW.

It's not as bad as you make out.. Come and Join us! (If you want a $10k BTC.. that is.).. still plenty of room..

There is a chain split if there is a division of hash power between old and new rule sets. The only difference is that a soft fork is backwards compatible with older node software, whereas a hard fork isn't.

In the event of a successful soft fork, older nodes continue to operate as normal.
In the event of a successful hard fork, older nodes become unsynced and have to upgrade.

In the event of a contentious fork, hard of soft, it becomes an economically damaging clusterfuck until the winning fork is determined (the longest chain) or a bilateral split occurs (the minority chain implements replay protection).

A hard fork which is hacked as a soft fork (where backwards compatibility is an illusionary hack), the soft fork functionality has to be sufficiently locked in before activation to prevent the backwards compatibility hacks from being exploited. In this case, an older node appears to operate as normal, but it really isn't because it is being fooled by filtered hacked data.

people are bored of this::

A plague on both your houses::

do both segwit and 2MB

LTC now provides a credible test bed and alternative.

BTC is shooting itself in the foot, did you notice how it has lost dominance so much, LTC has just done what 30% in 1 or 2 days.

The only thing  I don't quite get is it that miners want larger blocks so they can collect more fee's but the LN + segwit will mean they face much less fees for miners?

Totally..


As soon as the blocks aren't full.. the fee market will collapse. Any fee will do.

no what I mean is as the block insensitive drops and (if) usage goes up the block reward would compensate miners.

so a 10 mb  x  full use at 1/5 fees would give more 2 x more at 1 unit of fee in 1mb block size so it would word for usage and miners.

Now is it the case that LN would allow all of the extra fees of chain, and so make BTC less attractive miners and keep fees high?

It all started because of segwit. Without segwit, LTC would be rotting in stagnation, but thanks to segwit, lightning network developers are going to move there, so LTC will get tons of features that are impossible without segwit. Exchanges will show interest and LTC will solidify as a solid altcoin.

Meanwhile BTC remains as it is today due miners not following economic majority. I believe sooner or later the balance will fall into segwit, but until then, LTC remains bullish. There will be ups and downs anyway, but this is no longer an isolated pump and dump, the fundamentals are clear.

he asked for an altcoin with more than 1 mb block, nothing is incorrect, bitcore is the only one with more than 1 mb block, it has 20 mb

what you listed are coins with segwit only, not bigger blocks

Jonald is a paid joke. There is no way that CoinBase would have added LTC without SW. With SW and LN, LTC has a potential future in which you can transact both Bitcoin and Litecoin via the same Lightning Network!

Segwit == block size > 1 MB.

The faulty understanding is that Segwit != bigger blocks. Just because it handles data differently, that doesn't mean that the block aren't bigger.

so charlie Lee working at coinbase has nothing to do with it.

segwit only = bigger block ONLY IF:
1. users move funds to segwit keys
2. segwit keys get accepted into blocks
3. native spammers dont fill the base block with native spam

Obviously it helps, but without segwit LTC would have no selling point. Who wants a BTC clone with prospects to get anything new done? that was LTC before segwit. In this post-segwit reality, LTC can shine to unforeseen prices thanks to what segwit being activated means, this creates a big bullish pressure that Coinbase can cater for.
But of course, anti segwit FUDsters will never admit segwit drives the value of a coin up objectively speaking.

Straw man argument, again.

Which is guaranteed to happen

Those two can be rewritten into one point. The obvious solution, which I've been telling you about is, prioritizing native -> SW and SW -> SW transactions.

yeah i know but he asked specifically for a coins without segwit that use a block size more than 1 MB, just to see if other coin are in the line with BU probably....

LOL guaranteed. LOL

do pools prioritise LEAN transactions to allow more transactions in.. nope
do pools prioritise mature transactions to evade spammers.. nope (spam: those that intentionally respend every block)
do pools prioritise transactions with fee.. nope (empty blocks/btcc zero fee confirm)

you HOPE and have FAITH that pools will.. but 65% of pools are abstaining or saying no to wanting to prioritise segwit as a protocol. so they are not going to prioritise segwit transactions.

in short. no guarantee, no fix. just gesture, half expectations and faith
much like the expectation of
"if pools prioritise lean tx's we can get 7tx/s 2009-2017".. yet in last 8 years never had a block of 7tx/s

yes on testnet it can be seen but thats test net where 1 person is creating the tx's in a certain agenda display of expectation.. when dealing with real world people using it for real world needs. reality does not reach expectation or hope

P.S your "2.1mb" expectation is the exact same 7tx/s expectation that has been promoted since 2009.. but never reached
its all if's maybe's half gestures hopes faith trust.. not actual real rules that enforce it

Maybe it was not clear but of course I am assuming a significant hashrate majority. Then there is no need for replay protection because the chain will always converge to the new chain. If you still disagree please explain.

Of course a hardfork is cleaner but the amount of tech debt the softfork causes is acceptable and it more than makes up for it in risk mitigation.

Why not? In a hard fork, in theory consensus rules can be changed without restrictions.


I don't really understand your proposal. Do you mean this for the case "legacy transactions are prohibited" there is a backup for non-upgraded nodes? Well, the idea was to "prohibit legacy transactions", not "prohibit legacy keys" - it would be forever be possible to transfer them to Segwit keys - otherwise, many people would lose their Bitcoins. I think that's what AngryDwarf said here and is also what I meant (I perhaps wasn't precise enough):




From my understanding, in a hard fork for unupgraded nodes it would not be possible to follow the new chain anymore. Even if 95% of all miners agree on a hard fork, unupgraded non-mining nodes would split away and couldn't use Bitcoin anymore in a safe way. In a soft fork with a 95% or even 85% approval by miners the minority unupgraded chain would always be orphaned and no node would follow it.

That's why a hard fork would need much more preparation time. A soft fork could be deployed in a few months, a hard fork needs a year or so to ensure all relevant nodes are upgraded.
(If that's wrong correct me.)

We could spam the testnet for that if nobody does it. Your point is, I suppose, that someone would hold back spam attacks until the maximal block size becomes big enough (e.g. 8 MB)?


Wouldn't then the quadratic hashing time problem be unsolved forever? Because the problem seems to be the danger of spam attacks based on that problem, and if non-Segwit tx are possible then a spammer obviously will use them. I think as long as it is possible to transfer non-segwit outputs to segwit keys (non-segwit to non-segwit would be the possibility that would have to be prohibited) the precedent is not dangerous.



2 MB + SW in my idea would occur in >2019. If Bitcoin's growth continues at the same speed than until now (30-50% transaction volume growth per year) then we could see pretty full mempools then. OK, maybe not if sidechains or extension blocks are functioning.

Because this is equal to censorship. Additionally, the average TX size is well above the "lean transaction size".

Immature transactions does not necessary equal to spam.

Yes they do (not always obviously). You have no argument as usual.

That does not equal to real world testing unless you can mimic the whole network on a smaller scale.

They could hold back or spam right away. Either way, an attack vector must not be left in the air at any cost.

Yes, the quadratic hashing problem will exist until it gets sorted out via a hard fork (see the Flextrans proposal, which is a HF proposal similar to SW but vastly inferior even though the incompetent devs claim its superiority). As I've told franky, pools can and will prioritize native-to-segwit and segwit-to-segwit transactions in the case of native-to-native spam attacks.

I don't agree with the instant jumping visions anyways. Why not 1.2 MB now, 1.4 MB next year and so on, until we hit 2 MB? These kind of approaches make more sense to me.

Wait and see. Txs per day would need to go up dramatically in order to justify its value and whether segwit is successful. At the moment segwit doesn't help litecoin at all.
If adoption rate goes up then great. So it's wait and see.

This is nonsense. Segwit wasn't designed as a capacity increase. The capacity increase is a side-effect of it. List of benefits:

---

Source: https://bitcoincore.org/en/2016/01/26/segwit-benefits/

The point of the "civil war" is that intelligent people don't want segwit and/or LN.

So just do a 2mb then 4 then 6 then 8... activated when certain block number is reached... or whatever.

I was concern about those who hold bitcoin but do not follow the news daily. Maybe those will ignore bitcoin and wait 10 years. What happens then when they find their bitcoin is "prohibited"?

When listing benefits, any competent person would always list both pros and cons. That's to avoid being bias. So can you list the cons please? That would include what happens after segwit gets activated... LN for example?

Malleability Fixes - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing malleability (only the innocent will happily disarm)
Linear scaling of sighash operations - not fixed. just offering a 'opt-in' keypair type thats disarmed from doing quadratics (only the innocent will happily disarm)
same for the rest.

but im glad you admit that adding code to force users to only pay using a certain transaction method is " equal to censorship.".. now think about it
in regards to people saying
"Maybe they can be prohibited and all people owning bitcoins on non-Segwit keys have to transfer them to Segwit addresses."
"prioritise native->SW... SW->SW"
"Q: users move funds to segwit keys A: Which is guaranteed to happen"

also glad your now seeing the truth that its just a optimum HOPE not a reasonable expectation much like the 8 year hope of 7tx/s
"In regards to forcing people into Segwit addresses: While everyone using SW keys would be an optimal future, forcing them into doing this may set a dangerous precedent."

You can read all about that in the source. The Bitcoin Core team was pretty objective when assessing the downsides of Segwit. This is why I've added the source.

It is fixed. Nobody has claimed that it was fixed for the legacy keypairs.

Same as above.

This is a lie. You don't understand Segwit.

Forcing users into Segwit keypairs is not something that I'd exactly support, although I wouldn't strongly oppose it as much as I oppose certain things. Prioritizing native -> SW and SW -> SW is fine with me and tackles the native key spam problem very easily.

its not fixed.
the problem with quadratics /malleability is that malicious people will use it to do mallicious things.
unless mallicious people CANNOT do it. then its not fixed.

EG its illegal to use drugs in countries..
does not mean the war on drugs is fixed by some rule. because people still use and sell drugs.

unless there was a way to permenantly guarantee that no one can sell/use drugs, the war on drugs is not fixed.

segwit is not a war on quadratics fix
its not even a prohibition (think about the 1920's alcohol prohibition)
its just a gesture rule where people can voluntarily move to a gated community that voluntarily wants never touch quadratics. and it wil turn out that the only people wanting to move are the people that never intended to spam in the first place

It is fixed for the claimed keypairs.

You can't harm the network with sigops at 1 MB. Malleability is another matter. This is why everyone should strongly support switching over to Segwit keypairs and implement a stronger control for native keys.

you can. think of the sigops as another "limit" of spam that once filled nothing else can get in


we all know a tx bytes are made by (148*in)+(34*out) roughly(+-10bytes)

so lets make a tx that has 4k sigops
a) 3999input:1output= 591886bytes~(4ksigops)
b) 1input:3999output=136114bytes~(4ksigops)

5tx of (b)=680570bytes~(20ksigops)

screw it. i know there are many knitpickers
c) 1input:2856output=97252bytes~(2.857k sigops)
7tx of (c)=680764bytes(20k sigops)

so i can fill a blocks sigops limit easily with 7tx of (c)
and although its only 7tx, and only 0.68mb of data.. no other transactions can get into the base block.. not even segwit tx's

I've not understood it in its entirety. Is the following mechanism correct: Legacy spam transactions would been recognized and avoided because they would "steal" them computing power for no benefit?


I have no problem with that concept - only that in this case we should do that with a single hard fork (like in BIP 103) to avoid having to fork every year. Still, my favourite are BIP-100-based ideas where the maximum block size has to be "voted up" in small steps, as we've already discussed somewhere.


Obviously the whole concept should be made in such a way that if you hold Bitcoin on a legacy key, you could transfer them to Segwit addresses. Only legacy-to-legacy would have to be prohibited.

Nonsense. That is spam, and not what we were talking about. You keep creating straw man arguments.

Irrelevant, already known and denied by nobody. You're starting to become boring.

Which you can avoid by prioritizing Segwit transactions.

"Steal the computing power" is a pretty weird way to label this. I'd rather say that legacy transaction spam attacks would be recognized, and pools/miners could start prioritizing the other set of transactions.

Of course. A single Bitcoin hard fork is very hard, let alone several of them.

Yep, maybe. What I meant was that big spam transactions would cost them an amount of hashing power that they - if they ignored these transactions or give them a very low priority - could use better to find blocks faster and get an advantage over their competitors.

a ASIC does not have a hard drive.. it does not matter to an asic if a block is 250bytes or a gigabyte. the "hashing" is the same
an asic is just given a hash and rehashes it.

data or bloat does not hinder ASICS one bit.. it only hinders the pool/server that validates/relays full block data.

---

its taken years of debate and still no guarantee on moving the block size once.. do you honestly think moving to 1.2mb is going to benefit the network, and then have another few years of debating to gt 1.4mb..

if your talking about progressive blocksize movements that are automated by the protocol and not dev decisions per change.. then you are now waking up to the whole point of dynamics.. finally your looking passed blockstream control and starting to think about the network moving forward without dev spoon feeding . finally only took you 2 years (even if you think that hard limiting it at silly low amounts is good)

give it 2 more years and you will wake up to hard limit of 4mb and soft limit that moves up in increments.
EG
like the last 8 years (rplace hard with consensus and soft with policy, and you will start to understand)
1mb consensus 0.25mb policy 2009-2011
1mb consensus 0.5mb policy 2011-2013
1mb consensus 0.75mb policy 2013-2015
1mb consensus 0.99mb policy 2015-2017
to become
4mb consensus 2mb policy 2017-2018
where policy grows

oh and guess what.. pools never have just jumped from 0 to 0.25.. or 0.25 to 0.5..
even when policy allowed it, pools took things cautiously to avoid orphan risks

so say
4mb consensus 2mb policy 2017-2018 was implemented
pools wont make a 2mb block the very first block of activation. they would test the water with 1.000250mb to see the risks, timings issues of bugs orphans etc.
and increment from there.

you may argue "but whats to stop a pool jumping to 4mb".. well the same reason pools didnt jump to 1mb.. and instead themselves went up in safe increments to protect their own risks of orphans and other issues (as my last paragraph explained)
also thats where nodes would have an extra safeguard.. but ill leave you to take a few years to realise the extra safeguard. which is what dynamics is all about.

so go spend 2 years shouting nonsense/irrelevant until it finally dawns on you
have a nice 2 years

The quadratic hashing time issue is a non-problem. Miners employing parallel validation do not fall victim to extended time validating blocks containing aberrant large quadratic hashing time transactions. Instead, they orphan such blocks. By continuing to mine and validate on other threads while the validation of the aberrant quadratic hashing time block runs on one other thread. Miners who continue to make blocks with such transactions will eventually bankrupt themselves. All without doing any damage to the network. Problem solved.

What implementation includes parallel validation? Oh yeah... BU does.

Given the massive amounts of ram required by ultra large transactions that are heavy in sigops that would be prone the quadratic scaling laws, validating yet another block in parallel is an excellent way of using even more ram. High ram servers with 256GB may be able to cope temporarily with it but normal machines and even normal servers will likely run out of memory and kill bitcoind.

Which implementation has had out of memory issues already? Oh yeah... BU did.

This seems to be one of the center points of the discussion to me. Lauda, can you confirm I got it right?


@franky1
SWHF shares most of the properties you are bashing. I can't see the point you are trying to make. What alternative solution do you propose?

Well, saying that it would "cost them" differently is also incorrect. If you have two transactions:
1) native-to-native which is part of a big group of spam with X fee.
2) native-to-segwit or segwit-to-segwit which is a genuine transaction with a fee equal to X, it doesn't matter much for the miner. It costs them the same amount.

There is no debate. I have already mentioned that this would be done with 1 hard fork, so the subsequent rises (1.2 to 1.4 to 1.6 and so on) would be hard coded.

I am not strongly interested in hard fork proposals until I see someone coming up with solutions for the sigops problem.

from the point of view of asics makes no difference.
from the point of view of pools. the pools would have validated a tx before putting it into mempool.. so putting it in a raw(unsolved) block 4xx,xx1 minutes later or 4xx,002 makes no difference to any CPU time of forming a raw block to get a hash to send to asics to solve.

emphasis the quadratic/cpu intensive time only happens once for a pool. when it first gets relayed a tx and validates it to add it to mempool.. the creation of a raw block is just collating data minutes later. not revalidating tx's again

the choice of what gets into a raw block is more about preference. some pools (btcc) love their own internal customers tx's get in fee free. other pools want expensive first. and some pools want to distribute mature rewards to all the external miners first.

some pools want to waste other pools time by making spammy blocks so the first pool can concentrate on the next block while their competitors are hanging validating the first block

also segwit is "supposedly" 75% cheaper. which means pools get 4x less bonus from a segwit tx.

theres also issues of if they add segwit tx's they have to form the 2 merkle. and then have some peers request the pool to strip it down to just the base block..(old nodes connected to pools)*

however some pools would not treat a $0.25 tx as having higher priority than a $1 tx purely because its segwit



very simple keep sigops at a REAL 4k or below 4k per tx.
P.S if segwit went soft first and then removed the cludge to go to 1 merkle after. that means removing the 'witness discount' which then would bring back the quadratics risk of REAL 16k sigops (8min native validation time)*

*(disclaimer their is bait in my last sentence i wonder if you will bite)

I guess the thread title has not helped... it isn't going to be the last time and we'll never be able to continue in small words:)

Do any from both sides (I see the same posters) feel this will ever come to meet in some middle?

If you didn't mine the block, you are going to validate it. If a malicious miner starts deploying quadratic intensive blocks at higher MB (e.g. 2 MB), they could make you constantly be behind them (hence DDOS).

There is a reason for that. You need to re-read what Segwit is about.

That's not an issue.

Which also makes it easier to clutter up blocks to hit the max sigops per block limit. As you'd say it, this is no fix.

Your disclaimer is full of nonsense and proof that you don't understand Segwit. Go back to school.

Why would you compromise when you've delivered an actually proven and working solution for something that has no benefits aside from a capacity increase? ::)

now your starting to see why segwit hasnt fixed it!!

core have already removed the FEE calculation features such as priority, reactive.. nothing to stop them removing the 4x witness scale factor as soon as segwit is activated.. after duping people into activating it..
maybe you need to read the documentation and code and then think of the long term.. not the temporary sales pitch..

because of the tier network preventing old nodes connecting direct to pools, i did * that to say i was baiting you.. i was hoping you would have honesty /integrity to explain why its not an issue.. but you love to hide the bad bits under the rug with empty replies or wrong, irrelevant, not an issue

actually you need to think deeper.. by reducing tx sigops to say 1k and then having 80k blocksigops. without any cludgy maths of pretend counting..
it changes it from being just 5-7 tx to being 80tx to fill a block.

my disclaimer was to await your reply to see how practical, critical, and honest you would be .. but you stayed silent by just saying "t does not matter" without explaining why. knowing you would dig yourself a hole should you explain

but atleast in a few area's you are starting to think beyond the temporary promotion.. now you really need to start wearing the critical hat more often and look passed the blockstream defense you keep trying to promote

Will give it another try:

1. There are certain structural oversights in Bitcoin that need to be fixed. Without fixing this altcoins will probably overtake Bitcoin in the long run.

2. SegWit has several benefits (https://bitcoincore.org/en/2016/01/26/segwit-benefits/) including short term higher transaction capacity, long term much higher transaction capacity through second level transactions and also safe (!) increasing of the block size. If Satoshi would design Bitcoin from scratch today he would probably do it somewhat similar to SWHF.

3. SegWit a good solution, ready for action and well tested. Even some of it's strongest opponents secretly admit it is "good" ('verified chatlogs' (https://www.reddit.com/r/Bitcoin/comments/67nc2r/verified_chatlogs_why_jihan_and_jiang_want_to/)).

4. There are two possible ways to deploy/implement SegWit, as a softfork or as a hardfork. SegWit as a hardfork would allow a slightly cleaner implementation but would also require replay protection (as the exchanges have specifically asked for lately). SWSF does not require replay protection assuming a hashrate majority. Replay protection is difficult thus SegWit as a hardfork would altogether cause more technical debt than SWSF. Also a hardfork is generally considered of higher risk and would take a longer preparation time.

5. Because of a block verification processing time vulnerability that increases quadratically with block size, increasing the block size is only possible AFTER SegWit is active and only for SegWit transactions.

6. Any alternative to SegWit SF would take at least half a year longer in implementation and testing.

7. A mining hardware manufacturer and a rich guy are trying to prevent SegWit from being activated probably because of financial incentives and power political reasons ('verified chatlogs' (https://www.reddit.com/r/Bitcoin/comments/67nc2r/verified_chatlogs_why_jihan_and_jiang_want_to/)).

8. Watching altcoins with SWSF flourish pressure from the users will become so high that Bitcoin finally will get SegWit SF, probably by the miners accepting it after all.

There is no risk at 1 MB, and with >1MB for Segwit you'd have linear time so it has been fixed in this context.

The fee calculation is entirely irrelevant and priority has been mostly unused in ages. You still don't understand why the scale factor was included. Go back to Segwit 101.

It is still a non-issue.

Exactly what would that change? Nothing. You'd disable a lot of use-cases in which these sigops may be needed, in order to make it <20x more expensive to attack the network this way.

Ironically you don't explain anything yourself. All you write is "it is x y z". ::)

your still thinking from the HOPE of a 2merkle soft activation where people move to segwit tx's..
your question was
"If a malicious miner starts deploying quadratic intensive blocks at higher MB (e.g. 2 MB), they could make you constantly be behind them (hence DDOS)."

stop flip flopping to hide the risks of a 1 merkle segwit, by then round circling back to a 2 merkle*.
stop flip flopping to hide the non-fixes of a 2 merkle segwit, by then round circling back to a 1 merkle.

by lowering the txsigops (not fake the maths) you can both allow more tx's in and reduce the CPU demand of native tx's no matter if people are using segwit or not
P.S
*you forget to remind yourself that segwit linear time is ONLY IF people move to segwit keys (which malicious pools/spam users wont do) so stop trying to assume segwit will help, because pools/users that want to be malicious wont use segwit keys

No. You are confused again and need to re-read what I was talking about. You mentioned Segwit into a statement that had nothing to do with it, and lots again.

Both points are wrong. This:
1) Does not allow for more TXs. All it does is disable some use-cases which require more sigops.
2) It does not reduce CPU demand at all. Those 1k sigops still have quadratic validation time.

I did not forget anything and have already told you the answer to your nonsense. A malicious actor will be strongly weakened by the prioritization of native ->Segwit and Segwit -> Segwit transactions.

1. it does. because having say 1k txsigops and 80k blocksigops  vs 4k(mathematically twisted to be treated as 16k) means you cannot use up all the blocksigops with 5-7tx's but instead need 80+ tx's if your malicious
also
by having 1k sigops for instance it helps keep people to making lean tx's more. ask yourself why should anyone have the ability to make 1tx that uses up 14%-20% of a blocks limit.

2) quadratics of 4k of a few seconds vs 1k thats only a few milliseconds per tx..

EG 80x 1k tx sigops with 80kblocksigop = under 2 seconds CPU time per block..  

EG 5x 4k txsigops with 20k blocksigop= under 50 seconds CPU time per block..  
EG 5x 4k txsigops(math manip to 16k) with 80kblocksigop = under 50 seconds CPU time per block..  

EG 5x 16k txsigops = under 50 minutes CPU time per block..  

so 80x 1k txsigops with 80kblocksigop = under 2 seconds CPU time..   is better than
SFSW: 5x 4k txsigops(math manip to 16k) with 80kblocksigop= under 50 seconds CPU time..  
and better than removing the cludgy math to get a HFSW
HFSW: 5x 16k txsigops = under 50 minutes CPU time..  

do the maths
1 tx of 80k sigops vs 80tx of 1ksigops... both total 80k total sigops. but bcause its broken up into different tx's the CPU time changes where 80tx of 1ksigops is much much better for all reasons

a HOPE of priority of segwit users

CODE should mean more then HOPE

That is nonsensical. It does not allow for more throughput. All it does is make it a little bit harder to abuse sigops to fill up blocks.

They may be use cases which require this. Who are you to censor such transactions?

Irrelevant. It is still quadratic validation time.

No. It is going to happen as long as there are reasonable pools/miners, which we know that there are (e.g. Bitfury).

ill let you argue with yourself


one minute to say pools should and will censor tx's that can spam but then you argue that pools shouldnt censor transactions that can spam

you HOPE pools will prioritise segwit keys out of some faith and dream reasoning
but hate the idea of code prioritising transactions

Dishonest shills cant even keep their own story straight in the same day. 

Another contradiction recently has been: high fees are good...and then: bigger blocks wont fix high fees.

There is nothing to argue about. You don't understand English.

Which is not what I said. I used the word prioritize, which is very different from censoring.

It is not hope, it is reason. Stop trolling already.

Said the baboon working for BU. Ironic. ::)

You don't think the significant mining pools can afford one large server each?

False. Parallel validation routes around quadratic hash time issues, by naturally orphaning blocks that take an inordinate time to verify.

Sorry, it seems people have had their heads FOHK'ed with (Fear of Hard Fork).

There is little difference between the dangers of a soft fork and a hard fork.

In the event of a soft fork we have:
1.) The old chain exists with a more permissive set of rules.
2.) The new chain exists with a more restrictive set of rules.

In a hard fork we have:
1.) The old chain exists with a more restrictive set of rules.
2.) The new chain exists with a more permissive set of rules.

So they look exactly the same during a chain split.

The only difference is that a soft fork is backwards compatible because its more restrictive set of rules.

In the event of a successful soft fork, older nodes continue to operate as normal.
In the event of a successful hard fork, older nodes become unsynced and have to upgrade.

In the event of a contentious fork, hard of soft, it becomes an economically damaging clusterfuck until the winning fork is determined (the longest chain) or a bilateral split occurs (the minority chain implements replay protection)*.

* Strictly speaking the software forking away from the existing protocol (hard of soft) should be the version that implements relay protection as you cannot demand the existing protocol chain to change its behaviour. In practice though, the aim is not to create a permanent chain split and achieve consensus, so the minority chain should end up orphaned off, and any transactions that occur during any temporary chain split should end up confirmed on the main chain.

this is why you dont let TX's get MORE bloated when block sizes increase.
best option is to keep tx's at or below 4k sigops. the quadratics are copable and capable on normal machines

EG things like
< 4ktxsigops
< 100k txmaxbytes

that way for instance..
spam attack
1mb block  requires 5tx sigop spam or requires 10tx bloat data spam
2mb block  requires 10tx sigop spam or requires 20tx bloat data spam
4mb block  requires 10tx sigop spam or requires 40tx bloat data spam

some people think going up is ok (facepalm) (where sigops per tx and bytes per tx goes up with blocksize)
1mb block  requires 5tx sigop spam or requires 10tx bloat data spam
2mb block  requires 5tx sigop spam or requires 10tx bloat data spam
4mb block  requires 5tx sigop spam or requires 10tx bloat data spam

some people think going down is bad (facepalm) , yet if txsigops went to say 1k and txmaxbyte =50k
1mb block  requires 20tx sigop spam or requires 20tx bloat data spam
2mb block  requires 40tx sigop spam or requires 40tx bloat data spam
4mb block  requires 80tx sigop spam or requires 80tx bloat data spam

where by at 4mb block for instance even using max tx sigops the time to process is seconds not minutes

And that's your solution? Have only 10 nodes that can stay online worldwide during that parallel validation period and crash the remaining 6000+ nodes worldwide at the same time?

Surely that won't happen with a simple 2MB HF.  So if you are sincere about capacity increase, why not that now and maybe segwit later?

Yes. Anyone who wants to be a central element of a multibillion dollar system is going to have to buck up for the requisite (and rather trivially-valued, in the scope of things) hardware to do so.

Bitcoin's dirty little secret is that non-mining nodes provide zero benefit to the network at large. Sure, operating a node allows that particular node operator to transact directly on the chain, so provides value to that person or persons. But it provides zero utility to the network itself. Miners can always route around the nodes that do not accept their transactions. Miners don't care whether non-mining nodes accept their blocks - only whether other miners will build atop their blocks.

And the number will not be ten - it will be many more. As again, anyone who wants to be able to transact directly upon the chain in a trustless manner will need to buck up to the hardware demands.

Thanks. If anyone wants to know what BU'ers think of what the system is and should be, I think I can now refer them to your post.

I rest my case.

Ok, I think I have understood the quadratic scaling problem now (thanks to @Lauda, @franky1, @jbreher and @-ck), my error was to think that only miners were affected, but as it affects mainly validation, all full nodes are affected and a malicious miner/pool could try to "kill small full nodes" or even smaller mining pools via a spam attack. So my opinion is reinforced that in the case of a block size increase, legacy transactions would have to be restricted by the protocol in some way.

You know about flextrans right?

Makes it better, but doesn't fix it. It still doesn't scale linearly.

No, you may not. If you want to have a handy reference to what one BU'er -- namely myself -- thinks, then you can refer them to my post. I do not speak for others.

Do you care to argue the facts above? Or shall you just rely on crowd sentiment as sufficient to escape any reasoned discussion?

No I think I'm quite done here, thanks.

It is possible to fix it in the near future. How to spread the information then it already works.

Yup. This is exactly the nonsense that they are preaching. Let's make Bitcoin a very centralized system in which you can't achieve financial sovereignty unless you buy server grade hardware costing thousands of USD. ::)

Correct. Everyone is affected and the "parallel validation" BUIP that attempts to solve it is a joke. It does not solve anything.

Wouldn't Flextrans have the exact same problem? I haven't studied Flextrans in detail, but from what I remember it would enable a new "version" of transactions without malleability. But wouldn't legacy transactions ("v1", as they call it here (https://bitcoinclassic.com/devel/Quadratic%20Hashing.html)) continue to be allowed in this proposal, too? In this case it could lead to the exact same situation where a malicious miner or pool could try to spam the network with legacy transactions to "take out" some competitors.

Hi OP, don't spread such naive words.

Roger and miners have already agreed to activate SW first, only if BS devs show some sincerity on further blocklimit increase. But what's BS devs' response? They refuse any proposal and continue to spread lies and personal attacks on Roger and miners.


Bitcoin is not your enemy. Wake UP. Let's fight against BS.

yep flex trans is a new tx type just like segwit.. requiring people to choose to use them, but doesnt solve the issues with the old native(legacy) transactions

the solution is to limit the sigops. and develop a new priority fee formulae actually works that charges more for people that bloat and want to spend too often.

things like hope and faith that pools will do the right thing are not enough, i actually laugh that the blockstream(core) devs actually removed code mechanisms and then went for banker economics 'just pay more'

i laughed more when reading their half gesture hopes and utopian promoted half baked promises meant more to them then actual clean code

No, that is no solution whatsoever. All that does is kill use-cases which require higher sigops (see certain multisig).

Each wallet can and has developed their own fee calculations.

Statements like these make you look like an idiot. Mining pools have primarily stopped using priority long before Bitcoin Core removed it from their code (which is also the reason for its removal).

certain multisig.. pfft. and why do they deserve to have 20% of a block, without paying 20% of the price

yep but core removed some irrational ones. but also removed some rational ones. the network as a whole should have atleast some agreed(consensus) limits to make users be leaner and less easy to spam,..

im still laughing how you want to prioritise X but then you dont want to prioritise Y..


because that fee formulae was just a rich vs poor mechanism. core didnt even bother being devs to develop a better code formulae.

yep developers didnt develop
yep coders didnt code

instead they shouted "just pay more"
which is still the rich vs poor failed mechanism

It looks like someone hasn't been reading the Bitcoin Core code again. :)

---

This PR also negates any concern of your "easy to spam via 5 max sigops TXs" nonsense:
https://github.com/bitcoin/bitcoin/pull/8365

yor not understanding it
1. the 5x is about the blocksigoplimit/5=txsigop limit.. (consensus+policy)

2. the 'larger than rather than reject' is more about exceeding 100kb of data that SOME tx's would accumulate while trying to make 4k sigops.

which is where i knew you would knitpick.. so i pre-empted your obvious crap.

with a TX that stays below the:
bloat of 1mb block
bloat of 100k 'larger than' limit (of REAL BYTES)

while filling the blocksigop limits to prevent any other transactions getting in.

PS the cludgy maths that core has in the 'pull/8365' is just about trying to assume a fee for the tx. but.. ultimately if a pool was not using that cludgy maths/core implementation for the FEE. a pool would add the TX with a cheaper rate that doesnt have the cludgy maths.

this is why REAL rules. real code, should be used.. not bait and switch hope and faith cludgy maths crap.

Some people think that you aren't completely uneducated. That's what the only misunderstanding here is.

There is NO such thing as a TX sigops limit as a consensus rule. It is a RELAY policy. Any miner can create and include a transaction consisting of more than 4k sigops.

You don't understand the code behind a simple calculator, yet alone "real rules & real code". Get another job franky, seriously. I debunked you 20 times in 1 week.

you have not debunked crap.
you have just not seen the whole picture.
you have not seen things from the whoole network point of view.. you just love the word games

i dont even know why im interacting with someone that cant even read c++
lauda.. same advice i gave you a year ago
learn C++
learn to read passed the 1 paragraph sale pitch.

its hard enough to try explaining things in such short amounts before you lose concentration to just shout
"nonsensical" "wrong because shill" " they paying you enough" as your failsafe reply when you cant understand things.

but now you have gone beyond even trying to learn anything.

you have become a hypocrit by making arguments that actually debunk your own earlier arguments

by saying nodes can by pass the fee math cludge is correct.
but thats why real rules need to be placed in the consensus header file. rather than the cludge

P.S the blocksigop limit is in the consensus. but from a network wide overview. where the maths cludge of core can be by passed. my initial arguments still stand.

i tried entering your narrow mindset by pretending that everyone was following core code and even saying i was wrong when looking at cores cludge specifically.. (rather than network overview) and still shown how it can be abused. just to try getting you to understand the risks. but then you go and play semantics ..

your not trying to see the network risks, your just playing word games.
WAKE UP

a txsigops limit of <4k in consensus header file solves the native quadratics.!!
wake up

I don't even do C++ and it seem rather obvious that I understand more of it than someone claiming that he knows it (you). That is just sad.

You should write a book about lying and shilling. ::) Simple example of easily debunked bullshit.



No. You didn't even admit that you were wrong about the in-existence of the 4k limit per TX, as that's a policy rule. How sad.

thats maths cludge is CORE centric... not NETWORK consensus

from a network overview.. if pools used the 80k CONSENSUS but were not following cores CLUDGE maths.. then it does make things worse
there needs to be a proper RULE of 4k sigops that does not change.
REAL RULE. not math cludge. not implementation defined but real NETWORK consensus RULE

other implementations also have the 80k blocksigops for NETWORK CONSENSUS. meaning that due to segwit. it can make things worse.
ESPECIALLY when core removes the cludge to make a 1merkle version which they promise(but wont uphold) after the soft activation

Nope, that is completely wrong. The 80k limit is post-SW and legacy sigops count as 4x more. Therefore, for legacy transaction the limit does not change at all. It is 20k and will continue to remain 20k,

No.

---

See how I baited and double debunked you? You don't even understand the ELI5 explanations from sipa & luke-jr, let alone C++. :D

thats maths cludge OUTSIDE of network consensus rules..

but from a network consensus rule its not what you think

there needs to be a network consensus txsigops rule of <4k to solve the native risks

---

after a year you have prefered to just defend core.. rather than the network.
anyway.. your only wasting your own time with your games.
have a nice year kissing ass

No. The 4x sigops counting for legacy transactions is enforced by SW rules.

pools can ignore the 4x sigop count just like they ignored the priority fee formulae. by not following all the wastful cludgy maths stuff outside of consensus
which is where your hopes and expectations lay..

thats why having <4 maxtxsigops in the consensus.h header file would solve the issue so easily

---

maybe best you spend more time managing sig-spammers and taking a cut.
because you have made it clear you wont take time to learn c++. and prefer just to spam topics with empty word baiting for an income

Eh? for real? Then how can one understand something when one admitted to not knowing something?

A bit like me saying:-

I don't know how to make a nuclear bomb, but i understand more than the nuclear scientists. ??? ???

I did not look into it but from what I hear it sounds more like a resource consuming band aid. Why not a proper fix with less CPU cycles?


It is not fear but the expectation of 'clusterfuck' (as you put it).

Wait a second, there only exists a single chain as the old chain blocks are being orphaned (I am explicitly talking about a softfork with a hashrate majority as stated above).

No, not at all. With the hard fork the old chain is not 'corrected' to follow the new chain.

This is a big difference, isn't it?

Does a 70% hashrate majority still count as contentious? I don't think that would be a big problem for a softfork, the old chain would be forced to go along, but with a hardfork there would certainly remain two chains.

How would you implement replay protection for a soft fork, there is only a single chain...

I am considering making my list above a reddit thread as I think it sums up the current situation nicely  ;D

soft or hard.
there are scenario's of staying as one chain (just orphan drama and being either small drama or mega clusterf*ck of orphans before settling down to one chain) dependant on % of majority..

but in both soft or hard a second chain can be produced. but this involves intentionally ignoring consensus orphaning mechanism.. in laymens: not connecting to opposing nodes to see their different rules/chain, to then build own chain without protocol arguing(orphaning)

all the reddit doomsdays FUD is about trying to only mention softs best case, and hards worse case.
but never the other way around because then people will wise up to knowing that bitcoins consensus orphaning mechanism is a good thing and that doing things as a hard consensus is a good thing.

You have an incredibly myopic sense of scale. Allowing the system to keep up with demand requires an investment of well under 1.0 BTC. And what will you say when transactions fees rise above $10 due to the stupid artificial centrally-planned production quota? Over $100? Over 1BTC?

It is not so much a resource consuming band aid, as it is harnessing the natural incentive of greed on the part of the miners (you know, the same force that makes bitcoin work at all) to render the issue a non-problem.

Yes, it takes more memory to validate multiple blocks on different threads at the same time than a single block on a single thread. But this does not only lead to an incentive to not make blocks that take long to validate due to the O(n^2) hashing issue, it also provides a natural backpressure on excessively long-to-validate blocks for any reason whatsoever. Perhaps merely blocks that are huge numbers of simple transactions. And the resource requirements only increase linearly with the number of blocks currently being hashed concurrently by a single node.

More importantly, as miners who create blocks exhibiting this quadratic hash time issue have their blocks orphaned, they will be bankrupted. Accordingly, the creation of these blocks will be disincentivized to the point where they just plain won't be built.

Further, parallel validation is the logical approach to the problem. When one receives a block while still validating another, you need to consider that the first block under validation may be fraudulent. The sooner you find a valid block is the sooner you can get mining on the next block. Parallel validation allows one to find the valid block without having to wait until detection that the fraudulent block is fraudulent is accomplished. Not to mention the stunning fact that other miners do not currently mine at all while validating a block which may be fraudulent.

Last, in the entire 465,185 block history of Bitcoin, there has been (to my knowledge) exactly one such aberrant block ever added to the chain. And parallel validation was not available at the time. But the network did not crash. It paused for a slight bit, then carried on as if nothing untoward ever happened. The point is that, while such blocks are a nuisance, they are not a systemic problem even without parallel validation. And parallel validation routes around this one-in-a-half-million (+/-) event.

By all means, the O(n^2) hash time is suboptimal. We should replace it with a better algorithm at some date. But to focus on it as if it is even relevant to the current debate is ludicrous. It would be ludicrous even without the availability of parallel validation. The fact that BU implements parallel validation makes putting this consideration at the center of this debate ludicrous^2.

OK, but I would call that a hardfork ('ignoring consensus orphaning mechanism').

A SWHF certainly has it's benefits but SWSF is the superior solution IMHO. Some people may see this differently but I guess the majority would agree (if it is only because they trust Sipa and the other core people in their judgement).



Seems like it gives an incentive to mine small blocks? One would have to check the implications of this change really thoroughly...

But quadratically with block size meaning at 16MB blocks or so a 30% miner might still be able to block all nodes permanently.

For an attacker disrupting the network for a while might pay of via puts or rising altcoins or just by hurting Bitcoin.

See above, might give a bad advantage to small blocks.

This is because blocks were and are small.

The superior solution is on the table, well tested and ready to be deployed. Parallel validation still require additional limitations as suggested by franky1 for larger blocks. Also let me remind you of the resource discussion further up. Of course it is relevant to this debate. Why do you oppose the technically sound and sustainable solution? Particularly as it happens to also bring other important benefits?

soft forks do not need to result in a chain split
hard forks do not need to result in a chain split

soft involves just pool agreements to change something, thats just a network upgrade with one chain
hard involves nodes agreeing to change something, thats just a network upgrade with one chain

again
soft forks do not need to result in a chain split
hard forks do not need to result in a chain split

when some pools disagree and decide to intentionally ignore/ban/reject blocks/communication and the opposition continues. thats a chain split
when some nodes disagree and decide to intentionally ignore/ban/reject blocks/communication and the opposition continues. thats a chain split

soft can intentionally cause a split
hard can intentionally cause a split

and again
soft forks do not need to result in a chain split
hard forks do not need to result in a chain split

by thinking all "hard" actions = split.. and all "soft" actions = utopia.. that is taking softs best case scenario and hards worse case scenario. and avoid talking about the opposite

Please explain how a softfork would cause a chain split. A node ignoring/banning/rejecting blocks/communication means it diverted from the chain protocol which equals to a hard fork in my point of view.

https://www.reddit.com/r/Bitcoin/comments/69ypvg/segwit_situation_in_layman_terms/

FTFY

a hard chain split is about the nodes(users) doing something to cause 2 chains.
a soft chain split is about the pools doing something to cause 2 chains.

EG a soft chain split is even though nodes dont have to do anything. pools ignore each other purely based on a version number where the pools then decide to either join X or ignore X and build on Y

leading to the nodes that without doing anything end up following what they can happily accept

---

i just read your reddit summary and laughed my head off..

you do realise the only establishment causing drama are the portfolio of DCG (blockstream, btcc, coinbase, and more) with all their REKT campaigns, accusations, Pow killing proposals, deadlines, blackmails, bribes.

other non blockstream endorsed implementations are just plodding along not making threats and ven laughing at blockstreams attempt to get non-blockstream implementations to split, by simply saying 'no thanks w wanna stay as a peer network'

put it this way right now blockstream could make a 1merkle version that actually unites the community that can offer alot more features and set off a 6 month timeline. (afterall core think its ok to release 5 versions of software /year (0.13-0.13.1-0.13.2-0.14-0.14.1))

but blockstream motives are just to push the cludgy soft 2 merkle version and even if still veto'd in november will push on as the cludge version right upto the en of 2018 and try making it mandatory.
in short they cannot take no for an answer or dcide they should do something better

No. As I explained (did you even read?), parallel validation routes around the quadratic hash time issue.


No. As I explained (did you even read?), parallel validation routes around the quadratic hash time issue. A Bitcoin network with a significant proportion of miners implementing parallel validation can not be stalled by quadratic hash time.


There was no resource 'discussion' upthread, an inadequate strawman of resource consumption was used to cast aspersions upon parallel validation.

I oppose The SegWit Omnibus Changeset mostly due to considerations other than segwit itself. Namely: the SF nature; the backdoor of versionbit changes; and the centrally-planned magic 4:1 ratio. But mostly because the 1.7x or 2x or whatever capacity increase it ends up being is too little, too late, and we'll just be back at this same argument before the year is up.

A node will always follow the longest chain of blocks it considers valid. What have pools to do with it? Once again ignoring version numbers sounds like a protocol violation = hard fork.

Glad I could entertain you  :)

Never heard about dcg before, quite interesting (though offtopic). Would be interesting to know how much of a stake they hold in all these companies listed on their website. Regarding your accusations I feel these rather come from the BU side (I read both r/btc and r/bitcoin).

Sorry, I can't figure out what you are saying here.  :-\

---

Yes I did but I realize now I took a wrong train of thought at some point, sorry.

It's difficult to embrace a solution by someone with a track record as bad as BU recently if there is another more sustainable solution available by someone whose code I used without issue for years.

ok, this move the discussion forward.

As above: SF with hashrate majority safer than hardfork, replay protection is difficult

From the other point of views it allows for easy upgrades. I can't imagine core could pull of anything that really goes against the will of the user majority. People would simply hard fork away. Same if they will not increase the block size if it is safely possible.

Based on historic tx data and expected SW tx sizes I guess? This is concern trolling.

Better than nothing! And you are completely ignoring we need SegWit regardless of tx capacity.

Faster than anything else.

Possibly but by then we have learned more about larger blocks in a safe way. Also we will know more about about lightning and how much time it will be able to buy us. This could make a difference of a factor of ten or more and buy us quite some time. Think of it as an opportunity. We can always hardfork later on.

Bitcoin is fine, confirmed by price action. Segwit or BU will spook investors. Bitcoin is the gold standard of cryptocurrency, it is too big to change.

If we don't do anything we might as well bury Bitcoin right away. Altcoins will overtake quickly, just look at Litecoin.

As for the price action it could mean:

• current investors have no idea what they are doing
• current investors don't care
• current investors are optimistic a good solution will be found in time
• Bitcoin is undervalued despite the scaling discussion deadlock

I guess a mixture of the above...

lets kill 2 birds with one stone
1. blockstream wantis the network to split to give blockstream dominance
2. non blockstream implementations refusing to split.. wanting to keep the diverse implementations on an level/even playingfield

(gmaxwell is a founder and CTO of blockstream and also the lead dev of core and also the main moderator of technical discussions)

but in his own words

No, Litecoin and alts aren't taking over the safe haven status of Bitcoin IF Bitcoin remains as is today. It's the safe haven status that investors are after. Buying coffee can be done with alts and credit card.

^^ Totally agree with this.



^^ Totally disagree with this.

I think OP has realized that CORE are ACTUALLY your enemy now conveniently, given the fact that most Core members are against HF even months after SegWit.