Rofl you actually calculated 25 plus 1 * 1.3/100
So you summed 1.3 hundredth to your 25 instead of summing 101.3 * 25 / 100

>>> http://lmgtfy.com/?q=101.3%25+of+25

That's no problem since I have an ATX 24-pin splitter that turns on both PSUs simultaneously. What I'm wondering is whether it creates some sort of power differential having the motherboard on one PSU and a connected Graphicscard on another.

Using the molex-modified PCIe x1 cables, and they work so far. Now I'm at the maximum of my PSU and will order a new one. Just a quick question: is it save to power a card on another PSU than the others? I basically have 3 cards already all on 1 PSU, and the fourth will be on PSU #2, and connect its 6/8-pin connector and its molex to this PSU.
Could there be a problem or am I on the safe side?

Yup, I guess most questions will be about the protocol anyway, so there's no problem there.
Is the mailing list moderated? I think that would be usefull (unless we try to repeat the mess of the forum).

This is the classical bootstrapping problem of P2P Networks. We are considering to use BitTorrent trackers as an alternative way to bootstrap.

Sounds interesting, until you realize that assuming that at difficulty 1 you'd calculate the whole week, and now at difficulty 567358 you'd only be allowed to calculate for 1.066 seconds (http://www.wolframalpha.com/input/?i=1%2F567358+week). There is no way to coordinate this timeslot worldwide
Not to speak that all transactions would be confirmed in that small timeslot...

1) the /admin you use the user and pass from your config, while / is for the workers to contact, so there you'd use the miners username and password
2) Since you run the proxy on a webserver you'll probably have to point the workers to http://<ip>:80/

HTH,
cdecker

Great thanks, looking forward to the list.
The forum just became too crowded lately, and a lot of FUD around...

You host it yourself, if it goes down you're in trouble anyway

Just a quick question: is this just for mainline client dev, or are we alternative developers allowed to ask questions too?

Or you can use the flexible mining proxy (http://forum.bitcoin.org/?topic=5506) to configure more than one pool and it will switch for you. Compatible with most miners

Yup, got scammed by b4rrydoyle (5184) too. It's just 20 BTC but still... Hopefully dwdollar can publish the payout address for those scammers so we can start collecting all addresses they're using and start to track them.

Would you be interested in collaboratively creating a PDF in LaTex that would capture both the message format as well as the protocol behavior (something like the Pseudo-code presented in http://amzn.to/mgpDhH )? I had the idea a while back, but I'm under exams for another week.

Super, endlich haben wir einen potenziellen konkurenten zu MtGox

TH-R1924

Checksumming and the message magic bytes seem redundant, that's what Mike and I where thinking. Probably Satoshi was hunting down a bug in his code and introduced them. I love the magic bytes however since it enabled me to track down a bug in my protocol implementation (non-blocking IO and not yet completely filled read buffers ). A simple CRC should be enough for checksumming, if we want to have checksum at all. On the other side being a non-trusted network, and since any client may bomb you with anything, the checksum is not needed at all

In order not to waste your precious Bitcoins start the client with the -testnet option, that way you'll use a different network, and you'll be able to test between two testnet nodes. Just to limit your losses

Could you post the address you are sending to and the address that shows up in the transaction log?

The no-cancel is by design, the transaction being broadcast in the network we cannot guarantee that a cancel will reach an eventual block generator that includes it into its block.

Changes to message formatting and byte-ordering do have a lasting effect on the hashes that are used throughout the network. So everything that ends up being hashed is set in stone, unless we want to run dualstack for a really long transition period (until the last input from the old protocol has been spent, which probably will never happen due to lost wallets...).
Having to adhere to the existing protocol for large parts makes other changes pretty useless, as sad as it sound...

What I would like to do is add some structure to the network in order to reduce message complexity (think DHT for transaction inputs instead of everybody tracking everything), detect network partitions and a more hierarchical network topology (miners in the center, lightweight clients at the edge).

Yes, 20min is incredibly good at being bad

As the title says, today is IPv6 day, but not for the mainline client.

I'm happy to announce that (theoretically) Mike's bitcoinj and my BitDroidNetwork are in fact IPv6 compatible, the only thing that's missing is the IPv6 address format in the addr messages and we're ready to go

I opened (and closed) the pull request, even if I found it quite stupid to create a pull request for a semantic change...

Anyway I wanted to freeze the version number in the version message, and only change it when breaking changes are introduced. This way we could create clients that see a version number and say "ok, I speak that too", and then go ahead and communicate with each other. As it is now each new client version potentially brings breaking changes, and we have no way of being sure that the protocols are compatible.

I closed the pull request, because it was just plain stupid to have one for 2 added comments, and I thought it best to wait for the topic to come up again.