just out of curiousity, why would segwit impact asicboost

[jonald_fyookball]

(moderating to keep strictly on topic):

just out of intellectual curiousity, what does segwit have to do with
the technique https://pastebin.com/RU5SXsFE

thx

[achow101]

The covert method of asicboost requires calculating multiple merkle roots which have a collision in the last 4 bytes of the merkle root. The merkle root is the root node of a tree structure. The left subtree contains the coinbase transaction, and the right subtree contains just a bunch of transactions. A fairly efficient way of calculating merkle roots which collide in the last 4 bytes is to calculate a lot of candidates for the hash of the left subtree and a lot of candidates for the right subtree and just try every single possible combination of left subtree hashed with right subtree. Any combination of left subtree hash and right subtree hash would work since they are not dependent on each other.

But, with segwit, the left subtree becomes dependent on the right subtree, which makes this optimization completely useless as then you can't make a list of left subtree hashes and right subtree hashes and just try all combinations. This is due to the witness root hash which must be included in the coinbase transaction. This witness root hash is basically the merkle root but with the txwitness field. It also depends on the order of the transactions, so changing the right subtree of the merkle root will also end up changing the witness root hash, which will change the coinbase transaction in the left subtree and change the left subtree's hash and thus the left subtree is dependent on the right subtree.

[jonald_fyookball]

gotcha. thx

[AgentofCoin]

(moderating to keep strictly on topic):

just out of intellectual curiousity, what does segwit have to do with
the technique https://pastebin.com/RU5SXsFE

thx

Very layman version:

As designed, the segwit data references back into the block's coinbase.
The ASICBOOST works by anticipating half the proof of work answer before
it is fully performed. It is basically taking advantage of a loophole in the PoW.

With the SegWit's new Coinbase info, this loophole can not be performed.
This anticipatable second half of the PoW now must do the full PoW.
This is why some are claiming that this is a cheat or exploit, because
PoW is not being fully performed by this miner, while the others are
doing their jobs, presumably.

So, if we ignore this and we allow miners to all do ASICBOOST as is, then
developers can never use the Coinbase in interesting ways to "upgrade" Bitcoin
with new ideas and features. This would be a major blow to many future
possibilities for the network. Even Satoshi understood the Coinbase could be
used for references and anchoring.

Interestingly, "Fraud Proofs" that Satoshi originally envision, may not ever be
possible if we can not add new ref codes to the Coinbase.

This is why it is very significant. It isn't just an exploit, it prevents future
possibilities if it is allowed to continue.

[piotr_n]

(moderating to keep strictly on topic):

just out of intellectual curiousity, what does segwit have to do with
the technique https://pastebin.com/RU5SXsFE

despite what the street says, the immediate impact would be zero.

it's because a miner can choose to only include non-segwit txs inside the block, in which case he doesn't have to include the witness commitment, so he can just keep using asicboost without any issues.

the [economical] impact would appear when there was enough incentive (fees) from mining segwit transaction, as opposed to mining only the old fashion transactions.
the segwit transaction fees would have to grow big enough to exceed the profit the miner has from using the asicboost while mining only the old fashion txs.

so perhaps it would be even more interesting to ask the question:
[if segwit is activated...] what impact would asicboost have on the relation between an average fee for a segwit and a non-segwit transaction?

[jonald_fyookball]

so perhaps it would be even more interesting to ask the question:
[if segwit is activated...] what impact would asicboost have on the relation between an average fee for a segwit and a non-segwit transaction?

I would venture to guess: nothing... as it is operating on the block level, not the transaction level and doesn't have to do with the fee anyway?

[piotr_n]

No, it would definitely have an impact.

Assuming of course that asicboost is a real thing and that it saves like the given 20% of some important costs.

Let me give you an example.

The miner gets 12.50 BTC + fees for mining a block.
Let's say that mining of a block without using asicboost costs him 10.00 BTC (in energy, hardware, staff, rent, taxes, etc.)
Note that we're talking about an average cost per block, over a certain span of a time.
Now, assuming that asicboost saves 20% of energy, lets say that with using asicboost, the cost of mining a block (for the same miner) is 10% lower - that's 9.00 BTC

So he has to choose to either mine only non-segwit transactions, to be able to use asicboost: getting a net profit per block of 3.50 BTC + fees
Or he can choose to mine segwit transactions as well, in which case he can't use asicboost and has to deal with a profit per block of 2.50 BTC + fees

In the second case he has to gather the total fees per block, being at least 1.00 BTC higher to break even.
So it would affect the relation between segwit and non-segwit transaction fees.
It would basically make non-segwit transaction fees cheaper, at the expense of segwit transaction fees.

Or maybe I should start from saying, that after segwit is activated, you as a user can still choose to send your money via segwit or non-segwit transactions.
And the average choice of the average user will most likely be based on the cost of the transaction - he will simply choose the cheaper one.
The rest is just the mechanics.

[jonald_fyookball]

ah i see... but i think if segwit was activated, most of network would be on it before too long anyway

[piotr_n]

ah i see... but i think if segwit was activated, most of network would be on it before too long anyway

well, that's the actual interesting part.

because if you had like 40% of miners not willing to mine segwit transactions, thus delaying the payments...
wishlist 100% of miners would be mining non-segwit transactions, because why wouldn't they...

I don't know about you, but I would rather stick to the non-segwit payments, just to have them confirmed quicker.
especially if a fee for sending my BTC via segwit wold not be so much lower.

[gmaxwell]

it's because a miner can choose to only include non-segwit txs inside the block, in which case he doesn't have to include the witness commitment, so he can just keep using asicboost without any issues.

This is correct, but the covert method would become costly (as you note) and not very covert after a while (which I also think is worth pointing out)-- "why are you giving away free money by not including segwit txn? Hmm!".

I think it's wrong to focus just on segwit here, the interference shows up against most proposed protocol extensions... commited utxo set, stxo, fraud proofs, commited bloom filters... all would have similar interactions with covert boosting.

[classicsucks]

(moderating to keep strictly on topic):

just out of intellectual curiousity, what does segwit have to do with
the technique https://pastebin.com/RU5SXsFE

Because Segwit effs up the block architecture at such a low level...

[gmaxwell]

Because Segwit effs up the block architecture at such a low level...

The incompatiblity is by no means unique to segwit, the vast majority of proposed protocol improvements run into exactly the same issue.

Commited UTXO, Commited Address index, Commited Bloom filters, Fraud proofs, -- just to name a few more.

So what you meant to say was that covert asicboost 'effs' up the block architecture.

[classicsucks]

Because Segwit effs up the block architecture at such a low level...

The incompatiblity is by no means unique to segwit, the vast majority of proposed protocol improvements run into exactly the same issue.

Commited UTXO, Commited Address index, Commited Bloom filters, Fraud proofs, -- just to name a few more.

So what you meant to say was that covert asicboost 'effs' up the block architecture.

I don't think Hanke and Lerner went back in time to break Segwit...

...so I'll meet you halfway - "Segwit and other scaling proposals retroactively break patented asicboost technology".

[AgentofCoin]

Because Segwit effs up the block architecture at such a low level...

The incompatiblity is by no means unique to segwit, the vast majority of proposed protocol improvements run into exactly the same issue.

Commited UTXO, Commited Address index, Commited Bloom filters, Fraud proofs, -- just to name a few more.

So what you meant to say was that covert asicboost 'effs' up the block architecture.

I don't think Hanke and Lerner went back in time to break Segwit...

...so I'll meet you halfway - "Segwit and other scaling proposals retroactively break patented asicboost technology".

No, you are purposefully ignoring the elephant in the room.
The following should be your statement:" "Segwit and other currently unknown future protocol
proposals, upgrades, and additions retroactively breaks patented asicboost technology".

The conclusion is then either certain upgrade paths to the protocol is always wrong or
patented ASICBoost is wrong going forward, and as someone who I believe supports expansion
and not stagnation, you would agree that PoW should be performed without "shortcuts".
If you disagree then lets all agree that ASICBoost use has malformed Bitcoin from a PoW system
to a "Proof of Some Work" system and gimps developers abilities in future proposals/answers.

[franky1]

Because Segwit effs up the block architecture at such a low level...

The incompatiblity is by no means unique to segwit, the vast majority of proposed protocol improvements run into exactly the same issue.

Commited UTXO, Commited Address index, Commited Bloom filters, Fraud proofs, -- just to name a few more.

So what you meant to say was that covert asicboost 'effs' up the block architecture.

it doesnt F up the block architecture. you just have to find a different way of doing things.
you took a short cut using the backdoor luke highlighted in 2015. and last month you realised you hit a wall where the shortcut was a deadend

in future dont wast 1.5 years which shortcuts when doing a proper community desiring node+pool approach would get everything everyone wants without delay, debate and frustration in less time

EG
if you want to mess around with no witness, prunned, etc.. just make that a new brand. call it core lite, let the multibit/electrum guys play with that as a dev project

then YOU could concentrate on a network of proper full node network, not ways to dilute the full node count with all the going soft pretense of "aww its ok to waste 2 years for a messy 2 level (upstream tier nodes) and down stream filtered/stripped/pruned topology."

think about it
if in late 2015 you just done a release that would have been a proper NODE consensus of a single merkle design 4mb block. you would have had more than 80% acceptance of nodes by now. and a community that would have been happy. and no drama and no asic boost blaming for why segwit soft attempt has issues. (because there wouldnt have been a 2merkle approach)