Topic: Last Time. In small words. Why 2MB impossible. Why Soft Fork. Why SegWit First.. - page 4. (Read 6499 times)

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?

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)

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.

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?

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.

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.

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

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.

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.

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.

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

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.

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

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.

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

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?

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

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.

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/

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.