The linearize python script does not appear to have a method to accept a starting block height. I was not sure if Bitcoin-QT would recognize a bootstrap file not starting at block height 1. But it seems it does. This appears to work -



It generated a 3GB bootstrap between 250-270k which Bitcoin-QT accepted.

Will bitcoin-qt only recognize a bootstrap.dat file starting at block 1?

is it possible to use the python util to create a new bootstrap.dat starting at block 250001 ? For example - to update an off-line PC which has only had previous access to the 250k bootstrap.dat.

Creating a new 10gb+ file up to 270k+ seems silly when I only need to create the difference between the two (and easier to transfer to off-line PC).

Thanks.

To clarify - I would only be redeeming outputs that were previously generated on this off-line Bitcoin-QT instance. I would not be redeeming outputs that other third-parties may have sent me, but rather outputs that I have only signed myself. I gain no further information by downloading the blockchain, other then seeing which block my transactions were accepted in.

I suspect Bitcoin-QT won't let me spend unconfirmed outputs though? I know of at least one web-wallet that allows this. I would simply like to use the core-dev client instead, off-line.

If a transaction simply contains a list of inputs and outputs and are not tied to tied to specific blocks.. it seems to me that Bitcoin-QT should be able to sign a transaction (and subsequent transactions) without having the updated blockchain. Or, will Bitcoin-QT not spend unconfirmed outputs?

If it could spend unconfirmed outputs, then you should be able to perform a transaction and dump the raw transaction output... burn it to CD and copy the transaction to an on-line Bitcoin-QT installation and re-broadcast it. Could this work?

Legend.

http://www.youtube.com/watch?v=9sJUDx7iEJw

"Hoarders can get piles of money,
That is true, hackers, that is true.
But they cannot help their neighbors;
That's not good, hackers, that's not good."

Spend your coin.

If throwing 3 dice... would need to ensure you don't introduce any bias such as reading from lowest to highest. Would be best to read dice from left to right as they fell.

This is nice. The hex format can be confirmed with this I think -

echo 'obase=16; ibase=6; 0123450123450123450123450123450123450123450123450123450123450123450123450123450 12345012345012345012' | bc

Nice to not have to rely on computer rng.

This is nice. The hex format can be confirmed with this I think -

echo 'obase=16; ibase=6; 0123450123450123450123450123450123450123450123450123450123450123450123450123450 12345012345012345012' | bc

A nice way to input dice throws directly into bitaddress and not have to rely on computer rng.


Separate question - can bitcoin-qt import base16 directly?

Why this was moved to "Off-topic" I do not understand. I originally posted Economy/Marketplace. Many Bitcoin sites use Cloudflare.

That is my point. Cloudflare then sees the unencrypted data. Apparently this is of no concern?

Is it correct that in order for a site to utilize Cloudflare to protect them from DDOS on port 443 (SSL), that site must install their CA signed cert (private key) on Cloudflare's servers? I think Cloudflare did a deal with a CA to even stream-line this process.

Regardless of how data between Cloudflare and the site's real IP is subsequently proxied, does this effectively mean that said site must implicitly trust Cloudflare and any parent it may be answerable to? Is this a MITM scenario?

Due to the nature of SSL and CA infrastructure in general, I don't think there is a way around this natively. Is there a way for a third-party to filter (ie from flood) your SSL data securely? If not, perhaps some JS crypto could fill the gap between site and user? Of course, secure JS delivery has its own problems under such a scenario..

I like using Ubuntu with Bitcoin-QT. I also play with bitaddress etc offline. The default Ubuntu installer creates a swap partition. It provides an option to encrypt the user folder, but not swap. Might someone have a link to a how-to to resolve this concern?.. ie, encrypt the swap partition? Or, what might be the best way to tackle this in Ubuntu?

Thanks.

If you have Bitcoin-qt open or another client etc, is it possibly Linux might swap the memory (and keys) to swap? (and therefore to disk). Even though you might have wallet.dat encrypted, could the keys inadvertently be dumped to disk? How could this be avoided? Perhaps just have a lot of RAM so swapping is not needed? This could technically even occur with javascript key generators correct? Is it possible to zero-fill the swap partition after exiting the client?

Enter the same private key and passphrase into bitaddress and bit2factor. You will get a different result, but they both produce the same unencrypted result.

bit2factor.org looks interesting for encrypting prior keys. Is it considered safe and who wrote it? There is a random element to the BIP38 process, so the output is always different.

Hello there

Note above. Would some one know if above method for generating private keys from a dice-generated seed be "secure" ?

But will Bitcoin-QT import a private key directly? (not WIF) I am aware it has no checksum etc. Or would I need to rely on additional tools to ensure I generate the correct WIF key (example - bitcoin-bash-tools and bitaddress JS).




If I append "1", "2", "3" etc to the original series of rolls (seed) - sha256sum(3315135445366124436162446626244624624266466466622442224426424444624626624246264 4644646626242462622241) .. does this constitute a "secure" method for generating a series of addresses?



So, about 150 rolls of the dice?

Discussion of off-line secure computing, paper wallets, backups etc are beyond the scope of this post. I am aware of what steps to take. I also give these steps a lot of attention.

-----

I would like to create a bitcoin address using dice. I don't want to trust software and/or hardware RNG. I don't want to memorize anything. Therefore, I don't think Diceware is appropriate. I also want to prove to myself that my manual RNG is good. I also want to minimize potential issues with the human factor (me). I want to keep things simple.

Should I roll the equivalent of 256 bits of entropy with a standard dice (# of rolls?), and sha256 hash it for the secret exponent? What is a secure method for generating the bitcoin address from there?

I would then import the private key into Bitcoin-QT for spending (out of scope).


1. Is this a good approach?

2. If I append "1", "2", "3" etc to the original series of rolls (seed).. does this constitute a "secure" method for generating a series of addresses?

Does Armory sit on top of Bitcoind (ie RPC), or does Armory include a re-write of the Bitcoin crypto fundamentals?

Are there any concerns with Armory primarily being developed by a single person?

Say I have some .bit registrations. Currently they could be stolen from me? Under above scenario, stolen registrations might be returned to me? - roll back name updates to the block date of the vulnerability announcement? (or thereabouts)

reserved