If you aren't the sole controller of your private keys, you don't have any bitcoins.
This can't be said enough. If "your" bitcoins are under someone elses control you have an IOU for bitcoins, not bitcoins. Bitcoins can't be defaulted on, IOUs can. Bitcoins can't be blocked, IOU redemption requests can. This is one reason why BitSimple never holds user bitcoin balances. I feel Bitcoin is more secure when users take control of their own wealth. With instant rate lock there, I need liquidity is no excuse anymore. You can sell Bitcoins directly from your wallet (any wallet) for dollars in seconds. |
|
|
|
Having many unspent outputs in a wallet helps speed up spends, but transactions get bigger, as they contain more inputs. This may accelerate dust generation, if there's a bias in favor of never consolidating inputs. Wallets may have to become smarter about when to divide and when to consolidate inputs. Not necessarily. A compliant wallet should not generate dust outputs. It should use proper coin selection to ensure all outputs (including change) are above the dust threshold. Any spend consolidates outputs. Outside of niche applications it doesn't make any sense to consolidate outputs. If you have a large number of small outputs and need to make a large spend then the tx will be larger. If you conolidate them to avoid that then the consolidation tx will be large. More outputs (within reason) shouldn't significantly increase transaction size. Imagine two hypothetical wallets with 100 BTC in confirmed unspent outputs. Unspent outputs (100 BTC total) ----------------------- "A" 100 BTC vs Unspent outputs (100 BTC total) ----------------------- "A" 1 BTC "B" 3 BTC "C" 3 BTC "D" 6 BTC "E" 7 BTC "F" 20 BTC "G" 25 BTC "H" 35 BTC If I make a withdraw of 0.8 BTC, 6.7 BTC, or 23 BTC either wallet can handle it with a single input. The second wallet would need a second input if I wanted to withdraw 50 BTC but that will not change the transaction size significantly. I would always prefer to have the later wallet as it can handle all four hypothetical transactions without either waiting for change output to confirm or taking a risk and spending it while unconfirmed. For a large exchange "output management" is going to be important. Having all your funds in a single unspent output is going to kill real time transaction processing. |
|
|
|
In fact if a single state out of 50 decides not to regulate that could be enough. Sadly it isn't. BitSimple for example is incorporated in SC however prior legal battles have been fought over the fact that many states statutes indicate that even if your company is NOT in the state (or even in these United States) that if you offer your services to residents of that state you are required to be licensed. One could certainly argue this interferes with interstate commerce but so far the states have won this battle. Are you willing to risk your freedom and net worth on winning that battle? If the state wins, your life is over, if you win the state says "ok" and you are still stuck with the massive legal bill. This is why the current system is so burdensome. It isn't getting regulated in one state, it is getting regulated by 50+ regulators in all the states, each of which may change the laws, regulations, and procedures on any particular day. Keeping track of the forms, procedures, requirements, and current statutes of one state is a challenge, now multiply that by fifty. But it doesn't stop there. The biggest issue is the "unknown". There is a lot of regulatory uncertainty right now. No bitcoin exchange has a money transmitter license in NY, are they breaking the law? On advice of counsel, we have voluntarily chosen to not do business with residents of NY due to the fact that NY could say we are operating an unlicensed money transmission business "in" NY although the company, all its servers, asseets, and employees are hundreds of miles away. However at least NY has spoken out, that provides us some information. Most states are an opaque unknown having not said a single word on the applicability of existing statutes to virtual currency exchangers. Hell the basic definitions of money, currency, and transmission aren't even the same from states to states. Some states don't even define the words. Kinda hard to believe you can have a law about "money transmission" and not define "money" or "transmission". I guess that means the law can be whatever the state wants it to be, whenever they want it to be. Of course you could always fight them in court. A legal team will tell you the costs will run into the six figures pretty quick. So if your company just raised a million dollars you ready to potentially flush a quarter of it down the drain to fight one state in court. Even if you win, what about the other 49? The following hyperbolic example is to illustrate a point which don't necessarily reflect reality and shouldn't be taken as legal advice. NY may says explicitly you need to be licensed, FL has made no such statements but has arrested suspects for running an unlicensed MSB (even after the arrest there have been no statements), the law in PA might not ever apply to virtual currency even if regulators want it to due to the way it is worded, the same thing could be true in MO, but your company is unaware that right now they have an bill being voted on which will change the regulatory scope, CA issues a cease and desist against the Bitcoin foundation a year ago and then there is no followup (were they right or wrong? I guess you can spend another quarter million and sue them to find out), etc, etc, etc, <insert another 40+ etcs here>. Starting to see the issue? The "meta-problem" is regulators often write regulations for large cap companies. Companies which can spend $10M a year on legal and compliance and it amounts to 1% of revenue. In the Senate hearing the regulator even shared a story about a small upstate local town bank which complained they had MORE EMPLOYEES WORKING ON COMPLIANCE than all other employees combined. The shocking thing is although he seemed to share sympathy the regulatory burden hasn't gotten any lighter. So it is almost like the attitude is "wow, that is bad. I have no idea how they can even stay in business. ok lets see what other regulations we can pass today". I mean it is a head asplode disconnect between the needs of small business and the burden being imposed on them. On edit: Reading this now makes me sound like I think the world is over, it isn't. I am optimistic this will eventually be resolved, or the US will simply fall behind other nations where regulation is at least coherent, and compliance is possible for a company with less than a twenty man compliance & legal team. Bitcoin is the honey badger of money, it doesn't care. If the system is broken it will find a way to route around the damaged parts. What I'm concerned about is anyone looking to extend regulation to anything other than exchanges which makes no sense. The good news is AFAIK no regulator anywhere at any level is talking about regulating entities which don't exchange virtual currency for real currency. So far they all seem to see a company accepting Bitcoins is no more a regulated activity than a company accepting credit cards. |
|
|
|
Exchange can still send bitcoin at any time, just don't try to spend unconfirmed change. Anyway, it is always a good idea to pay multiple clients in one transaction
Yeah, but the issue (I would guess?) is that exchanges were paying one client, then using the unconfirmed txid with their unspent output to pay the next client, and so on and so on... if you have a lot of money paying one client (+ change to yourself) and then are waiting one at a time for a block to confirm your last client's tx is a bad idea, because you'll lock up lots of your coins and slow down your withdrawals to a crawl (one client per 10 minutes, ouch!). You also don't want to split your coins into tons of different key pairs because then you're accumulating expensive tx fees. So ideally you should be doing per block settlements (which most exchanges like btc-e already were, I think). The number of keypairs (unqiue addresses) holding the "funds" doesn't affect the size of the transaction. The number of discrete inputs (and outputs). Spending two outputs send to one address isn't any smaller than spending two outputs sent to two addresses. An exchange is going to have one input in their wallet for each deposit. Generally that means the exchange will have hundreds of confirmed outputs. Now depending on the value of the outputs it may take more than one per withdraw but a properly setup exchange (or other service provider which make outbound payments) should be able to process a large number of withdraws using just confirmed outputs. So it isn't one withdrawal per block. It is multiple withdraws each using different confirmed outputs and then next block those new change outputs will become confirmed allowing more new transactions. If a service provider is sending deposits to a cold wallet, and then making a single transaction from the cold wallet to the hot wallet they would end up with less available outputs however there is no requirement to make the funding transaction from cold wallet to hot wallet be a single output. As an example instead of sending 1x500 BTC to the hotwallet send 10x50 BTC and once that confirms you can process 10 not 1 withdrawals (of up to 50 BTC each). Outputs are relatively small so you can get ~4 outputs per KB making the cost per discrete output about $0.02 right now. That is simply the cost of doing business. A smart exchange will monitor the number and value of their unspent outputs and take action to ensure it isn't exhausted. For example if a large rush of withdraws reduces the number of confirmed outputs, start creating transactions which produce an extra change output (payment + change + change). If this sounds hard and complicated ... that is why the exchange is getting paid. They are providing a service to abstract all this from the user so it just "works". Start to expect more from your exchange, not give them excuses on why they can't do it.  |
|
|
|
|
By "platform" do you mean a website where you don't have direct control over the private keys (examples would be exchange account, mining pool, etc).
If so understand you can't actually "send" bitcoins all you can do is make a request through the website.
If you made a request and the transaction id doesn't show up in blockchain.info, blockexplorer, or your local wallet it is very likely that either
a) the service has NOT sent your coins
or
b) the service has had an error which produced an invalid transaction that wasn't relayed to peers on the network.
Either way the place to start if the website/service where you made the request and ask them why they haven't sent your coins.
It may take a while for transactions to confirm but valid transactions created by competent service providers should propagate across the network within a matter of seconds.
Simple version:
If a website (any website) reports "we sent your coins" and it has been 60 seconds and your wallet, blockchain.info and blockexplorer all don't show it, then they haven't sent them (or haven't sent them properly). Don't accept excuses that it "might take a while", that is nonsense. Confirmations "take a while" unconfirmed transactions should be relayed to all nodes on the network within seconds.
|
|
|
|
Do you have any idea how many scams have been attempted on this website and they all follow the same M.O.
First a posting by someone who has no reputation on this website and then multiple follow ups about how great the service is from many more new members who all claim the same.
999 times out of 1000 its a scam.
If it looks like a duck, walks like a duck, quacks like a duck.......
So why not trade with someone who is already trusted instead? BitSimple - https://BitSimple.com |
|
|
|
|
jl2012 got it.
The patched reference client will include a command to set the min # of confirmations before change is unlocked (spendable). For those running a client which support coin control you can temporarily work around the issue by selecting only confirmed outputs.
It also is likely a good idea to keep more confirmed outputs (the # of discrete outputs not necessarily the number of BTC) in the hot wallet. This will reduce the chance of "confirmed output exhaustion" where a wallet can't make payments because all the change outputs are waiting confirmations.
Lastly any competence business should be paying the min mandatory fee even for high priority transactions. Paying sufficient fees becomes even more important now. If a tx is delayed a few blocks, then the change also becomes unspendable for a few blocks.
Obviously the long term fix is to have immutable transaction ids but that is a long term fix. The patches being considered right now will at least make the clients are "little smarter" in dealing with the reality of an attacker actively spamming duplicates into the network.
|
|
|
|
How come all the major exchanges had experienced the same problem, even though the problem was already known. Did they use the same code? Or did they all ignore the problem tough it would go away?
They didn't have the same problem. MtGox = lets naively keep paying the same customer over and over and over on withdraws so he can steal coins. Oh crap we just lost a small fortune so lets shutdown and blame Bitcoin. A few other exchange = the DDOS and the way the reference client handles unconfirmed change outputs is caused us to generate broken withdraws so lets suspend withdraws until the patch to not spend unconfirmed change outputs is released. Some other exchanges ( including https://bitsimple.com ) = Yup we are still open. Right this second. Starting to see the difference? |
|
|
|
The malleability attack becomes a DOS attack. We need a quick fix. Before there is a better solution, the bitcoind should not report unconfirmed transactions. Account balance should be solely based on confirmed transactions. Before malleability is fixed (if ever), unconfirmed outputs should not be spent.
How does it become a DoS attack? Care to explain? The clients track unspent outputs before forwarding tx (or mining it). How does malleability cause a problem? I don't see any issue (non-gox) unless I missed something. Why the quick fix? It does not seem urgent. Lets do it properly and thoughtfully. Most current wallets will attempt to spend unconfirmed change outputs. If the tx id is mutated and the mutated versions ends up in a block then the spent change output becomes permanently invalid. For a site like an exchange with a large amount of withdraws (spends) it is very likely they will spend using unconfirmed change outputs and thus end up with broken outgoing payments. More info: https://bitcointalk.org/index.php?topic=460944.0The "quick fix" is to have clients deal with the possibility of tx being mutated before confirmation in a more consistent and expected way. The improvement to immutable tx ids is a long complex process which will require extensive testing. It won't be quick. |
|
|
|
Actually blockchain is affected, the data on it is not trustable. Nonsense. Either you are intentionally spreading misinformation or are just don't understand the issue. Nothing about this affects the blockchain. Please point to a single confirmed transaction which is "not trustable". |
|
|
|
|
Possible Global Shutdown? I don't think so.
BitSimple is open, and not affected.
I guess the media has a hard time with the concept of a peer to peer network.
|
|
|
|
But having said that wouldn't it be good enough to check for a particular transaction , at least from the our own side ? I see it gives me the timestamps even after removing "Default" label.
I figure this should be good enough to track it .. aint it so ? Or am i sleep talking again ?
You should not rely on timestamps at all. You have a tx A, it has a timestamp of 12:00:00. Your broadcast it out. I mutate the tx so it has a hash of B, I broadcast it out with a timestamp of 01:01:01. Your node would see this as a different transactions. If you are using this to track payments and I reported I didn't get paid you would find no transaction time a timestamp of 12:00:00 in a block. Timestamps should never be trusted in Bitcoin for any reason. They are only used by the protocol to adjust difficulty and that is because there is no way to do it without recording time. Other nodes can feed you false timestamp data trivially. Even if tx id were immutable timestamps should still never be trusted. |
|
|
|
[…]
To clarify further: in an transaction, only the inputs, the outputs and the amount are signed. The TXID is -not- signed, and thus can be changed by anybody while keeping the transaction valid. It is -not- a bug, it's a design choice. The Bitcoin protocol never stated that the TXID was to be unchangeable, and thus nobody should have expected that in their software.
One can uniquely track transactions otherwise. Even if the TXID is changes, the inputs are not. Thus one can know if a transaction went trough by checking if a given input has been spent according to the blockchain.
Why not sign the entire transaction including the TXID? Sign it with which private key? A tx can (and usually does) have multiple inputs. |
|
|
|
|
BitSimple is not affected. We are accepting trades right now. We aren't crazy enough to sell Bitcoins for PayPal but we will buy your Bitcoins for a paypal payment (or ACH or Bank Wire). We also never hold user's bitcoins so if we did need to suspend wallet operations your coins wouldn't be frozen.
|
|
|
|
|
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.
|
|
|
|
The original post is well written. There's another problem with the fix, though. If you can't spend unconfirmed change arising from confirmed inputs, once you've spent some money, you sometimes can't spend again until a few confirmations have been processed. There's now an option in the official QT client to enforce that rule.
This creates operational problems for Bitcoin use. Once you've spent some Bitcoins, you may not be able to spend any more Bitcoins for tens of minutes. Whether or not you can spend depends on the denominations of Bitcoins currently in your wallet. You don't have an "account balance", you have a collection of Bitcoin items with varying denominations, and this now matters. Explaining this to end users is going to be a problem, especially since the current user interface doesn't expose that level of detail to the user. With the "no spending unconfirmed change" rule enforced, it's going to look like this, I think:
User has 1 BTC, 0 unconfirmed, 1.0 available for spending. The 1 BTC is from a single transaction.
User spends 0.5 BTC.
User now has 0.5 BTC, 0.5 unconfirmed, 0 available for spending.
Half an hour later....
User now has 0.5 BTC, 0 unconfirmed, 0.5 available for spending.
This is not going to play well at the mall.
For a big operation with a lot of outgoing transactions, like an exchange, wallet systems may have to have something like active currency management. (This is the "we have too many twenties, and not enough fives right now" problem a retailer sometimes faces).
Anybody thinking about this?
That assumes the user only has a single unspent output available to spend. If a user had multiple unspent outputs they could make multiple txs each involving one or more of them while the new unconfirmed change confirms. My current wallet has 118 unspent outputs so I wouldn't be affected as much by the more conservative version than someone who literally has received Bitcoins once ever. The patch isn't ideal but it is better than a situation where txs "unexplainably" simply never confirm. The long term goal should be immutable transaction ids however this is a significant challenge and it is going to take a long time. The "fix" proposed would be temporary because doing nothing until the long term goal is reached is not viable. Make no mistake, it isn't ideal, but it is better than what we have right now. I also suggested that it be optional so if users want to risk broken transactions they can spend unconfirmed change outputs. Another optional change would be to have the client create two or more change outputs when the number of discrete unspent outputs (we are talking unique outputs not necessarily value) is "low". This would give the coin selection algorithm more options and (once confirmed) allowed the user to make multiple back to back transactions before needing to wait for a confirmation. You can manually do this yourself (i.e. in your 1 BTC example the user could right now send 0.1 BTC to 10 different addresses in his wallet). |
|
|
|
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. |
|
|
|
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. |
|
|
|
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". |
|
|
|
|
Show Posts
