Derp, I'm a dummy. I meant ZFS. (if it was ReiserFS I probably wouldn't have mistyperemembered)

http://docs.oracle.com/cd/E19253-01/819-5461/gavvx/index.html

XFS with checkpoints every hour, then besides having a robust journal that can be replayed when powering up, you can roll back to a previous checkpoint.

If by "not exact correct", you mean potentially orders of magnitudes off (by not understanding how Bitcoin addresses are encoded), than you are correct.

The chance the second digit is "A" is about 1/22. The probability the same position is "1" is 1/256; for it to be "z", 1/1353.

The probability that the 34th digit doesn't exist is about 1/41.

The probability that positions 1-20 are all "1"s is 0.
 

Picking the low hanging fruit - so then I can't spend my money. I've received .5 "even" and .5 "odd" into my wallet, neither of which were under my control. Now I want to pay 1 to a single party.


Have it ready how? A block work still needs to include the hash of the previous block. Miners could be duped into flushing their work and working on the wrong parity by malicious header broadcasts. Maybe you should define what you mean by this.

You seem to be mixing your definitions for odd block/transaction/address etc.

It seems like you would need to have proof that the idle computing devices were actually idling. Maybe by having them do some cryptographic hashes of blocks that are lower than the full difficulty in their idle time, and then submitting those to the pool to measure the hashrate of the device (so that everyone is compensated fairly for idling their mining devices). This could be a benefit to all members of the pool, because there is a change that these idle-time proof-of-works could sometimes even solve full difficulty blocks.

Did you try pressing "yes"?

Your threat to damage your own property does not hasten my reply.

The hash that comes out of a strong hashing algorithm has a random distribution. Although it is less likely, it doesn't take any more work to find a 000000000000000001.. hash than it does a 0000ffff.. hash, only luck.

The blockchain requires each block to meet the proof of work. To replace ten past blocks, you would have to generate ten blocks of your own. This is a much higher bar than a single lucky hash being able to replace ten blocks.

With a more-difficult-hash chain instantly winning like proposed, it would be an orphan free-for-all, you could get one lucky hash attempting to build on blocks from a week ago and replace tons of transactions. As described, a miner could attack for free by

1. constantly be transferring a large balance between new addresses in every block they mine,
2. find a "lucky" hash much smaller than the average and withhold it, and
3. make all sorts of purchases that will be wiped when they publish the chain-erasing block find that sends the money back to the miner.

OP already annoyed everyone with his great ideas based on a poor understanding of mining here: https://bitcointalk.org/index.php?topic=823544.msg9204175#msg9204175

Is the config file being put in the datadir? You tell bitcoin at the command line -datadir=/media/myusb/.bitcoin/, then that's where the config file has to be.

Tails has network filters to block anything not going through Tor, it is likely the rpcallow= command along with the proxy setting that isn't going to let you connect back into a daemon with the network stack, although loopback<->loopback should work if you specifically allow a non-routable local IP.


https://tails.boum.org/contribute/design/Tor_enforcement/Network_filter/ - notable:

Local services whitelist

The Tails firewall uses a whitelist which only grants access to each local service to the users that actually need it. This blocks potential leaks due to misconfigurations or bugs, and deanonymization attacks by compromised processes. For specifics, see the firewall configuration where this is well commented: config/chroot local-includes/etc/ferm/ferm.conf

Verification is disabled up to the most recent checkpoint, block 295000. The hash and headers leading to it is known trustworthy, so signature checking is turned off. That's what I said that you just quoted. If you remove all but the first checkpoint from chainparams.cpp and recompile, you will find a quite different result.

(295000, uint256("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983"))

BTW, you have 4 cores with hyperthreading, CPU-Z your machine. Still, a $300+ CPU is not the lowest bar.

In a Bitcoin ATM thread two years ago:

A risky thing to do is to accept credit card payments into your payment system. The fraud and chargebacks inherent in the system make it unmanageable, and the only way to prevent the company financial harm is to screw over end users.

Bitcoin: send money regardless of a third-party-profiteer's opinion.

When you port forward, you must specify the IP address of the internal computer running Bitcoin. If you are using DHCP, this does not guarantee that the internal computers will always receive the same IP addresses. You should set up a DHCP fixed lease in your router for the particular computer's MAC address, or manually configure the IP address on the machine itself.

Only one device should should be a DHCP server for your local network, and there should only be one layer of network address translation (your router's external interface should get a real internet address from the modem or network it is connected to).

Bitcoin Core will tell you the size of the keypool through an RPC command, which you can also type in the debug->console window. Here you can see the result of me setting the default higher:


>getwalletinfo

{
"walletversion" : 60000,
"balance" : xx.xxxxxxxx,
"txcount" : xxx,
"keypoololdest" : 1308965703,
"keypoolsize" : 201
}


To have Bitcoin Core maintain a larger keypool size to future-proof wallet backups, you can increase the keypool size as an option in your Bitcoin configuration file. I have written a guide with an example configuration file which includes the keypool option - simply remove the comment "#" and change the setting from the default of 100. The "Bitcoin data directory" link there also takes you to documentation to locate your OS data directory.

If you want to use up the keypool, you can issue the "getrawchangeaddress" command as many times as you have addresses. Encrypting a wallet will also discard the keypool and generate a new one.

No. The first challenge will be functions that have had name changes. itertools izip used in the salsa mix function had a name change in Python 3. xrange is renamed to just range, but range() is not an generator in py2, etc. Better that Python 3 has a syntax error than Python 2 does the wrong thing.

I might change over to https://github.com/ricmoo/pyscrypt from http://hg.saddi.com/scrypt/ if I've got time to clean up and merge that code into one file (it is about 20% faster at encryption) and then see what other traps I find. Until the majority of LiveCDs don't run Python 2 as default this won't be a big concern.

How would you say bcrypt? The same way you would say scrypt.

You can write off mining with anything less than a current-generation ASIC miner; anything else isn't even worth your time to set up.

Even with someone else paying the electricity, you need to look at whether you will even get a break-even return on your hardware investment. Bitcoin mining difficulty is extremely high and run by large miners and may continue an unstoppable uptrend, this makes your future earnings a guess. The block reward will be halving in less than two years.

You also should not take a possible future rise in Bitcoin price into account when choosing to mine. If you predict the price will increase, you can just buy bitcoins now with your money instead of trying to earn them over months and years.

1BTeQw63egu3r8ju2n85T1Uf6ifssWJxzk, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUMMzJXdRKc
1BT9fd6DLopvATwHX7EjihdxgEtTBjwsYW, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUNYDEvd3SU
1BtWg6esDx8DmvNHBfDgZ9AtsdB87wywri, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUSxfYT54xh
1BtRrn3XZ3fjXZKkXm74TS27tdkLufjgE5, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUcUv1r2oMY
1BTgd8skyrcNh3z1TvohSopZ9PYHo3oP42, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUdGjFK7kDF
1BTkAD8w89BsUo19KUj8JVQ5JDvs8WJgNY, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUtv2nYpZQ6
1BToChzkUcCPNdY2RGxfymYdLG3fAHVJ6q, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUyvr492dng
1BTpDD7HohMALpURFGjCjq8ro2z6pwi2WX, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVEDUFKziRZ
1BTzL4GrkmRpZgLVgptpCJqhjPxkn3jeJx, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVFo6aLx8zp
1BtAezWY6k7eDhb4Yofz8jVT8zeFpNnUFN, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVJ54P6REeT
1Btz9QdNv7HPpcYg2Q7jZSa1t448JUVUU3, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVJmPrtNmqf
1BtHp6fWwKwBYHsAw1jHGPLbDGUYJF2HC2, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVNJZJHMr3u
1BtZhxENWm4pu1WX8GUDHZw6JgPZuH6xqn, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVc1KVTjS8J
1BTsAfe2D6ytutTBdVMMBoDiiPqu13TwGx, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVkcnTxbpuQ
1BtprfDEt2DrDUo5ViqyLRiWuMaQncWVkD, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVmyTu5Fp8P
1BTA7MCfZQrxbTA1cnaopMxXcCUGJ9EE74, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVpwm68pKBH
1BTzwcpnjbAB1LHtyDBhLuJdeTdjWcmqHB, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFW3Hqrn4RYF
1BTiJ6hstvHAxmPxqkWpcyNveFshbkZp4R, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFWDGV731Kaw
1BToo8r2TaU7vd31w3TC2trzJHHsMub7Np, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFWH2bZJnJc1
1BTG6CFSx6sFVFbqzikWzzYBh9bS1Nockh, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFWKX1Vdh6Wm
1BtKphaSZTmiFLLnw9EDfxggHyZvs3TYYo, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFWY8XYJBeBi
1BTcmJw45ztiKC4PzUjzG2HsjMw1LiTtPk, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFWYyptnvzaE
1Bt6F25rSzFKdn8SQpNLKf4ReDHrz6px1, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFWhkkf3unU3
1Btj6VkuQKHm5Q2X7kg4Tc5pNZpUB7noTs, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFWkQ8PiUQ8T
1BtD3iaeWToGksydE9FWEQAczqCTJXbrGn, KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFWyrwsg24sS

oh noes I just posted private keys because I'm a noooob..

edit: even worse, I just sent money to the first one, heavens me!

You do not need be careful because the person posting it needs to be trustworthy, you only need to be mindful not to accidentally reuse the address. After importing, Bitcoin Core will not give you this address when you use "request a payment", but you could do something silly like look through your list of past transactions and take the address from there when you ask someone to send you money. I never underestimate the ingeniousness of idiots.

Even for dust, someone will quickly snatch up and spend private keys I've posted before with a balance for fun. It's first-come, first-serve, since anybody can use the secret key to spend the money.

Just signature and Merkle tree analysis of the whole blockchain (which is disabled by checkpoints) would take ~24+ hours of modern CPU processing power. These need to be performed by every user in a trustless environment. Optimizations are beneficial to every user, whether by utilization of available hardware resources, algorithmic shortcuts, or even hand-tuned x64/SSE assembly code routines.

Impractical. The minimum criteria are that the attacker must be running their attack analysis program on the same CPU core as the one signing hundreds of signatures with the same key, and also must capture the data of each signature and correlate them with the signing execution.

A scenario would be if I got a virtual host on the same single-core box as is running a service like a mixer or an exchange, and was allowed to send the service's wallet thousands of transactions to the same address and then was also able to force that service to spend them in a way that I could monitor and correlate in isolation from the other signatures they would likely to be doing. Just the fact that the service is running Bitcoin and a web interface that also use CPU and resources might be enough to obfuscate this OpenSSL analysis... this is for the most part academic, but it does demonstrate at least in a clean environment a way of recovering a key through side channels where an algorithm should not present a cryptanalysis attack surface.