Here in Vancouver, several brick-and-mortar businesses accept zero-confirm transactions using BitPay. If you are buying a coffee, no one is going to wait 10 minutes (or longer) for confirmation; it is critical that zero-confirm transactions are reasonably secure in order for this business model to work.
So let me see if I understand the transaction malleability problem in relation to brick-and-mortar stores:
I pay for my coffee at Waves for 4mBTC. Assume that to avoid "address reuse," my phone uses the full balance in 1AddressA, sends 4mBTC to Waves, and the rest to a new change address 1AddressB. BitPay accepts this transaction and I get my coffee. As soon as I finish paying, I realize that I also wanted a donut. So I pay for this using what are now unconfirmed coins sitting in 1AddressB. BitPay still approves the transaction and I get my donut too.
But my first transaction was mutated, and the mutated version was accepted into the blockchain. This means that the transaction I used to pay for my donut is now invalid, and Waves/BitPay won't get the money (and I've already left the store).
This seems like a messy problem to deal with. If we disallow spending unconfirmed change outputs, then there will be certain cases when I can't actually purchase my donut [without a long wait], correct? Ideally, my wallet would try to break up my coins so that there are always plenty of fully-confirmed outputs ready for spending. But how do most wallets actually work? The Blockchain.info mobile wallet [that I use] sends the change back to the same address, so I'd expect that it would be very rare to have exhausted all of the confirmed outputs. But for mobile wallets that avoid address reuse [do these even exist?], would it be less likely that you'd have confirmed coins available?
And should BitPay do anything to protect itself?
Very good example to think about, but: did I miss something? I think it won't happen, or at least doesn't have to. When you try to pay for the donut, assuming your wallet makes use of the change utxo which has been malled and is not yet confirmed, will bitpay accept it? I don't know whether they would today, but isn't it trivial to just check each utxo used as input and look at the blockchain to see if that transaction has any confirms? That way, they can accept unconfirmed spends, but not accept unconfirmed spends of unconfirmed spends, which is practically absolutely fine. Except you don't get your donut  Unless your wallet is coded to not use unconfirmed change... Today BitPay would accept it. Unconfirmed change is used rather routinely although probably will be changing soon. 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. Of course the shop will have no clue how to get your coins back, and "you" (or a less educated user) might be kinda upset seeing the donut funds deducted from your wallet but not getting the donut and the clueless clerk having no idea how to get your coins back or even where they went. If this happened enough the store might just not accept Bitcoin in the future. Now I am not going all doom and gloom and none of this is unsolvable but you can see how all this starts to get really ugly real quick. Transaction Ids need to be immutable. Period. There is no other viable long term option. However that is going to take some time so things might get a little clunky for service providers before they get better. |
|
|
|
It isn't the equivalent because mailing pennies isn't going to break anyone's mailbox, but this did break some wallets. If it broke anyone's wallet then that wallet it so horribly defective that they are in the running for beating MtGox when it comes to worst wallet implementation ever. You should run for the exit now, because if a wallet can't properly handle an unconfirmed transaction who knows what else they got wrong. I mean someone sent you money. A wallet that can't handle that is a joke. If your bitcoin wallet breaks when someone sends you bitcoins that is generally speaking a bad sign. |
|
|
|
|
Yup from a straight reading of the complaint those saying "entrapment" obviously have a definition of "if the cop doesn't tell you he is an undercover cop and in any way tricks you" = entrapment. In the real world it doesn't come within a mile of entrapment. For those thinking it rises to an entrapment defense .... cops can lie to you. If this is the first time that truth has crashed into your reality well it is good to learn it before you are in a court room.
However the flip side is the money laundering charge doesn't even seem to hold water. I am not saying it is a weak case, I am saying the the the basic material fact of the charge aren't represented. I mean the prosecutor has better chance of indicting for the murder of a person who isn't dead. Unless there is more than what is in the complaint, I can't see it even surviving the first motion from the defense. Honestly I don't think the prosecutor could get the grand jury to indict, even if they were half asleep, so that is a plus for the defense.
If the ML charges go away it gets a lot more interesting. Is the state of FL going to go ahead with the unlicensed money transmitter charge on an otherwise legit exchange? If so then the hyperbolic title of the thread is 100% spot on. So honestly I really do hope the ML charges get dismissed because then it just comes down to a black and white case on if two citizens of Florida can exchange dollars for Bitcoins.
|
|
|
|
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.
Just head of your service, do you do International Wire transfer to Europe? BitSimple is available to US residents only at this time but we will be adding international support shortly. |
|
|
|
This indeed old news but if these guys were stupid enough to complete bitcoin sales after being told there were going to be used for illegal purposes, then maybe they need to go to jail.
~BCX~
It shouldn't be the sellers responsibility what the buyer is going to do with the money, this is blatant entrapment and should be an outrage to everyone on this board. entrapment doesn't mean what you think it means. By that logic any undercover drug deal, prostitution sting, or cop pretending to be a child online to catch a pedo would be entrapment. |
|
|
|
|
Well it isn't just that franky. To use your train analogy some mining pools simply use larger trains. Ironically it is the Eligus pool which uses some of the largest trains possible while many other pools uses trains with only half as many cars. Some miners simply run with just a locomotive and no cars (no transactions beyond the coinbase reward to the miner).
|
|
|
|
Somebody somewhere wants to license bits ...
Wil-E coyote moment as they look down and realise just how far out over the cliff they have gone?
The widepsread monetary insanity and confusion has no limits it seems.
The real insanity is people in our own industry emphatically saying "I want regulation" and when pressed for an answer why they reply "because it's coming anyway" The bureaucracy is expanding to meet the expanding needs of the bureaucracy. |
|
|
|
|
Only MtGox apparently double paid scammers.
Other exchanges shut down for a related but different reason. Someone on the network has been duplicating all transactions, not just theirs to get double payment. This wreaks havoc on the withdraw system of SOME exchanges due to it breaking the change output and causing subsequent transactions to fail. A few failures can be manually resolved but it was occuring is such high volume to essentially be a DDOS. The fix for that is a patched version of clients which doesn't spend unconfirmed change.
Of course some exchanges/brokers never shut down not even for a minute because their backends would sophisticated enough to handle the duplicates without issue.
So it is important to not lump all service providers together in the same category.
|
|
|
|
|
It doesn't exist on the network. Your "great trusted platform admin" is incompetent or crooked. You haven't been paid.
|
|
|
|
if you're into bitcoin for the long term, we could sign a contract where you'd get the bitcoins after 180 days from payment (longest paypal chargeback period I know of) when it's quite safe to release bitcoins for paypal payment. if the payment is charged back in the mean time, contract is void. it's that easy. i would even move the coins for you so they have a footprint in the blockchain just would not let you have the private key sooner. sorry but paypal is really bad money to buy bitcoins with.
if you search the forum you might find sellers releasing coins immediately but they are rare and usually won't deal with users without a background check (ebay id with feedback, verified paypal account, web of trust rating, successful trades with forum members in the past).
if paypal is your only option, then the 14% fee via virwox might be the way to go (and be happy to buy bitcoin with pp at all)
You would still get scammed. Buy $x worth of Bitcoins using PayPal. If the exchange rate goes up don't dispute. If the exchange rate goes down file a dispute. Guaranteed profit for the scammer, either he gets $x back or he gets >$x worth of BTC. |
|
|
|
I understand it can't be with BTC where there isn't a regulator, but we shall not fear, nor be surprised if at times, there are things we do not understand, or that things are causing reactions we hadn't expected, so much that the safest thing to do may be to stop everyhting. I called Satoshi. He turned the master bitcoin key to off so blockchain should be stopping shortly. Thanks for the heads up that was a close one.  |
|
|
|
According to the last 10 news posts at blockchain.info, there is a lot more to it than a penny in someones mailbox.. it seems to be a little more complicated than that
You are saying that you believe that send you a satoshi is the same thing as the ongoing DDOS attack? There is a real attack going on which has absolutely nothing with this thread. |
|
|
|
So it turns out my concerns were semi-legit? No, however you deserve credit for riling up the clueless. Bitcoin addresses are public knowledge much like postal addresses. Say one day I felt stupid and decided I wanted to mail 1 US penny to 10,000 random postal addresses. Do you know what could happen? You might open your mailbox one day and .... HOLY CRAP there would be a penny in there. How could this happen? You didn't ask for a penny and it was mailed from some anonymous mailbox? What the hell is going on? Has the security of the postal mail system been broken? Is someone tracking you? What if this is part of some 51% postal attack? I heard they are "dusting" your finances with this penny so when you deposit it then they can hack your bank account from the inside out. OH NOES! CALL HOMELAND SECURITY! We need to stop this. Someone should put penny detectors on all mail drops to ensure hackers aren't able to destroy the world economy by mailing pennies. We need to act now. The entire postal system as we know it could collapse within days if people can just mail things to other people and stuff. This is the digital equivalent of that, and the reaction is just as silly. |
|
|
|
|
Yes. It has on more than one adjustment in the past.
Is it likely that it will go down anytime soon? No.
|
|
|
|
Are they? I'm not sure if the company is, but the CEO himself holds a lot.
I hadn't seen any news about this. If this is the case though, I'd be very intrigued to see how this is reported in their financials. And I wonder what BTC sales and holding BTC would fall under in their EBITDA. Um  it is in the article that this thread is about. Overstock’s recent decision to keep some bitcoin on its balance sheets could also find the company playing the role of newsmaker once again. Byrne suggested that should Overstock be holding bitcoins at the time of its upcoming first-quarter fiscal reporting, it will likely be required to report this action to the tax authorities.
“That’s an issue that the sec and the accounting wizards have not opined yet, so we could be the test case.”
Byrne indicated that he has already been contacted by several outside accounting firms that have voiced an interest in being part of this process. The agencies, he said, are interested in participating because it could set a precedent for how publicly traded bitcoin merchants will need to disclose such holdings. |
|
|
|
Or was this error in the Gox payment system exclusively exploited by criminals? This. At the time there was no mass mutation of transactions. The attackers were mutating their own transactions something like this: 1 ) Attacker request withdraw. 2 ) MtGox generates tx id A (likely defective in a host of ways making the rest of the attack easier). 3 ) Attacker grabs a copy of the "busted tx" and cleans it up (mutates it). Call this tx id "B". 4 ) Attacker pushes mutated version (tx id "B") to a miner. 5 ) Tx id "B" is included in a block. Attacker has been paid. 6 ) Attacker contact MtGox stating they had not received withdraw (this is made more believable because MtGox broken wallet had created tens of thousands of legit broken transactions). 7 ) MtGox checks blockchain and tx id "A" does not exist. 8 ) MtGox pays the attacker again. So distilled down the only way you got double paid was if you did all of the following: a) you noticed MtGox was generating broken transactions b) you used their API to pull a copy of the tx (because it was being dropped by relay nodes) c) you modified the transaction to clean it up d) you received payment and then contacted MtGox claiming you didn't. It didn't happen by accident. Even if someone legitimately cleaned up (mutated) their transaction because MtGox was generating broken garbage, they still wouldn't get paid again unless they then lied to MtGox and told them the transaction never went through so MtGox would cut another payment. There is no way of knowing how many times attackers did this, or even how many people working together or independently tricked MtGox into overpaying them. The withdraw issues (legitimate complaints about unconfirmed payments due to MtGox broken wallet) have been going on a month. Did the attackers realize on day 1 or only a few days ago? Only MtGox knows. |
|
|
|
bitcoind gives you a txid when you send coins. bitcoind has "gettransaction <txid>" to look up transactions. This being broken means that it is all there as a trap to cause you grief. And as a great tool for social engineering to steal your coins. What you are basically saying is that you want bitcoind to contain broken tools so that people will have problems and lose lots of money, and then you can later laugh at them and call them stupid. I don't think that's a good future for bitcoin. Nobody competent and knowledgeable is saying mutable transaction ids are a good thing. The trolling and clueless might but who cares. The long term goal is immutable transaction ids but there are a lot of technical challenges. It isn't going to be done overnight. In the short term the way clients handle/report duplicate transactions will be improved, however the reality is that tx ids are mutable for the immediate future. So (and I say this tongue in cheek I have used your pool for years) you can either learn to handle mutable tx ids or you can shutdown for 6-12 months and at that point you likely will be able to rely on unconfirmed tx ids being immutable (but even then could be changed by the sender). To make unconfirmed tx ids immutable will require a core change to the protocol. There is still disagreement on what is the best way to achieve that goal. Then extensive testing that will need to be done. Miners will probably have to show support, clients will have to be soft upgraded, and a deadline put in place. Just like adding P2SH support, in a distributed decentralized consensus system there is no fast and easy way to make a breaking change. So if you want to run a Bitcoin related business in 2014, mutable transaction ids are simply a reality, like the possibility of a double spend, or a 51% attack, or a DDOS attack, or a hacker breaching your hot wallet. It is just another reality that makes all this a challenge. I am pretty sure you understand this but for anyone else, the blockchain is the canonical reference of transactions. Unconfirmed transactions are not guaranteed to be accepted by all nodes. The transaction ids of unconfirmed transaction being mutable are just a manifestation of that reality. |
|
|
|
|
Any plans to add an option so that unconfirmed change is not spent? There are pulls in github to add similar functionality to the QT client. The fact that Armory favors spent over unspent means it is less of an issue unless the wallet has no/few confirmed outputs. Do you agree users should have the option of disabling this potentially undesirable behavior?
|
|
|
|
|
I didn't know they are holding some of their acquired Bitcoins. That is even bigger news. Any gain (i.e. difference between value of BTC at time of sale and time of report) is reported separately. Since they are a publicly traded company they will have to report it. That would be a first. If it becomes large enough it might even become its own line item in the quarterly and annual reports.
|
|
|
|
Sorry guys, I haven't been seeing notifications on these threads, and I've been on travel so I hadn't noticed it..
Armory does not have any problems with transaction malleability.
There are no security issues with this. Armory does not rely on transaction IDs for anything except transaction comments. If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.
The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction. Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added. I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions. It would also solve it for mutated transactions.
When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done. When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed. It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.
That means it is immune to one of the two problems facing most clients listed here. A well earned kudo on that. https://bitcointalk.org/index.php?topic=460944.0However what about the issue of breaking transactions which rely on unconfirmed change output. Does Armory not spend unconfirmed change outputs? Does it provide an option to require a certain number of confirmations before change outputs are unlocked for spending? |
|
|
|
|
Show Posts
