Thanks for the clarification. So, as I understand you, Defcon's statement
"our projections of order finalization volume indicated that we would need the community’s full balance in hot storage."
Really didn't state the error he made quite right.
It had nothing to do with which or what kind of storage he was using.
This leaves open the urgent question:
How does one determine whether one's holdings in cryptocurrency XYZ at exchange FooBar are at risk from transaction malleability?
The next question is:
If those holdings are at risk, how does one then most economically ameliorate that risk?
Topic: Terminology confusion: Escrow vs Shared vs Hot Wallets (Read 616 times)
the issue is not to do with what wallets a business/individual uses.
the issue is not to do with what service a business/individual uses.
the issue is how the business/individual programmed their bot/script which balance checks its customers. this has nothing to do with wallet but more to do with the coding people put inbetween their website and the wallet.
put it this way
if i sent you £20 to a mailbox and you gave me a receipt with a reference number on it. you can change the reference number. but i cannot change anything in the mailbox(bitcoin address).
when i audit the balances i do not check the total of the mailbox(bitcoin address) to calculate the payments made to the mailbox(bitcoin address). i instead look at the receipt reference numbers and find out one of the reference numbers appears invalid.
you then knowing there is money in the mailbox(bitcoin address) come to me and tell me that the mailbox is empty. i check the reference number of the receipt and yep, its invalid. so i give you another payment. this is not a double spend. this is paying you twice because i beleive the first payment failed.
this is nothing to do with bitcoin. this is to do with me/anyone programming a script that does not look at the mailbox(bitcoin address) but instead relies on reference numbers. and then trusts these reference numbers more so then actual mailbox(bitcoin address) holdings.
i now see one positive reason why luke JR drowns on about using new virgin bitcoin addresses per payment, as its easier to balance check the actual address rather then using txid's to work it out. but this all relies on the individuals programming ability's to audit their transactions. and not related to the bitcoin protocol itself.
the issue is not to do with what service a business/individual uses.
the issue is how the business/individual programmed their bot/script which balance checks its customers. this has nothing to do with wallet but more to do with the coding people put inbetween their website and the wallet.
put it this way
if i sent you £20 to a mailbox and you gave me a receipt with a reference number on it. you can change the reference number. but i cannot change anything in the mailbox(bitcoin address).
when i audit the balances i do not check the total of the mailbox(bitcoin address) to calculate the payments made to the mailbox(bitcoin address). i instead look at the receipt reference numbers and find out one of the reference numbers appears invalid.
you then knowing there is money in the mailbox(bitcoin address) come to me and tell me that the mailbox is empty. i check the reference number of the receipt and yep, its invalid. so i give you another payment. this is not a double spend. this is paying you twice because i beleive the first payment failed.
this is nothing to do with bitcoin. this is to do with me/anyone programming a script that does not look at the mailbox(bitcoin address) but instead relies on reference numbers. and then trusts these reference numbers more so then actual mailbox(bitcoin address) holdings.
i now see one positive reason why luke JR drowns on about using new virgin bitcoin addresses per payment, as its easier to balance check the actual address rather then using txid's to work it out. but this all relies on the individuals programming ability's to audit their transactions. and not related to the bitcoin protocol itself.
Most everyone knows by now that the substantive threat from transaction malleability is limited to certain kinds of wallets that are in control of exchanges or other sites that hold assets for registered users. There is some confusion, however, over exactly what to call these wallets, hence there is confusion over how to identify whether a particular asset, held by an exchange, is vulnerable.
I've seen the term "hot storage" used by Defcon, apparently as synonymous with "escrow wallet". I've also seen the term "shared wallet" used.
Are these different? if so, how? Which are vulnerable?
Once we have identified the terminology for vulnerable wallets that are on some exchanges, how do we go about identifying which assets are being held in the vulnerable class of wallets?
Do we then withdraw those assets to private wallets on our own machines for safety (with whatever backup mechanisms are prudent)?
Do we have to get a client for each different type of cryptcurrency that might be in one of these vulnerable wallets?
It is persistence of this kind of confusion that continues to drive BTC prices down.
I've seen the term "hot storage" used by Defcon, apparently as synonymous with "escrow wallet". I've also seen the term "shared wallet" used.
Are these different? if so, how? Which are vulnerable?
Once we have identified the terminology for vulnerable wallets that are on some exchanges, how do we go about identifying which assets are being held in the vulnerable class of wallets?
Do we then withdraw those assets to private wallets on our own machines for safety (with whatever backup mechanisms are prudent)?
Do we have to get a client for each different type of cryptcurrency that might be in one of these vulnerable wallets?
It is persistence of this kind of confusion that continues to drive BTC prices down.
Jump to: