|
I am curious as to how the client knows in the first place if a transaction has propagated, thus allowing spending uncofirmed changed output? I mean your ISP can MITM you or all the nodes connected can just drop it, if you put your tinfoil hat on.
Maybe the miners can be configured to respond to queries about if a transaction is in the mempool, but that opens them up to possible DDOS attacks.
|
|
|
|
get off mark's dick people.
obviously mistakes were made. this technology is still BETA.
his explanation makes sense.
mtgox is being attacked by the press, ddos, angry bitcoiners, and scammers 24/7 - they are doing their "best"
they are the oldest exchange that has not LOST all the bitcoins or run off or closed down.
give them credit
most of the newer exchanges were written more recently that could explain why their code is different.
also, regular reference clients arent' made for "exchanges" or volume users so custom code needs to be regardless.
bitcoiners, need to calm down, be smart and stop blaming GOX for EVERYTHING =)
Perhaps he did all the due diligence when he was eager to make money, but started to slack off when he has enough. |
|
|
|
In your scenario though the bad news is not BitPay needs to figure out a way to return your coins. You can't undo it and eventually it will confirm (unless a duplicate of the prior output is what confirms). So you are now out the donut and coins.
Oh yes of course, stupid of me, the customer loses out there. But it still always comes back to the same thing for me: wallets should not attempt to spend unconfirmed change. Yes, I know there are some practical difficulties there with the way wallets are designed, but it doesn't look insurmountable - at worst it just causes a few inconveniences. The client could just try to/prompt to respend if after 10 minutes or so if it fails to see the expected change txid, but some outputs summed to the same amount with another txid getting confirmed in a block, and the sum of all outputs doesn't change. |
|
|
|
I am fairly certain that all (or nearly all) clients allow spending unconfirmed change outputs. Until the "mass mutation attack" it improved the user experience to have this option. Without the ability to spend unconfirmed change outputs the user could potentially (depending on what other confirmed outputs are available) need to wait for confirmations between spends. I can't see any wallet intentionally doing that. Many some minor less tested wallet may have accidentally ended up with that behavior.
AFAIK, Armory automatically send change to a new address, so at least it could have an option to disallow spending unconfirmed change outputs, unless there is nothing else spendable, should work in many cases. Also, shouldn't the priority of spending be decided by the coin-age? As the fee rule discourages spending "hot" coins. |
|
|
|
Well, you said the mutated one gets confirmed, can I find the one or not? Thanks.
https://bitcointalk.org/index.php?topic=460944.msg5089865#msg5089865Please actually read the section labeled "Mutable Transaction ids break spending unconfirmed change". To answer your question. No. You can "find it" but a tx created from an unconfirmed change output which is subsequently mutated will never confirm. I corrected my post, how many clients you know share the same behaviour? EDIT: I would suggest you somehow also post your OP in the tech discussion board btw. |
|
|
|
The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)
It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.
this is probably related to the current malleability attack on the bitcoin network (25% of transactions were affected today). it has nothing to do with your theft.
In addition to the above jgarzik is quoted on reddit to have said that one home PC could have done this. One home PC can screw up 25% of transactions! Hold on. Are there actually any reports of something being screwed, apart from couple of exchanges who stopped withdrawals as a precaution measure? It depends on what you mean by "screwed up". The attacker can't change the inputs or outputs or fees, however they can change the tx hash of unconfirmed txs. There were over 16,000 tx "mutated" in the last 24 hours. I am sure they weren't all withdraws from exchanges. It would appear the attackers are simply mutating in mass all transactions they are able to and broadcasting the mutated version into the network. If the mutated version of the tx is the one which gets confirmed it can have consequences for any user. https://bitcointalk.org/index.php?topic=460944.0So, don't deliver until the transaction to you is confirmed, is that....news? Obviously you didn't read the post or link. I said nothing about delivering goods before confirmed. I am not saying you have said anything wrong, I was referring to the panic. And I don't think such consequences can be considered "screwed up", as an end user I would probably not even notice anything other than a slow-up of the network if I don't pay attention. You wouldn't notice a transaction you made (or someone made to you) that never confirms due to no fault of your own. By never, I mean never. Not in an hour, or a day, or a year.  Most people would and they probably would consider that "screwed up". Well, I don't know about you, but when I actually want to see if my tx gets confirmed, I always search for the address and check if there is a new transaction with the correct amount, probably it's just me though... Once again you might want to read the link. I am not talking about it being confirmed under a new tx id. I am talking about it NEVER confirming because it now has become invalid due to the inputs being invalid. Well, you said the mutated one gets confirmed, can I find the one or not? Thanks. EDIT: Okay, I read your OP, I was awfully unaware of the way the reference client works as I have never actually used it, thanks. |
|
|
|
The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)
It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.
this is probably related to the current malleability attack on the bitcoin network (25% of transactions were affected today). it has nothing to do with your theft.
In addition to the above jgarzik is quoted on reddit to have said that one home PC could have done this. One home PC can screw up 25% of transactions! Hold on. Are there actually any reports of something being screwed, apart from couple of exchanges who stopped withdrawals as a precaution measure? It depends on what you mean by "screwed up". The attacker can't change the inputs or outputs or fees, however they can change the tx hash of unconfirmed txs. There were over 16,000 tx "mutated" in the last 24 hours. I am sure they weren't all withdraws from exchanges. It would appear the attackers are simply mutating in mass all transactions they are able to and broadcasting the mutated version into the network. If the mutated version of the tx is the one which gets confirmed it can have consequences for any user. https://bitcointalk.org/index.php?topic=460944.0So, don't deliver until the transaction to you is confirmed, is that....news? Obviously you didn't read the post or link. I said nothing about delivering goods before confirmed. I am not saying you have said anything wrong, I was referring to the panic. And I don't think such consequences can be considered "screwed up", as an end user I would probably not even notice anything other than a slow-up of the network if I don't pay attention. You wouldn't notice a transaction you made (or someone made to you) that never confirms due to no fault of your own. By never, I mean never. Not in an hour, or a day, or a year. Most people would and they probably would consider that "screwed up". Well, I don't know about you, but when I actually want to see if my tx gets confirmed, I always search for the address and check if there is a new transaction with the correct amount, coming from the right address, probably it's just me though... I have no idea how do other clients track the txs, but I would be utterly surprised if there are still that many using Bitcoin-Qt. |
|
|
|
The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)
It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.
this is probably related to the current malleability attack on the bitcoin network (25% of transactions were affected today). it has nothing to do with your theft.
In addition to the above jgarzik is quoted on reddit to have said that one home PC could have done this. One home PC can screw up 25% of transactions! Hold on. Are there actually any reports of something being screwed, apart from couple of exchanges who stopped withdrawals as a precaution measure? It depends on what you mean by "screwed up". The attacker can't change the inputs or outputs or fees, however they can change the tx hash of unconfirmed txs. There were over 16,000 tx "mutated" in the last 24 hours. I am sure they weren't all withdraws from exchanges. It would appear the attackers are simply mutating in mass all transactions they are able to and broadcasting the mutated version into the network. If the mutated version of the tx is the one which gets confirmed it can have consequences for any user. https://bitcointalk.org/index.php?topic=460944.0So, don't deliver until the transaction to you is confirmed, is that....news? Obviously you didn't read the post or link. I said nothing about delivering goods before confirmed. I am not saying you have said anything wrong, I was referring to the panic. And I don't think such consequences can be considered "screwed up", as an end user I would probably not even notice anything other than a slow-up of the network if I don't pay attention. |
|
|
|
There is no way you can verify independently whether these time datas are correct.
Hmmm. Are you referring to the median time that is used ? Or are you getting a different output ? Its from the blockchain so it should be consistent for all of us as long as there is no reorganisation .. isn't it ? This should work for confirmed transactions with a mutated txid as a check, isnt it ? Please help me understand more. Well, on second reading you've pointed out yourself that if you don't check the txid then the time datas can actually be tampered with by the relaying nodes before it's mined, I have nothing new to add. |
|
|
|
The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)
It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.
this is probably related to the current malleability attack on the bitcoin network (25% of transactions were affected today). it has nothing to do with your theft.
In addition to the above jgarzik is quoted on reddit to have said that one home PC could have done this. One home PC can screw up 25% of transactions! Hold on. Are there actually any reports of something being screwed, apart from couple of exchanges who stopped withdrawals as a precaution measure? It depends on what you mean by "screwed up". The attacker can't change the inputs or outputs or fees, however they can change the tx hash of unconfirmed txs. There were over 16,000 tx "mutated" in the last 24 hours. I am sure they weren't all withdraws from exchanges. It would appear the attackers are simply mutating in mass all transactions they are able to and broadcasting the mutated version into the network. If the mutated version of the tx is the one which gets confirmed it can have consequences for any user. https://bitcointalk.org/index.php?topic=460944.0So, don't deliver until the transaction to you is confirmed, is that....news? |
|
|
|
Easier fix would be to track transactions using (add,amt,time) .... no ?
There are no timestamps in bitcoin transactions. Try this in the console :  gettransaction 6baf826a0c5dcd22d28640233cae375cf8a3b37cf7251a93475986e3f42fa823-000 Output : {
"amount" : 0.00016720,
"confirmations" : 16124,
"blockhash" : "000000000000000a0f90a320fd1adea3bfefee716fa98c9f10625021d8d4f29e",
"blockindex" : 655,
"blocktime" : 1383072371,
"txid" : "6baf826a0c5dcd22d28640233cae375cf8a3b37cf7251a93475986e3f42fa823",
"time" : 1383070892,
"timereceived" : 1383070892,
"details" : [
{
"account" : "Default",
"address" : "1rU2kc24GcRUjXLm3MZ8RQtjL1zpcsnK3",
"category" : "receive",
"amount" : 0.00016720
}
]
} What are those "time" and "timereceived" ? Although again its kind of circular where we have to depend on txid :-( .. maybe another way to get those perhaps will do the trick. There is no way you can verify independently whether these time datas are correct. |
|
|
|
Also bit time buyers don't buy on exchanges. And they don't usually make many withdrawals repetitively in a short time.  |
|
|
|
|
Hi, I saw gmaxwell mentioning that the bitcoin-qt's algorithm for finding unspent outputs have a time complexity of O(N^2!), wonder what's the situation with Armory? Just curious, thanks.
|
|
|
|
|
Being Russians, how can these bureaucrats be so ignorant about math?
You can't outlaw the creation and circulation of Bitcoin, unless you outlaw computation with SHA-256 hash functions and possibly, outlaw any logic operation as it's entirely doable to rewrite the hash function to achieve the same output, only taking more steps and longer time.
|
|
|
|
Am I the only one who thinks the Russian gov is possibly serious about what they said? Sochi Olympics is upcoming and they may be genuinely worried that Bitcoin will be used to finance terrorist organizations planning to create some havocs. Most of the terrorist activities in Russia are funded by the Saudi Arabian Royal Family. They don't need Bitcoins to do that. There are better options available. Well, all I said is they maybe genuinely concerned, but they may also be utterly misinformed and are freaking out, like all your good old paranoid autocratic folks. |
|
|
|
|
Is 7-11 big in Mexico? Also I still hope WU can come around and do the right thing.
|
|
|
|
It can bring the required state for a fully validating node down to few measly kilobytes of working state, forever. Provided you have access to one or more archival nodes willing to serve untrusted data, that is.
"Ultimate blockchain compression" is a bit of a misnomer these days. Pieter Wuille aka "sipa" implemented the compression the name was referring to in his "ultraprune" branch of bitcoind, which was merged with the 0.8 release of the reference client, prior to my getting involved with UBC. That release and all releases since maintain a separate structure containing all data necessary for validating future blocks, stored in a database which at the time I am writing this is about 305MB (vs. about 18GB, so about 94% compression). The reference client still keeps the historical block chain data around, because there are not adequate features in place yet to protect the health of the network once a significant number of nodes start pruning old chain state. But that is something both I and others intend to fix in the near future, thereby allowing people to benefit from these space saving features already deployed. Nodes will still need to retain all of this data however, as they would have no way of retrieving it from untrusted peers in a safe manner.
That is the problem that UBC solves: safely querying a peer for data extracted out of the validation structure. If you assume that there will be at least one reachable peer with the information you need and appropriate bandwidth, then it becomes possible to "compress" (sic) the block chain further by offloading this data onto the network, down to a minimal size of 28 bytes - the hash of the current best block, minus the 4 bytes that are always zero. In reality you'd have to have a few (10's of?) kilobytes to store and process the network messages, and much more than that in cached data to be reasonably performant. But you could probably, for example, make a hardware wallet device with only about 512kb of storage, that nevertheless operates as a full node by querying bitcoind over an untrusted USB connection.
Thanks, it's probably the first time I get a clue about this. Still it may make it easier for the law enforcement to close in on the network as people tend to offload the burden of keeping the validation data to others, the decentralization effort requires us to keep the validation structure, which is, I assume, mostly the UTXO set? If 10% of global population adopts Bitcoin, and each of them create something like 50-100 outputs, the set will be dozens of terabytes big, and I guess there is no way to compress it much further? |
|
|
|
|
The redaction of scriptSig could backfire them. If someone comes forward and proves that one output Gox claims to own actually belongs to him, then it's smoking gun they are lying and trying to hide something.
|
|
|
|
Use the search tool, this has been discussed to death already...
Now we are onto this maaku, do you have an estimate about the reduction in size the "ultimate blockchain compression"(is it actually a utxo set compression) can bring about? |
|
|
|
|
Am I the only one who thinks the Russian gov is possibly serious about what they said? Sochi Olympics is upcoming and they may be genuinely worried that Bitcoin will be used to finance terrorist organizations planning to create some havocs.
So after the Olympics is over the pressure may die down a bit.
|
|
|
|
|
Show Posts
