BTW, I am running a full bitcoind on a 80USD ARM baord: http://cubieboard.org/ without any problem. So are we facing a big problem? I would say not yet How much time did you spent on initializing? How much time will you spend on restore corrupted DB? How much time will you spend for sync if your bitcoind will go down? Initializing: about 36 hours. But remember it's only a ARM board, like your cell phone. It could be much faster if I copy the blockchain files from another full node to the board Restore: It has been running for 14 days without any problem and is still keeping up with the latest block. and........... how about my SPV suggestion? |
|
|
|
so nodes will have an option to store full chain or only its part? So SPV client like MultiBit is what you need BTW, I am running a full bitcoind on a 80USD ARM baord: http://cubieboard.org/ without any problem. So are we facing a big problem? I would say not yet |
|
|
|
By the way its not really an upper limit: n+1 is a pretty valid private key, it's just that it's equal to 1 (as n+1 mod n == 1 mod n)
If you generate that way you will end up with keys which are not equiprobable. The difference from uniform is very small, but its a certificational weakness you should avoid. Is the version of securerandom.js used at bitaddress.org safe? https://github.com/pointbiz/bitaddress.org/blob/master/src/securerandom.jsI personally don't trust any computer generated random number. All my addresses are generated with other methods with 256bit entropy |
|
|
|
有两笔从外面转过来的BTC，交易费用是0。几个小时了，一个确认都没有
一般这种情况会什么时候才能到
要看個別情況才可判斷. 你可以把交易號碼放上來嗎? |
|
|
|
who crashed first?
should be China |
|
|
|
what's wrong with China? Why they don't buy at 1900? Is it a cursed number or something?
There is a 1000BTC wall below it |
|
|
|
Looks like China is awake, and not afraid to continue buying it up.
Yes, the fiat transfer from bank account to btcchina is instant and fully automatic, which means it literally works 7*24 and no bank holiday. |
|
|
|
Can I generate new keys from this address?
The answer is quite obvious....... Can you recover the key with the address in my signature? |
|
|
|
Wow, Either Bitcoiners have really learned not to panic or the news hasn't spread. The Selfish Mining attack :https://bitcointalk.org/index.php?topic=325824.msg3494144#msg3494144 https://bitcointalk.org/index.php?topic=324413.msg3475905#msg3475905Something like this, though clearly mentioned "theoretical attack", would have triggered a panic sell @ $260. this published well before the rally. just a theoretical and mostly impractical attack |
|
|
|
This process runs away and leads any pool that starts with >33% to end up with >50%, at which point the classic 51% attack becomes possible.
So that's the 51% attack mentioned in Satoshi's paper. I can't see any originality here |
|
|
|
 I found an interesting fractal when comparing tonight's chart with last week's "mother of all cuphandles". Maybe it forecasts something that's about to happen: We go sideways for a day while drilling away at the resistance and then have a massive breakout? I feel the same. Another handle may be forming |
|
|
|
So I just bought some bitcoins and wanted to try to make them as safe as possible within a reasonable way. I also happen to have a raspberry pi, so here is what I did:
On my normal computer:
1. Formatted SD card.
2. Installed raspbian.
Then on my Raspberry pi:
1. Connected to the internet.
2. Updated software.
3. Downloaded and installed printer software.
4. Went to bitaddress.org and saved it.
5. Disconnected from the internet and changed raspbian log in password.
6. Generated multiple copies of my paper wallets and printed them.
7. Stored paper wallets and SD card in different locations I consider safe.
I could also secure wipe/destroy the SD card but I don't think it's necessary at the moment and I might want to create more wallets later on (I will never connect to the internet again of course).
I realize there are a few ways this could be insecure (other then gaining physical access to my wallets) such as:
1. Bitaddress.org doesn't make random enough addresses offline.
2. Some kind of software from when I installed raspbian on my normal computer or when I connected to the internet through my raspberry pi changed how bitaddress.org makes its keys so they aren't really random.
I can't think of anything else at the moment. How likely do you think any of the above is and what do you guys think in general of my method? Thanks in advance!
Depends on how paranoid you are, you may: 1. Check the hash of bitaddress.org against the one on github. Check it on the offline raspberry pi, not on the desktop computer 2. Audit the bitaddress.org code if you could 3. Never allow the raspberry pi connect the internet again or simply remove its lan port. Never use it for any other purpose 4. If you worry about randomness, generate private key by throwing dices, and transform the key into address with bitaddress.org 5. Never connect your printer to anything other than that particular raspberry pi. Your printer may store the private key in its RAM |
|
|
|
266.00001  |
|
|
|
china is a 7 yuan from their ATH....
Looking at the charts they had an intraday high of 1944(!). But yeah, closing-price high has now been surpassed. The march 23rd dump on that chart is crazy. I know, I had to rub my eyes too. It says they sold down to 10 CNY, or 1.64 USD - dayyum! 16,000% profit in 7.5 months? Yes please. I wonder what the volume on that was. That was a bug in their trading engine. Someone put an ask order at 10CNY, intended to sell at market price, and being executed at 10CNY. As far as I remember, BTCC compensated the loss of the client. The same bug was (is?) also found in bitstamp's engine. So be careful |
|
|
|
This problem as I see it is non-existent. As I've talked about before Mining Block References (MBRs) can tremendously reduce latency which would squash this attack. 1) Make the nonce long enough that the extraNonce field is no longer needed in the coinbase transaction. 2) Now it's possible for miners to broadcast their Merkle tree as soon as they start hashing (10 minutes on average before they finish) 3) When they find a valid hash, now they only need to broadcast the block header because the rest of the network has (usually) already received and validated the Merkle tree. 4) Block header propagation is very fast and not dependent of the size of the blocks. I feel that this post might be the solution to this 33% attack. As a valid block must be pre-broadcasted in the step 2), earlier than a certain time period, and there is a single time system globally, the Selfish Miner's private block should not be seen as valid if it has no pre-broadcasted Merkle tree. This precautions essentially makes everyone can announce a block no faster than a certain speed, so that we can constrain the centralization of Bitcoin mining power. Selfish Miner can also pre-broadcast his Merkle tree. The interesting points of this solution are to minimize the advantage of the low latency connection of the selfish miner. |
|
|
|
All ASIC will be broken so basically no one will follow this hardfork. All ASICs get replaced after a few months anyway, so it would be no problem to define it 6-12 months in the future before implementing it. The arm-race won't last indefinitely and it will eventually slow down. I don't see any chance to change the format of the 80bytes header unless absolutely needed, e.g. SHA256 weakened or timestamp overflow in the far future |
|
|
|
|
Show Posts
