It's an interesting thought experiment and it's not entirely impossible either; say for example, if Mt Gox became sufficiently large, after they compiled statistics on their average cash withdrawals and deposits per day, they could quite feasibly loan out their hard currency on the interbank market; they may potentially already be doing this, however, it is extremely unlikely it would ever have any impact on users unless they are lending the funds out for extended periods, in which case a run becomes possible, otherwise, worst case scenario is that someone has to wait an extra 24 hours for their withdrawal.

The same could potentially be applied to BitCoins, but with the current level of market activity and the nature of the system itself, there's no real feasibility to it.

in regards to your IPv6 comment... IPv6 is actually very easy to restrict; only allow one freebie per /64 and also check if any requests made within a short space of each-other have come from the same /56 or /48 and if so, block accordingly.

are you retarded or just a lunatic?

If you care, run an API spy on the EXE - I release it as an EXE because that's what Satoshi does, and the installer is in fact identical except for including x64 headers.

As a previous poster mentioned, if you give a toss, extract the binaries yourself, although I think if you're trying to imply I'm using the installer a springboard for something nefarious you're clearly off your trolley, any genuinely malicious person would put their code in the BitCoin EXE, not the installer.

Yeah, my opinion on this is that the GUI should be separated from the underlying code. BUT... there's no need to throw the baby out with the bathwater and I firmly believe that the current wxWidgets interface should be maintained until such a time as something superior comes along.

My personal feeling is that whilst separate daemon/GUI binaries can work, it also tends to be messy, I'd be far more in favour of having the core code and then separate source that you compile with it according to your target OS, that way everything is still a single binary and can be integrated as idealistically as possible.

To put this in practice, imagine 3 SVN trunks; the first is BitCoin core, the other two are LINGUI and WINGUI - the latter two being dependant on code from the first.

the Visual C++ 2010 x64 runtime is required, link provided by previous poster.

And definitely delete the DLL you provided, that error means you got the 32 bit one

for precisely the same reasons people run lottery syndicates.

problem is, in a lottery syndicate, obviously you will know who paid into the ticket fund and who didn't.

How do you plan to verify someone in the syndicate is actually trying to solve blocks?

The best way I can think of is by measuring their average number of hashes per second and then have a secondary target their client must achieve which acts as a proof of work for the syndicate to know that this person is dedicating their CPU resources to generation.

My usual x64 build. based on the latest SVN code.

It doesn't contain tcatm's SSE2 hashing code and instead uses the Crypto++ x64 MASM (as in my previous builds) since after testing both, the x64 MASM proved to be about twice as fast.

Download Bitcoin 0.3.10.3 here

if you found this useful, my BTC address is below

it doesn't, so you must be smoking something.

just an idea for making it a bit better:

randomize the amount the faucet gives out with the randomisation occuring once per day, per IP, you can bias it towards lower sums if you really want; either way, this would strongly disincentiveise abuse because it'd make it a real bastard to make any real profit from it.

Yes, but what's so special about cash? it's just a type of asset; you're simply reaffirming that if you are using something to purchase bitcoins, the notional value of BitCoins will be increased because of your willingness to exchange it for a different asset... you could put a car up for sale with X amount of bitcoins accepted as payment, that too would have an effect on its value, however, if your price was way above or way below the current averaged value, your distortion would be short lived.

Yes, because that recourse open up the possibility of either victimising people who have grudges or simple trolling (just look at 4chan) ... a host of trolls will get buyers to do escrow transactions and refuse to release them because it costs them nothing to do so.

An effective automated escrow mechanism needs to disincentivise both parties from scamming/trolling.

Sure, you can do it as asm instructions or you can use the SDK to make it more easy to read, it's going to result in the same code in either case.

the bitcoin usage of SHA256 does not prevent you from using Padlock C style functions because they are the same standard of init, update, final.

why bother? Via publish an SDK for it.

I should also point out that you will need the lib files for linking.

Even if the difficulty increases, you will ALWAYS have an advantage over everyone else who cannot compute hashes as fast as you.

ok, posted the installer in its own topic, go ahead and grab it.

For those of you who are familiar with my builds, just download it

For others: this is an x64 build which leverages x64 asm to perform the SHA256 and has some minor optimizations such as unnecessary Byteswaps being removed.

if the buyer refuses to finalise the transaction and the seller refuses to permit a refund, they have 2 choices.

1) be spiteful and nobody will get anything

2) agree on a third party to send the money to. that third party will be an arbitrator who will weigh up both sides of the argument and come to a decision as to who should be returned the money, minus whatever fee they agreed with the two hurt parties.

Subsequent to this, I also realised that my suggestion is open to trolling whereby a seller makes someone do an escrow transaction and then refuses to ship anything or arbitrate, my solution to this issue gives the following modification of the system:

the buyer makes an escrow transaction which is then presented to the seller, if the seller wants to go ahead, they must agree to be debited a sum stipulated by the buyer, the seller agrees and the escrow transaction then goes into the network for inclusion into the block chain, both parties are now down on their money.

if everything goes to plan, the buyer OKs the release of the funds and the seller gets the payment + his "trust deposit" returned.

if the buyer wishes to cancel, the seller authorises the cancellation and both parties get their original funds back.

if nobody can agree on a release, both parties now have an incentive to go to an arbitrator, when the arbitrator is authorised to receive the transaction funds, the trust deposit gets immediately returned to the seller, the arbitrator doesn't get a say over those funds.

I'll grab the SVN tonight and upload it for consumption

precisely, and the hashes you generate are going to be completely invalid because the target your systems are aiming for will be higher than the one the network requires.