|
Post updated for truthlessness.
|
|
|
|
|
It favors small, old ones to minimize fees and to consolidate the dust in your wallet.
Edit: Wrong, see below.
|
|
|
|
|
I don't know how well DMG encryption has been audited. I reccomend using gpg or truecrypt which are both well scrutinized and available on all major platforms.
A 20 character password is sufficient if it is completely random but possibly not if it is from dictionary words. I reccomend against l33tspeak words which tend to make the password hard to remember faster than they add entropy. Either use a short fully random key or use a long list of plain words. Otherwise you will forget some bit of punctuation.
The rest of your process looks good for a highly paranoid approach.
|
|
|
|
Could it also be used as a storage space, a bit like how Freenet works? It already is. There are a lot of small plaintext strings in the blockchain already, and likely a bunch of encrypted data that we can't measure. It's pretty expensive storage per byte though. |
|
|
|
I think we are dealing with an age old problem of creating non-determinism out of a deterministic system. To the best of my knowledge it hasn't been solved yet. Modern computer systems are nondeterministic. Bitcoin is sufficiently affected by network latency and being a randomly-wired network that it's chaotic to the point of being impossible to create a discrete model; you have to do it statistically. The same goes for /dev/random / urandom which is are collected / seeded from high quality chaos such as keyboard interrupts. Computers also have true random number generators. Thermal noise in a resistor is popular and inexpensive method to capture quantum mechanical randomness. |
|
|
|
Using the timestamp or other block data would make this vulnerable to a Finney attack. You could mutually post an encrypted rock paper scissors roll in transactions, then mutually reveal the keys to see the results after they confirm. There's no practical reason to do it in the blockchain; it would be faster to just do it in email or a TCP connection; but it could be done for novelty's sake. It occurs to me that IP over blockchain would be possible. I'm actually surprised no one has tried it. If you think satoshidice is spammy you ain't seen nothing yet.  |
|
|
|
The article just talks about double spending which is a problem older than Bitcoin. https://en.bitcoin.it/wiki/Double-spendingI don't see any link to the actual research so I can't really say if there's anything new. |
|
|
|
This is absolutely not generally understood, and the main dev team should not assume this. +1. It caught me by surprise. I lost over 1300 btc. Where does that put me on the loser's list of losses due to carelessness? Ouch. That's enough to warrant some serious exploration of your USB stick. Definitely make a dd block dump of it before you do anything. Even if the undelete utilities can't find anything, we may be able to scrounge something. There's a good utility here for recovering unencrypted keys by looking for their raw signature: https://bitcointalk.org/index.php?topic=25091.0 . If they were encrypted you can probably place a bounty for someone to extend the program to recognize encrypted keys. |
|
|
|
|
Yes, it's the same as BTC. A pool's round is until the pool solves a block and therefore has some reward to distribute. The pool will go through many blocks in a round until they get one.
On LTC you'll see the blocks go even faster because it's set up to average 2.5 minutes instead of 10.
|
|
|
|
|
Yes that's normal. You always want to base the next block on the highest available one, so every time a new block is broadcast you start from there. This is not a setback because each new hash is as equally likely to solve it, so it's not like you're starting over.
If everyone kept working on the same old block we would still be on block #1, solving it over and over with ever increasing size.
|
|
|
|
|
Ouch, I wasn't aware of that - why would it throw away the pool?
|
|
|
|
|
Yes, your coins are probably still there. The client pre-generates a bunch of addresses for change, so it's likely all there.
Shut it down and rerun it in a cmd window: "bitcoin-qt.exe -rescan".
|
|
|
|
Hmmm, never thought about this type of love. I guess if this is true, we are all in a dirty business, no matter what coins you're interested in.  Kind of sobering, isn't it? I'm here because I love the technological and sociological aspects, not for collecting and coveting, but I know I'm facilitating those who do. I rationalize it as making money less evil than government issue, but it sometimes gives me pause to make sure I'm on the right path. |
|
|
|
|
"For the love of money is the root of all evil."
I usually don't quote that book but it's the first thing that comes to mind.
|
|
|
|
|
Check out Bitcoin Spinner on the Google app store.
|
|
|
|
Throw a huge amount of mining power at the coin, stop mining until the difficulty decreases again, rinse and repeat. Difficulty drops to a level where the added strength makes a huge impact... That's a scenario where you get difficulty waves like happened to Namecoin for a while, but it doesn't blow through huge numbers of blocks. Let's say you come online with an absurd amount of hashpower and mine through 2016 blocks in 1 minute. Great, huge head start! But then it retargets to something absurdly high. Your choices: either keep mining at that rate (and thus generate the normal 2016 blocks per half week); or pull your hashpower offline (and then fail to even get to the next retarget this year). The waves result in a SLOWER overall block rate because the down-cycles end up being extremely long. You won't get 100k blocks per month this way. |
|
|
|
|
Show Posts
