When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6, generation got broken on the Linux 64-bit build. Version 0.3.8.1 is on SourceForge with the 64-bit binary updated. Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download Future versions after 0.3.8 will probably require SSE2. Anyone have Pentium 3 or older where this would be a problem? […]
Read moreMonth: August 2010
Re: bitcoin generation broken in 0.3.8?
After testing the 32bit and 64bit builds, the problem I can confirm what was already posted here, it just affects the 64bit builds. When I go back and trace what’s being produced, it’s the 64bit Linux machines (the 64bit windows machines don’t appear to have this problem) that aren’t producing […]
Read moreRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
Quote from: impossible7 on August 06, 2010, 11:37:20 CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is […]
Read moreEscrow
Here’s an outline of the kind of escrow transaction that’s possible in software. This is not implemented and I probably won’t have time to implement it soon, but just to let you know what’s possible. The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction […]
Read moreRe: A proposal for a semi-automated Escrow mechanism
Quote from: jgarzik on August 05, 2010, 19:00:30 Due to that recourse, it is unlikely to be used as an escrow mechanism 🙂 Really? Do you think people won’t be able to understand the benefit? (If your response is an argument that there’s no benefit at all, I guess that […]
Read moreRe: Bitcoin minting is thermodynamically perverse
I understand that the incredibly thermodynamic inefficiency I was complaining about is in fact very deliberate, and bitcoin might be said to waste as much energy as possible, as a security feature! Now I really don’t know what to think – because exactly what I was complaining about gives the […]
Read moreRe: latency and locality
What I’m suggesting doesn’t exist yet. There was related talk about similar issues on the thermodynamic perversity of generating blocks. If I have just one central node, the system could generate a transaction block in a fraction of a second. If you wanted, it could do this only once every […]
Read moreRe: A proposal for a semi-automated Escrow mechanism
So, the basic escrow works by two people working through a third party to exchange (usually money) for some other form of goods or services. In a transaction where both people are honest, the escrow business can essentially be automatic since the buyer gets his goods and approves release of […]
Read moreRe: Flood attack 0.00000001 BC
Quote from: bytemaster on August 05, 2010, 16:46:52 Right now the transaction fee address is left “blank” and the block generator fills it out. Now you would fill it in with the address of the person you are asking to build the block. If you’re only going to have one […]
Read moreRe: Transaction Overload Solution
In another thread I posted the comment below, but I felt that it was an important enough flaw that it should be addressed asap before bitcoin is overrun with huge numbers of automated non-micro payments. The real issue is that even a simple legitimate automated payment negotiation system could overload […]
Read more