However, he cannot obtain the private key by hacking torwallet.net. He can only obtain it by hacking the onion site itself. That socat tool is pretty damn cool; I've added it to my arsenal.
Most .onion sites don't bother having SSL enabled because Tor provides encryption... but for external access, this is a perfect example of how to use it.
The hacker don't need the wallet private key to withdraw BTC. Only the secret codes are needed That's correct, however URL query strings are encrypted when using SSL, so they can't be sniffed. If someone tried to MITM after compromising Torwallet.net, the SSL certificate would have a different fingerprint and it would be detected as an error, since you have created a special exemption in your browser for that specific fingerprint. One the torwallet.net page it claims "Seizing or hacking this server will have no effect on TORwallet's services and gain you no bitcoins, only our wrath", but this is wrong. If the torwallet.net server is hacked, the private key of the SSL certificate is exposed, and the hacker will know the URL query strings That is not correct. Torwallet.net does not contain any private keys, and it is a separate server from the .onion site. They are not hosted on the same server. Not sure what's so hard to understand about that. I mean private key of the SSL certificate, not private key of BTC accounts. Not sure what's so hard to understand about that...... I know you meant that, and you are incorrect. The private key of the SSL certificate is stored on the .onion site, not on the torwallet.net server. Perhaps you should look closer at how socat works: it has the option to serve up its own certificate, but that is not in use here. It is simply concatenating data between ports 443 and 9050, in both directions. I mean the private key of the SSL certificate of torwallet.net, not the SSL certificate of the .onion site ...... |
|
|
|
However, he cannot obtain the private key by hacking torwallet.net. He can only obtain it by hacking the onion site itself. That socat tool is pretty damn cool; I've added it to my arsenal.
Most .onion sites don't bother having SSL enabled because Tor provides encryption... but for external access, this is a perfect example of how to use it.
The hacker don't need the wallet private key to withdraw BTC. Only the secret codes are needed That's correct, however URL query strings are encrypted when using SSL, so they can't be sniffed. If someone tried to MITM after compromising Torwallet.net, the SSL certificate would have a different fingerprint and it would be detected as an error, since you have created a special exemption in your browser for that specific fingerprint. One the torwallet.net page it claims "Seizing or hacking this server will have no effect on TORwallet's services and gain you no bitcoins, only our wrath", but this is wrong. If the torwallet.net server is hacked, the private key of the SSL certificate is exposed, and the hacker will know the URL query strings That is not correct. Torwallet.net does not contain any private keys, and it is a separate server from the .onion site. They are not hosted on the same server. Not sure what's so hard to understand about that. I mean private key of the SSL certificate, not private key of BTC accounts. Not sure what's so hard to understand about that...... |
|
|
|
However, he cannot obtain the private key by hacking torwallet.net. He can only obtain it by hacking the onion site itself. That socat tool is pretty damn cool; I've added it to my arsenal.
Most .onion sites don't bother having SSL enabled because Tor provides encryption... but for external access, this is a perfect example of how to use it.
The hacker don't need the wallet private key to withdraw BTC. Only the secret codes are needed That's correct, however URL query strings are encrypted when using SSL, so they can't be sniffed. If someone tried to MITM after compromising Torwallet.net, the SSL certificate would have a different fingerprint and it would be detected as an error, since you have created a special exemption in your browser for that specific fingerprint. One the torwallet.net page it claims "Seizing or hacking this server will have no effect on TORwallet's services and gain you no bitcoins, only our wrath", but this is wrong. If the torwallet.net server is hacked, the private key of the SSL certificate is exposed, and the hacker will know the URL query strings |
|
|
|
Although you do not have a wallet on torwallet.net, hacking of torwallet.net will expose the secret code, and thus the balance of the accounts of those who use torwallet.net. It is impossible for google or anyone else to find the link to a TORwallet unless it has been posted somewhere. Those instawallet links were most likely indexed by google visiting instawallet.org and being redirected to a new wallet.
We are working on adding an optional password field to the site. We are waiting for our developer to get back from vacation.
Hacking of torwallet.net will expose absolutely nothing. https://torwallet.net is nothing more than a proxy, and actually has more in common with a port forward in your router. It doesn't even understand http and does nothing more than pipe data through tor. In fact, here is the command we use. socat openssl-listen:443,fork,reuseaddr,su=nobody socks4a:127.0.0.1:nci2szjrwjqw2zbi.onion:80,socksport=9050 Hacking of nci2szjrwjqw2zbi.onion would reveal current balances, however the attack surface is limited to a single port. Just for example, I have the following wallet: https://www.torwallet.net/w/c85f0c2c5347caf6b302cebabed0e93c3ce023d6739b1e502128cbaa7042eddbTherefore, anyone who knows the code "c85f0c2c53.............." can redeem all coins in my wallet. A hacker can obtain the private key of torwallet.net's certificate, and he will learn the code "c85f0c2c53.............." However, he cannot obtain the private key by hacking torwallet.net. He can only obtain it by hacking the onion site itself. That socat tool is pretty damn cool; I've added it to my arsenal. Most .onion sites don't bother having SSL enabled because Tor provides encryption... but for external access, this is a perfect example of how to use it. The hacker don't need the wallet private key to withdraw BTC. Only the secret codes are needed |
|
|
|
Although you do not have a wallet on torwallet.net, hacking of torwallet.net will expose the secret code, and thus the balance of the accounts of those who use torwallet.net. It is impossible for google or anyone else to find the link to a TORwallet unless it has been posted somewhere. Those instawallet links were most likely indexed by google visiting instawallet.org and being redirected to a new wallet.
We are working on adding an optional password field to the site. We are waiting for our developer to get back from vacation.
Hacking of torwallet.net will expose absolutely nothing. https://torwallet.net is nothing more than a proxy, and actually has more in common with a port forward in your router. It doesn't even understand http and does nothing more than pipe data through tor. In fact, here is the command we use. socat openssl-listen:443,fork,reuseaddr,su=nobody socks4a:127.0.0.1:nci2szjrwjqw2zbi.onion:80,socksport=9050 Hacking of nci2szjrwjqw2zbi.onion would reveal current balances, however the attack surface is limited to a single port. Just for example, I have the following wallet: https://www.torwallet.net/w/c85f0c2c5347caf6b302cebabed0e93c3ce023d6739b1e502128cbaa7042eddbTherefore, anyone who knows the code "c85f0c2c53.............." can redeem all coins in my wallet. A hacker can obtain the private key of torwallet.net's certificate, and he will learn the code "c85f0c2c53.............." |
|
|
|
What's the incentive to "kill a coin" compared to "making loads of coin" by simply mining?
What's the incentive to vandalize a strangers car? There is none, yet people still do it. What's the cost to vandalize a car? The main worry is that a government may see Bitcoin as a threat (think of SR, WikiLeaks) and launch a 51% attack to destroy it.
How exactly would the destruction work? Do you have a link to a good description or can describe it yourself? A person with 51% hashing power can refuse any new transaction or charge ridiculous transaction fee, so basically no one can spend or receive coins. |
|
|
|
|
Is it possible to use Lancelot for something else, such as Litecoin mining, protein folding, or looking for large prime numbers?
|
|
|
|
It is you do not know what a 51% attack is. 51% attack can kill a coin. Search "Coiledcoin" Do people even know what a 51% attack is, what it takes to do, and that it is much less profitable than mining with that sort of power ?
Some people heard that a 51% attack is possible, so they assume it's a bad thing and anyone with the resources would want to do it.
With 51% attack you can only invalidate a transaction that you made so it returns to your wallet, you cannot make money out of thin air with it.
This would mean you have to have a huge amount of money in your wallet to begin with, $1mil for example, then send it to someone, have them dispatch the goods worth that amount withing an hour, then reverse the transaction using your 51% hashing power and hope they don't contact the courier to stop the goods being shipped on.
So you see it's not very practical.
Also 99.9999% of people who mine wouldn't have a clue how to modify a block and launch a 51% attack as most miners are business investors and not hackers.
|
|
|
|
Although you do not have a wallet on torwallet.net, hacking of torwallet.net will expose the secret code, and thus the balance of the accounts of those who use torwallet.net. It is impossible for google or anyone else to find the link to a TORwallet unless it has been posted somewhere. Those instawallet links were most likely indexed by google visiting instawallet.org and being redirected to a new wallet.
We are working on adding an optional password field to the site. We are waiting for our developer to get back from vacation.
|
|
|
|
|
I have a proposal as an "add-on" to this
When a miner sees a tx, he could either 1. grab the tx fee, or 2. "donate" the tx fee to the alt-chain.
Grabbing the tx free is essentially the current practice
If it is "donated", it will go to a jackpot pool for the alt-chain. A miner who find a valid block in the alt-chain will claim the jackpot.
By donating the tx fee, miner will get a "discount" in their mining difficulty. The discount will be calculated in a pay-per-share manner. For example, the current difficulty is 1583 177.847444 with block reward of 50BTC. A fair PPS would be 0.00003158. Therefore, a tx fee of 0.0005 is equivalent to 15.831778 shares. By donating the tx fee, the miner will only need to find a block with difficulty of 1583177.847444-15.831778 = 1583162.015666.
Miner will want to donate tx fee since this helps them to find a block easier and reduce variation. It also provide a feedback mechanism for mining. In a bad luck turn where many tx accumulate, difficulty is reduced and the bad luck turn could be ended earlier.
The effective difficulty is no longer a constant throughout 2016 blocks. Instead, it will be a zig-zag function: highest at the beginning of a round, keep decreasing as unconfirmed tx accumulate, and jump back to the highest value when a block is found. The average block generation rate is still 10-minutes but the variation is reduced too.
Some miners may abuse this system by creating tx with high tx fee (e.g. 25BTC) and donating it to the alt-chain, so their difficulty is reduced by 50%. To prevent this, we may put a cap on the difficulty discount (e.g. 10% of difficulty) and/or calculate the discount with <100% PPS (So the expected return will be decreased).
|
|
|
|
Unless the tx fee is so high which could compensate the orphans, miner will start to reject tx like what Eligius doing. Eligius is simply putting the burden on other miners and increase their orphan rate.
Although I agree SD is abusing the network, a successful BTC network should be able to handle 1000x of current volume. If SD is a stress test, the network is failed. It means the network cannot grow further.
Without changing the current infrastructure, there are 3 options: 1. Miners will allow only a limited number of tx in a block, but this may leave some tx never confirmed and BTC is dead; 2. Increase the tx fee by 10x or even 100x; 3. A revised tx fee formula to punish people using coins with <3 confirmation.
All these solutions, however, would be short-term. If more people use BTC (which most of us want to see), the same problem will emerge again. If this could not be solved, this will be a major bottleneck of the whole system.
Actually, the TX fee used to be much higher (0.01 per KB vs 0.0005). It was reduced to 1/200th it's original size after last summer's bubble. At this point, txfees are almost meaningless because of that decision. To process credit cards, you're looking at percentage fees, in addition to $0.05 to $0.30 per transaction, depending on volume and your system's ability to run the transactions in batches and the volume of transactions you process daily. Right now, the txfees are pointless. They don't even amount to a penny per TX in most cases. That's why I actually agree with what Luke has done. It is not SD's fault, they are following the rules that were changed because the developers were being pressured by the community last summer when TX fees were "becoming too big" because the price was $20-30 for a few weeks. However, even at the peak value and 0.01 per KB, they were almost always cheaper than what would be charged by any credit card/payment processor. If the fees were still 0.01, this wouldn't be a problem. The fees would be adding enough to each block to make up for the higher risk of orphans. Of course, it would also probably kill SatoshiDice because the fees would be a much larger portion of the bets. Not that Bitcoin should be kept in this state for SatoshiDice. I don't ever recall Bitcoin being marketed as a micropayment system. And even if fees were bumped back up to 0.01, this doesn't mean everybody is suddenly paying high fees. The network is designed to give priority to large transfers of highly confirmed coins. The only people that would feel the change are those sending coins just after receiving them, or sending extremely small amounts of coins [or paying with a "bag of pennies" in change]. It's only 1/20th, not 1/200th Transparency of the BTC tx fee system is actually quite low. Although the client will provide a "standard" rate, you will never know if it will be accepted or not. I think the major pools should publish their fee schedule/rules. Fee should be decided by the market, not the devs. BTC may not be marketed as a micropayment system, but it has a good potential to be one. Tx fee of 0.01BTC may work a this moment. Pushing the tx fee to 0.3USD (0.01*30USD at the peak) will just kill any sub-dollar tx, or force them out of the blockchain (what SD suggested to do). (OK, may be I should start a BTC micropayment service) Is it possible to improve the protocol, so we could tolerate SD-type tx while keeping the fee low? |
|
|
|
Yeah. After thinking about it, it seems that SatoshiDice actually proves Satoshi failed with his ideas as BTC cannot possibly scale. Oh, I wouldn't quite agree with this statement. It does still work - just causing an incredible increase of the number of orphaned blocks. Sort of a reward deprecation from the 50 BTC to.. something less, which was not planned in the initial design  Yeah. I still think this is a problem. Are the developers acknowledging this or not ? This is causing more orphans and more stales for everyone mining  Unless the tx fee is so high which could compensate the orphans, miner will start to reject tx like what Eligius doing. Eligius is simply putting the burden on other miners and increase their orphan rate. Although I agree SD is abusing the network, a successful BTC network should be able to handle 1000x of current volume. If SD is a stress test, the network is failed. It means the network cannot grow further. Without changing the current infrastructure, there are 3 options: 1. Miners will allow only a limited number of tx in a block, but this may leave some tx never confirmed and BTC is dead; 2. Increase the tx fee by 10x or even 100x; 3. A revised tx fee formula to punish people using coins with <3 confirmation. All these solutions, however, would be short-term. If more people use BTC (which most of us want to see), the same problem will emerge again. If this could not be solved, this will be a major bottleneck of the whole system. |
|
|
|
Ahh. I can feel the thought process you went through. I totally sympathize with you. I don't know about you, such a mistake could've let to much more than 10 BTC loss! So, it's not fun, but it could've been worse (always trying to stay positive) I think it would be pretty easy to add a box to let the user specify what address they'd like to use for the change output. That doesn't entirely solve the problem, but it would at least serve as a reminder and give you a way around shooting yourself in the foot like this. I can take it a step further, and add a wallet option/flag that tells it to stick to imported addresses only. The question is, when I need to create change, how do I do it? Send to the next address that hasn't had change sent to it recently? Have the user specify a universal send-change-to address? Require them to specify it every time? Obviously, this will be under the advanced interface  P.S. -- I'm still claiming that my program has never been responsible for losing anyone's money. I'm sticking to that claim even after your report Is it possible for users to specify the root key and chain code? Then we could have deterministic brain wallets and don't need a paper backup at all. |
|
|
|
Wrong. The difficulty changes every 2016 blocks, not 2 weeks. Yeah...talk about disruptive technology...lol Most of the 21 million bitcoins would be mined in no time compared to the original estimates...
the difficulty changes every 2 weeks. So unless we could online this massive amount of hash power in that timeline, difficulty will quickly increase to keep the block generation as close to 144 per day as possible. you know what I meant..... They are completely different. If the difficulty change is time-based, we could theoretically mine 21 million bitcoins instantly. But this is not true |
|
|
|
Wrong. The difficulty changes every 2016 blocks, not 2 weeks. Yeah...talk about disruptive technology...lol Most of the 21 million bitcoins would be mined in no time compared to the original estimates...
the difficulty changes every 2 weeks. So unless we could online this massive amount of hash power in that timeline, difficulty will quickly increase to keep the block generation as close to 144 per day as possible. |
|
|
|
|
May I ask if there is a command-line mode for armory, either in Windows or Linux?
|
|
|
|
|
I have a question about the security of the deterministic wallet algorithm of Armory. Is it possible to deduce the private key(s) of other addresses in the same wallet in the following situation?
1. Knowing private key of one of the addresses in a wallet
2. Knowing private keys of many addresses in a wallet
3. Knowing private key of one of the addresses in a wallet, and having the watch-only wallet
4. Knowing private keys of many addresses in a wallet, and having the watch-only wallet
For example, Alice shares a watch-only copy of her wallet with Bob, and she also needs to share private keys of some addresses with Bob. Could Bob deduce the the private keys of other addresses in Alice's wallet?
|
|
|
|
I tried to create new wallets. It simply dies with "Illegal instruction" no matter it is encrypted or not. It dies even I click "receive bitcoin". However, it could show the existing addresses without dying. I also tried to run as root. Since I did not use it with root before, there is no wallet. However, it still has the same problems So I believe there is nothing wrong with my wallets. Do you have any idea where the message "Illegal instruction" comes from? Is it somewhere in Armory source code, or from a 3rd party package? In the worst case I have to reinstall the OS but I want to try to fix it first first of all, i'm using ubuntu 11, and I'm already starting armory as suggested. Everything seems normal except a few GTK-Warning about pixmap at the beginning
no, my label is very short so that's irrelevant
I tried to delete one of my wallets (which contains no BTC at all). When I try to restore by paper backup, the "Illegal instruction" death happens again. When I tried to type one wrong character in the root key field, it first shows Checksum error, then illegal instruction death. When I tried to put all "a"s in the root key and chain code, it just shows "Checksum fix failed" and won't die.
As long as I still have the correct paper backup, I suppose my BTC is 100% safe, right?
Thanks!
Yes. So far, no one has lost any money with my program (at least no one has reported it), and I've never had a hint of a problem with paper backups. So, the odds are good your money is still safe I see now that you are having the problem on multiple wallets, which leads me to believe something went awry with your system, an encryption library, and/or the Armory installation itself. But you said you reinstalled with the newer version, so it's probably not the Armory installation. And all the encryption/signing stuff is compiled in, so I don't think that would be it... Can you make a new, encrypted wallet, and see if it works as expected? Unencrypted wallet, too. I am done for tonight, but I'll continue this conversation tomorrow. I'm anxious to figure out what's going on... |
|
|
|
|
first of all, i'm using ubuntu 11, and I'm already starting armory as suggested. Everything seems normal except a few GTK-Warning about pixmap at the beginning
no, my label is very short so that's irrelevant
I tried to delete one of my wallets (which contains no BTC at all). When I try to restore by paper backup, the "Illegal instruction" death happens again. When I tried to type one wrong character in the root key field, it first shows Checksum error, then illegal instruction death. When I tried to put all "a"s in the root key and chain code, it just shows "Checksum fix failed" and won't die.
As long as I still have the correct paper backup, I suppose my BTC is 100% safe, right?
Thanks!
|
|
|
|
|
Show Posts
