|
How about hardware trojan and hardware keylogger?
|
|
|
|
I'm honestly tired reading all these silly accusations about how miners are evil and how we should resist against them.
It's just so stupid that I cannot even quantify the level of its stupidity.
First of all, miners are not evil - they are the power of the network by design
And second, even if you wanted to, you cannot resist their power, because they are the power of the network by design.
You don't like the miners' ruling the bitcoin - invent your own virtual currency, one that has it designed otherwise.
In the virtual currency invented by Satoshi in 2009, miners are supposed to rule and so they do rule - you can't change it, it's impossible.
And if you don't like this idea, then obviously you have not yet found a digital currency that is suitable enough for you.
Myself, I am going to stick to the miners' ruled currency, because I do find this idea of democracy a proper way to go.
Bitcoin is hopeless if majority of miners are evil. I don't think this will happen. I am just responding to jdillon's accusation: What you are proposing allows miners who wish to raise the blocksize to rig the vote by ignoring transactions voting against an increase, and it just takes a 50% majority of miners to do that. |
|
|
|
miners are willing to make it impossible for you to send funds to someone who is off-line or simply does not wish to vote
As you assume that miners are evil enough to reject votes they don't like, certainly they are willing to do so. We can and should further strengthen this protection by having all nodes only relay votes for outputs of confirmed transactions, never unconfirmed ones.
This doesn't help at all. Evil miners will require people send the votes to them directly, or publish them on a public forum. |
|
|
|
The POW for a block is equal to (1 + mini-confirms/16) of the normal POW amount
Why 16 instead of 64? |
|
|
|
Oh I missed the part about no tx on each mini block. So all this does is effectively eliminates the probability of one-block reversals. Hmm, I'm not so much in favor of this direction.
This does not only eliminate the probability of block reversal, but also reduces the average full confirmation time from 60 mins to 15-20 mins. My only point was that as your average confirm time moves closer to the header propagation time, you're dramatically increasing time spent by miners mining on forks. Sure you don't get one-regular-confirmation reversals, but you'll end up with a totally fragmented network all working on different chains because most of the network can't get the longest chain in time to switch to it. It may be that the header propagation times are, in fact, much smaller than 10s, in which case it wouldn't be so bad for the majority of the network.
But consider a miner on a slow, high-latency connection. If they have 10s latency to receive data, they would probably spend >50% of their time mining on forks. Basically, they wouldn't be able to mine.
They would probably spend 50% of their time mining on forks ONLY WHEN THERE IS A FORK. If the fork rate is 5%, they would spend only 2.5% of their total mining on forks Also, we may first try 1min instead of 10s. Mining with 1min latency is not possible anyway. |
|
|
|
I would like to share my post in my blog relating a society-engineering/technical attack on Bitcoin. The attack is speculative, and there is no certainty that I will succeed as described. Nevertheless the attack idea makes sense for me, and the suggested solution could prevent the network from other unknown market-socio-technical attacks, that play with human emotions like fear or greed. Here is my post: http://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/Here is a copy of the proposed solution: Add the Satoshi client a “Safe Mode” (since there is already a Safe Mode that is related to the RPC commands, this could be Safe Mode 2). In Safe Mode, transactions are only considered confirmed if they have 144 blocks of confirmation (1 day). Also in Safe Mode, the clients do not accept any chain reorganization of length greater than 144 blocks (this is the key restriction). One day has been proven to be enough for the core dev team to resolve chain forking situations, and still it is short enough to let people transact almost as normal. Only services that require fast confirmation will have to pause their operations, or accept payments of low value with the implicit risk. Safe Mode could be announced by using the network alert system, either by making clients automatically switch to this mode or by requiring the user confirmation. Safe Mode alerts would have a finalization date, as other alerts. Also Safe Mode would be immediately terminated by the "Alert key compromised" alert. This solution is very simple to implement (maybe 5 lines of code), and yet provides an incredible increased level of protection against attacks that attempt Bitcoin destruction. I has to be there so it never needs to be used. The only drawback would be if a 51% powerful attacker colludes with the dev team to activate the Safe Mode and create a 144 length alternate branch to split the network, which is of course a much more sophisticated attack. Best regards, Sergio. There are 2 possible solutions (and both are soft-forks): 1. Automatic checkpointing (or automatic alerting system) with Ripple-like consensus system: https://bitcointalk.org/index.php?topic=144193 This one is specially designed to fight against situations like ECDSA 2. Decoupling POW and transaction: https://bitcointalk.org/index.php?topic=179598.0This one allows 10 seconds/confirmation, without worrying much about network latency. There will be 360 confirmations in 1 hour and impossible to reverse without a real 51% attack |
|
|
|
Unfortunately that just isn't possible because miners fundamentally control what votes get into the blockchain at all. What you are proposing allows miners who wish to raise the blocksize to rig the vote by ignoring transactions voting against an increase, and it just takes a 50% majority of miners to do that. Not exactly a compelling majority of Bitcoin users is it?
This also applies to your proposal. 51% of miners can reject all "status quo votes" and blocks containing status quo votes. After one year, these status quo votes will get lower and lower weight and eventually the blocksize will be increased. |
|
|
|
|
I don't know how Firmcoins exactly works but I think there is a potential problem.
As you said, Firmcoin can export the private key to a smartphone through NFC. Is the following attack possible?
1. The phone requests the private key through NFC
2. Firmcoin sends the key through NFC
3. The phone receives the key but does not response
4. Firmcoin is not sure whether the key has been successfully sent, and does not delete the key. (If Firmcoin deletes they key without confirmation from the phone, the key may be lost if there is communication error)
Possible solution: the Firmcoin will always send a warning to the user if it had any unsuccessful key export attempt.
|
|
|
|
|
First of all, the private key is simply printed on the physical coin, no SD card involved.
Anyway, you proposal has no advantage at all, because it is equivalent to transferring bitcoin to another address. You can throw the physical coin away after that.
|
|
|
|
很多NAS是基于Linux系统的。
最简单的方法是在WIN上映射NAS上一个磁盘，然后将钱包路径指过去。
NAS:
1、buffalo(巴比禄) ls-250gl
2、Synology(群辉) DS412+
想改机，大家给出出注意？
NAS的系統保安很差 具体说说。 我已找不到那文章. 但有專業的電腦保安人員研究過, NAS內置的系統很不安全, 例如所有伺服器都直接以root運行 |
|
|
|
很多NAS是基于Linux系统的。
最简单的方法是在WIN上映射NAS上一个磁盘，然后将钱包路径指过去。
NAS:
1、buffalo(巴比禄) ls-250gl
2、Synology(群辉) DS412+
想改机，大家给出出注意？
NAS的系統保安很差 |
|
|
|
我的安卓手机里装了一个比特币钱包，里面有3.4325 BTC。
前几天我的手机不慎恢复了出厂设置，于是手机里的东西全没了，包括钱包在内。
私人密钥备份过的，备份在SD卡里，但重新安装了新的钱包后才发现无法找到备份文件，即程序无法自行导入密钥。
现在我手机里装的是另一个全新钱包，版本似乎与以前相同，就是里面空空如也。
我今天终于找到了老钱包的比特币地址，请问有办法找回这三个多的比特币吗？谢谢！！！
你的sd卡內找不到任何備份? |
|
|
|
Bitcoin: The Last Straw for American Banker  |
|
|
|
Let's say the IRS wants to be able to confiscate bitcoins from tax evaders. So they go to the US courts to get this. A judge ends up ordering the bitcoin.org dev team to include a government backdoor so the IRS can take funds away from those who don't pay taxes.
The devs would be forced to comply right?
The devs are not forced to comply because they can simply abandon the project. They have no obligation to contribute to the project. If the government want to add a backdoor, they can always hire a programmer to work on that. They can also confiscate the bitcoin.org and put their version of bitcoin there. However, people can still contribute to the original bitcoin project anonymously, e.g. through TOR network. In that case, a hardfork will happen: the original bitcoin and censored bitcoin |
|
|
|
I am asking for a forum member who is not good in English: https://bitcointalk.org/index.php?topic=226133.0 (discussion in Chinese) He lost his password to his bitcoind wallet. As I read somewhere before, it is possible to extract individual encrypted private key from the wallet.dat . The wallet owner who lost password may publish an encrypted private key with zero balance, so other people could help cracking the key while unable to take the money even the password is found. The wallet owner will then buy the password back. I forget how to do this. Anyone help? Thanks! |
|
|
|
好像有一個方法, 你可以把錢包內其中一個沒有錢的新地址的加密密匙抽出來, 在這裏公開. 如果有人能破解到密碼, 也拿不到錢包的錢. 那時候你就可以用那58.8BTC的一部份來交換密碼.
例如你可以懸紅20BTC, 如果有人找到密碼, 你就等於可以找回38.8BTC了. 你賣0.1BTC, 怎樣也不可能有388個人買.
但是, 如果你已經把錢包賣給了任何人, 以上方法已不適用
加密的怎么样才能变成密匙？ 你有沒有把錢包發給過任何人? 如果還沒有, 我可以在英文版面幫你問怎樣做 |
|
|
|
|
Show Posts
