Am pretty sure BenRayField would be interested in this (or was it his post earlier that prompted yours).

One issue I have found is that when specifying a tx amount when one has a "change" address then one satoshi goes missing in the "change" amount.

So starting from its default tx if I first set the BTC for the dest addr to 40.00 then it correctly creates a 10.00000000 value for the change, however, if I then set the tx fee to 0.005 the "change" output now appears as follows:

And if I change the fee to 0.05 the "change" output now appears as follows:

Maybe there is some kind of rounding issue going on here?

Can't you use the raw tx API to accomplish this?

(to make it easier you could use an offline "brainwallet.org")

Clearly you wouldn't measure this in milliseconds but effectively in clock cycles via a counter (which should be nanoseconds and good luck with measuring that with a video recording).

It is the asynchronous nature of the starting and ending events that provide the extra entropy (especially if the device was always looping a counter).

For improved initial entropy you could just require the button to be pressed and released several times before it is "enabled".

Haven't heard anyone offering that but it is worthwhile to check https://www.spendbitcoins.com/buy/ (although not at the moment) as sometimes they will sell BTC at close to the current Mt. Gox price (when they are wanting to reduce their BTC supply).

Note that this option requires you to deposit money in person at a bank branch but is fairly quick (same day).

Sure - the gap can be quite large - but unfortunately a wire transfer will take at least two days (and up to five days if over the weekend).

If there was a way to obtain a large number of bitcoins for AUD (without paying more than 1% above Mt. Gox rates and without having to trust some basically anonymous forum member or pay wire transfer fees or wait for days) then I would be very interested myself.

One fairly simple addition would be to have a button that is held by the user (for perhaps at least x milliseconds) and then use the CPU cycles between the user pushing and releasing the button to add entropy (as unlike the RSA devices a new address is only needed when a user "requests" it).

Unfortunately I think you are going to have to do an international (or wire) transfer (yes it sucks trying to buy bitcoins with AUD).

Also bear in mind that even though it looks as though there is a good arbitrage opportunity between the exchange prices the volume at Crypto is very low (so you probably aren't likely to end up making much for your troubles).

It depends upon whether you are mining solo or for a pool (and without extremely good hardware there is no point in mining solo) - but basically the main thing you are doing is trying to find a "random" number when hashed using SHA256 along with other data will produce a hash with a large enough number of leading 0s (according to the current "difficulty").

If you solve the problem (i.e. find a "correct" random number) and your work is able to be included in the "next block" then you will be sent 50 BTC (if solo) or a proportion of that amount (if in a pool). Also note that the 50 BTC reward drops by half every 4 years (and will do so soon).

To finally make a profit (in a fiat currency at least) you would have to sell your mined bitcoins to someone else.


As the other poster stated this hardware (and it's really only the graphics card that matters) will not do so well (so don't even attempt solo mining with it as you will just be wasting a lot of electricity for no reward).

Good to know they got back to you and perhaps you might want to remove the word "Scam" from the title of this thread.

My guess as to why the response was slow is that because their volume is small they cannot really afford to have many people helping out with support (which ends up becoming bit of a chicken and egg problem).

Yup - a quite painful lesson to whoever paid those fees - I would like to suggest that perhaps we add a "max fee amount" as an optional addition to the sendrawtransaction RPC with a fairly low default value:

Haven't noticed this (yet) and I have been using the watch list ever since it was added.

Also note that this topic would probably be more suited to the Meta board.

Oops - I should probably have said "send several tx's" with the old funds (the first being just a test one to make sure the new software and wallet is working).

A side benefit from sending the old coins to multiple new addresses is that future tx's will have a better chance of avoiding tx fees due to  "coin age".

The beauty of "colored bitcoins" is that it can exist within bitcoin without any change to the protocol (it only requires a client that can recognize the "colors" by searching the block chain) so there is absolutely no need for another block chain.

Actually I think you both have a good point but perhaps the Kickstarter platform was not really designed for the purpose the OP was thinking of.

I will be releasing a system soon that is perhaps far more suited to the OP's funding ideas than the current crowd-funding models (it will be its own guinea pig so we will see how it fares).

I think if someone has complete control over a potential victim's computer then just stealing their wallet (or installing a trojan that changes the payment address when you send BTC) would probably be much easier than this idea so I wouldn't really be too worried about this "cancer node" scenario (although keeping the client up-to-date is important).

I don't think that is quite correct.

AFAIA the IRC bootstrap is no longer used so I still don't see how this could happen (unless the victim was running an old version of the client).

And how exactly does the attacker control that (without having first hacked the victim's computer)?

Sorry - I edited the last post a bit late - as far as I know the standard client will send the tx to all the connections it has (nothing to do with who you are sending actual bitcoin to and in all likelihood your attacker would not even be one of those connections).

Is the point that the attacker is somehow the only connection the victim has to the P2P network?