Gold collapsing. Bitcoin UP.

[solex]

@freetrader The DimWit attack looks like a problem. So, SW can't be used by anyone who cares about their money until it hits an exclusive trigger level, presumably 95%, and only at that point can SW reject all blocks where the segwit scripting is invalid?

Waiting for Adam Backtrack to embrace the 75% threshold with grace period
3,2,1...

 

[freetrader]

@solex: the way I understood the attack is that it effectively puts transacting parties on the network at risk even before SegWit is released - so long before SegWit hits an exclusive trigger level.

When asking whether people would be issuing SegWit transactions before it activates at 95%, you may find answers like these given:


As I see it, it's a matter of there not being enough SegWit nodes to prevent consensus building on top of such attack blocks. Thus, if proven to be realistic, the attack would depend only on two things:

1. the broken aspect of SegWit's current soft-fork design
2. SegWit eventually activating, i.e. spending of such diverted outputs becoming feasible

If true- yikes.

UPDATE April 4 2016: this attack has, to my satisfaction, been shown to be impossible. Non-segwit nodes would still try to validate the input to the malicious tx , find it invalid and reject the malicious block.

 

[cypherdoc]

Lol, @johnyj's page turner:

 

[albin]

Can somebody explain this attack? I'm having a hard time following, I think there's some crucial aspect I'm not picking up on.

 

[go1111111]

@go1111111 thats not so, Bitcoin miners and sidechain miners are not necessarily the same miners.

If a sidechain is merge mined, every sidechain miner will also be a bitcoin miner, otherwise the economics don't make sense for miners. And those miners will be willing to hash more to get those sidechain fees, so this helps Bitcoin security. It's true that not every Bitcoin miner will be a sidechain miner, but to the extent this is true it just means the sidechain is less secure.

If the sidechain is not merge mined, then the tx fees on the sidechain don't encourage any more security for Bitcoin. So if people made fewer Bitcoin transactions on the main chain and made sidechain transactions instead, Bitcoin security could fall by the amount of fees of those transactions. However it seems unlikely to me that any major sidechain that used PoW would not be merge mined.

@go1111111

then why haven't miners flocked to merge mine Namecoin? and of those who did, f2pool comprises what, 70% of hash?

I'm guessing namecoin fees are negligible.

 

[cypherdoc]

Can somebody explain this attack? I'm having a hard time following, I think there's some crucial aspect I'm not picking up on.

yeah, i think i got it. i don't think franky1 is right.

basically franky1 wants to perform a miner attack where he self mines a SW tx spending to himself weeks/months before SW actually activates. franky believes this miner can cement into the blockchain this ANYONECANSPEND tx to himself even though it's a non standard tx. because the miner has the privkey to this address he just spent someone else's coins to, AFTER SW activates, he thinks the miner can use that privkey of that address to then spend them.

the reason the miner can't do this is that the miner doesn't have the privkey from the original owner's address, therefore the attacking SW tx is invalid.

 

[solex]

@cypherdoc
The variation that I was thinking of is where an attacker, with modified SW code creates invalid witness data which is included in the merkle-root of the witness block and therefore linked to the standard block which successfully stays in the blockchain because the non-SW miners are not checking the SW data, and still have a majority of the hashpower.

 

[Richy_T]

For some applications, this is undesirable (this is where my knowledge on the matter ends, unfortunately, for the time being: don't ask me why ).

This is correct but is fixable entirely without Segwit.
[doublepost=1459733375][/doublepost]

@albin: maybe, but in the case of MtGox the fault was completely theirs (and with a lot of stupidity).

Actually, it appears that there was no fault because the whole MtGox malleability fuss was merely a smokescreen for other malfeasance that was going on and had no basis in anything that was actually happening..

 

[AdrianX]

If a sidechain is merge mined, every sidechain miner will also be a bitcoin miner

That's OK, it's the fact that not every Bitcoin miner gets fees from sidechain transactions that leaves less revenue for Bitcoin miners over time it results in less security.

I'm not concerned about the sidechains that have no value it's the ones that have utility like lower tx fees that are the problem they'll suck the value out of Bitcoin and the bitcoin tx fees with it leaving Bitcoin less secure.

I'm fine with competition but adding features to Bitcoin by design that cause it to fail is where I take issue.

 

[cypherdoc]

@cypherdoc
The variation that I was thinking of is where an attacker, with modified SW code creates invalid witness data which is included in the merkle-root of the witness block and therefore linked to the standard block which successfully stays in the blockchain because the non-SW miners are not checking the SW data, and still have a majority of the hashpower.

why would non SW miners have a majority of the hash when SW won't activate unless 95% of them support SW?

 

[solex]

They won't. However originally it was mooted that SW tx would occur before 95%. Even now the threshold is uncertain.

Of course a major annoyance about the whole thing is its grand designer, Wuille, has gone dark and not answered any of the many reasonable questions raised by the community, leaving other people to answer who all seem to have an incomplete picture,

 

[freetrader]

They won't

Unless the majority of hashing power upgrades to SegWit before such an attack happens, how can it be excluded (i.e. guaranteed that consensus won't form on the invalid tx)?

If I understand correctly, the 95% threshold is not a limiting factor to producing SegWit transactions... although I wish someone could provide me with proof of the contrary.

It's back to reading SegWit BIPs for me. I need to understand how this would be prevented.

EDIT: So far from reading the BIPs again I've found only this in BIP141:

What a non-upgraded wallet cannot do

• Validating segregated witness transaction. It assumes such a transaction is always valid

and this in BIP143:

Backward compatibility:

As a soft fork, older software will continue to operate without modification. Non-upgraded nodes, however, will not see nor validate the witness data and will consider all witness programs, inculding the redefined sigops, as anyone-can-spend scripts.

UPDATE April 4 2016: this attack has, to my satisfaction, been shown to be impossible. Non-segwit nodes would still try to validate the input to the malicious tx , find it invalid and reject the malicious block.

 

[Dusty]

Actually, it appears that there was no fault because the whole MtGox malleability fuss was merely a smokescreen for other malfeasance that was going on and had no basis in anything that was actually happening

I remember the thing happening for a few people, so the problem was surely existing, but as you correctly state, that had nothing to do with the massive fraud that led to MtGox failure.

 

[freetrader]

w.r.t.:

[a non-upgraded node] assumes such a [SegWit] transaction is always valid

someone claimed that this refers to a transaction that is spending another segwit transaction, but that the first nonsegwit > segwit is validated, and franky1's attack would therefore fail.

Is this correct?

And therefore, is franky1 wrong here?
https://bitcointalk.org/index.php?topic=1423718.msg14404864#msg14404864

UPDATE April 4 2016: this attack has, to my satisfaction, been shown to be impossible. Non-segwit nodes would still try to validate the input to the malicious tx , find it invalid and reject the malicious block.

 

[freetrader]

the reason the miner can't do this is that the miner doesn't have the privkey from the original owner's address, therefore the attacking SW tx is invalid.

The whole attack is based on "who's going to tell?"

The attacking miner is not going to broadcast the SW tx - only the block.
Alledgedly, non-upgraded nodes can't validate this tx - at least no-one has credibly explained to me how they would do that. So I don't yet believe they can validate and therefore reject the malicious block.

I would like to know - what will happen 2000 blocks later when SegWit nodes figure out that this block contained an invalid transaction?

UPDATE April 4 2016: this attack has, to my satisfaction, been shown to be impossible. Non-segwit nodes would still try to validate the input to the malicious tx , find it invalid and reject the malicious block.

 

[Dusty]

I would like to know - what will happen 2000 blocks later when SegWit nodes figure out that this block contained an invalid transaction?

Franky1 does not understand how bitcoin transactions are built and confuses inputs with outputs, so his "attack" is nonsense.

He can't prepare his transaction in advance because it would be invalid and hence could not be mined (or built upon).

 

[Norway]

I wonder if the only bitcoin ATM in Panama, run by Erik Vorhees, is going to be busy this week, lol!
http://coinatmradar.com/country/165/bitcoin-atm-panama/

 

[freetrader]

@Dusty : agreed, the attack franky1 proposed would not be possible.

Thanks for explaining.

 

[JVWVU]

 

[Norway]

Thought experiment:
What kind of hardware and bandwidth would be needed for a full node at 100 000 transactions per second? Anybody?