Bitcoin Forum
July 18, 2024, 12:48:50 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Transaction malleability 2017  (Read 1575 times)
bitaps (OP)
Member
**
Offline Offline

Activity: 148
Merit: 45

https://bitaps.com/


View Profile WWW
March 12, 2017, 08:40:37 PM
 #21

2 transactions try to spend same coins and as result create different output coins

This is double spent
A transaction malleation attack does not change the outputs in any way whatsoever. There are no "different output coins". The receivers still get the Bitcoin, regardless or whether the original or the malleated transaction confirms. Transaction malleation is not a double spend attack. Nor is it an attack on the Bitcoin network but rather it is an attack on poorly written wallets and services.

Coin this is link to Transaction Hash and output number inside this transaction. In case transaction hash changed coins that created by this tx also changed. So we have 2 different txs hashes and have different coins in UTXO.  Yes all this coins related to same bitcoin address.
But this is different coins, but input coins is same. You can  admit it or not, but technically this is double spend.


bitaps (OP)
Member
**
Offline Offline

Activity: 148
Merit: 45

https://bitaps.com/


View Profile WWW
March 12, 2017, 08:54:18 PM
 #22

Right! Any double spent attempt have one winner tx and losing tx or few losing txs

So they can trick lets say bitbay that don't wait for confirmation to double sped - interesting.

Quote
Some online chatter regarding the issue revolved around the idea that the attack is political; trying to influence developers and stakeholders to come to a solution to the so-called malleability issue (which Segwit is intended to solve).

For me all know that "malleability issue" but BU Cheesy shit this like nothing happened everything is ok you can makes attacks and what now ?
For those BU supporters waiting 30min for confirmations is not big deal.
I think that Bitcoin have to fix security holes that shout this is your foud you sould be wait for 30 min confirmations if you have luck because not you can wait up to few hours Cheesy

2 transactions try to spend same coins and as result create different output coins

This is double spent
A transaction malleation attack does not change the outputs in any way whatsoever. There are no "different output coins". The receivers still get the Bitcoin, regardless or whether the original or the malleated transaction confirms. Transaction malleation is not a double spend attack. Nor is it an attack on the Bitcoin network but rather it is an attack on poorly written wallets and services.

so how "malleation attack" fucked up Mt Gox ? they were complaing about that if i good remember that they lost BTC in that process.



Bitclub is not BU supporter, they vote for SegWit. Maybe he want to say that Segwit help us to fix this problem? But this is not true.
Segwit will fix this problem only for witness outputs. All old UTXO set will be still vulnerable for malleability attack. How long will that take to spend all old UTXO?? Grin  

Segwit in softfork mode  will not solve these problems completely.  Before to laugh at BU supporters, better understand in detail in the issue.

piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1356


aka tonikt


View Profile WWW
March 12, 2017, 09:04:30 PM
 #23

Quote
so how "malleation attack" fucked up Mt Gox ? they were complaing about that if i good remember that they lost BTC in that process

It's not really confirmed whether mtgox funds were lost through some kind of malleability attack.

That's what they were claiming at some point,  but they never showed any proofs, or even a technical explanation of how that would actually be possible.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
piotr_n
Legendary
*
Offline Offline

Activity: 2053
Merit: 1356


aka tonikt


View Profile WWW
March 12, 2017, 09:11:39 PM
 #24

It definitely looks like some statement from the mining pool, saying 'if we won't activate segwit, look what can be happening'.

Well, I've seen it...
And I'm not impressed, frighten or shocked. Smiley

Even though I'd like to see segwit activated.
But not as much as most of the supporters Smiley

I also spent my time to add segwit support to my software. It was fun and I won't be crying if this doesn't get used.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
bitaps (OP)
Member
**
Offline Offline

Activity: 148
Merit: 45

https://bitaps.com/


View Profile WWW
March 12, 2017, 09:23:55 PM
 #25

Segwit will not fix this problem! To fix this problem we need segwit + hardfork (restrict negative S value)


Segwit is good improvement, but we need the solution to give ability change block size and this thing very important.
Yes Segwit will get more txs inside 1 MB blocks.
But in case we not accept change block size solution  today, to come that day when we will hit the block  limit again, at that time bitcoin infrastructure will grow significantly. Do hard fork will  be more painful than do it now!

Also accept solution to give ability change block size, this is not mean that we should change block size right now.

cr1776
Legendary
*
Offline Offline

Activity: 4102
Merit: 1306


View Profile
March 12, 2017, 10:38:48 PM
Last edit: March 12, 2017, 10:49:26 PM by cr1776
 #26

Quote
so how "malleation attack" fucked up Mt Gox ? they were complaing about that if i good remember that they lost BTC in that process

It's not really confirmed whether mtgox funds were lost through some kind of malleability attack.

That's what they were claiming at some point,  but they never showed any proofs, or even a technical explanation of how that would actually be possible.

The hypothesis regarding mtgox (fed by them, iirc) was that they were relying on transaction IDs to update their internal database of balances.  So, there were withdrawals, then the attacker changed the transaction ID when they broadcast a transaction (the attacker was directly connected to them).  So gox never decreased their balance since they were relying on the TX ID and they would withdraw again.  (There were more details).

Again, poorly written non-bitcoin network software IF that is what happened.

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!