This is better than I could ever imagine: religious freakery mixed with golden calf worship really produces comedy gold.

Godminer-Jr is warning you: if you have a nice little research chain it would be sad to see it unable to process transactions. It has been written on the tablets revealed on Mt.Sinai: Thou shalt have none other chains before mine (Deuteronomy 5:4-21).

Godminer-Jr is warning you: if you have a nice little research chain it would be sad to see it unable to process transactions. It has been written on the tablets revealed on Mt.Sinai: Thou shalt have none other chains before mine (Deuteronomy 5:4-21).

I'm doing a full quote of gmaxwell's post to try to preserve it for posterity.

I like it the most where he came up with "tiping the incentives" as an euphemism for extortion.

Luke-Jr has a very stilted writing style. gmaxwell is a world-class copy-writer.

We used to joke about "mining cartel". But now we have "mining mafia" consolidating the control of their territory. Forget about doing a collection for Max Keiser to shoot a short about Bitcoin. We should do a round of fund-raising to induce F.F.Coppola to direct and produce a "Godminer" triptych. 

Summary could spoil the suspense of the message at the end.

http://www.youtube.com/watch?v=q4-Qyu9KbBo

I'm far away from my server room, but from the memory: it is under Advanced Peripheral/IO Configuration; PCI resources. Normally everything is on Automatic. With working hardware find a correct static configuration, then remove all working cards and reboot for hot plugging of the bad one. We've done it many times flashing x86 BIOSes to the SCSI cards that had BIOSes for other architectures, like Itanium, Alpha or SPARC.

Anti-static precautions are a must.

You could try hot-plugging. But first set up the BIOS for static assignment of resources to the PCI. I never tried this with the AMD/ATI card, but it worked for some other rare peripherals, like video capture & compression card or strange SCSI controller.

By hot-plugging I mean: power-on without the card, go past the self test, interrupt the boot manager, plug in the card, allow the boot process to continue.

I'll pretty much believe that in the Bitcoin milieu anything is possible: if somebody builds a "pig in a poke" ("Katze im Sack") market it will find willing participants. Those phrases became proverbial because there was a continuous demand for it throughout the history. There will be natural extensions for them implemented using Bitcoin. That's what makes Bitcoin such interesting from the anthropological perspective. 

What a charming old-fashioned prediction! Deepbit will merge with an exchange and it will offer negative effective transaction fees to the users of the exchange.

Joe will offer "Mining Pool and Guaranteed-payback Three-card Monte": that's the market demand amongst the Bitcoin miners.

It may be interesting from the anthropological point-of-view: who's gonna fall for it. Technically the negotiation for inclusion in a block doesn't make sense: the blocks are won randomly. I guess from the game-theoretical point-of-view one could come up with an optimal strategy: clairvoyance.

Zhoutong is not afraid of loan sharks, Zhoutong IS a loan shark and has a nut collection to prove it. 

I'm sorry, due to my copy/paste error this fragment didn't get included in my earlier post.
This is probably due to three factors:

1) you collect only one-sided statistics
2) the mining protocol on your end is extraordinarily simple: "getwork" or "getwork <hexstring>". Thus probably some corruptions show as "stales", "invalids" or some such.
3) on your end mining protocol has shorter packets. To really see the errors the amount of data exchanged needs to be larger that TCP/IP MSS (maximum segment size), which in turn depends on MTU (maximum transmission unit)

I only ever solo-mined test coins, so I'm not really familiar with the details of pooled mining. For solo-mining without a pool server the error detection is nonexistent.

Ha ha! This is a very good joke. It may be the most succinct way to describe a modern bucket shop.

Hi slush!

After waiting a while and reading the replies and comments to your proposal I now understand your approach and my mistakes. Basically I only took a helicopter tour of Klondike, but you are the one who has a ground floor experience of Klondike. I'm kinda living a sheltered life: I'm never on the first line when talking to my customers: before they talk to me they need to jump a trench or two in my organization. I'm not avoiding my customers, it just that the ones I interact with were already filtered. This is completely unlike you: are the one who speaks to every customer.

I now understand that there's no point of trying to require advanced features like pair-of-FSMs design if the potential users are only familiar and comfortable with RPC-style designs. I searched this board for any sign of anyone writing about state-of-the-art financial services technology. There wasn't anyone who would mention things like CICS,Tuxedo or even no-cost MTS & MSDTC.

If the residents of Klondike demand lighter pickaxes there's no point of offering hydraulicking.

I wouldn't recommend switching to XML. What I was trying to suggest is to try re-host some features of XML-based protocols on top of JSON or whatever else you choose. I think you already doing that. The main advantage of SOAP is that first-line tech support person can say things like "Parasoft SOAtest agrees with our diagnosis, the errors are on your side" and avoid the cost of escalated support calls.

Well, NAT breaks the end-to-end principle of IP networking. But the real culprits are usually various marketing-motivated enhancements like SPI (stateful packet inspection); "gaming mode"; "multimedia prioritization", etc.

The "stateless" discussions remind me of "zero configuration" discussions in other areas. After all the late-discovered problems get fixed the "stateless" design is way more complex and fragile than the competing "stateful" designs.

My general suggestions can be summarized as follows:
1) store coins with as key pairs plus the block hash and height in chain
2) client connecting to server send a chain length and tip block-hash of the last connection
3) server responds with positive difference in height and new tip block-hash
4) in case of the reorg server responds with negative difference in height and hash of last block pre-fork followed by the same information as in (3) for the new branch.
5) client can recalculate the wallet and retry the transactions that still have valid inputs after the reorg
6) server takes a proactive retrying approach to the transactions it originated. This is particularly important in case of the reorg and when the originating client already disconnected.

I didn't do a complete http://en.wikipedia.org/wiki/Transaction_processing analysis, but there is a number of possible compromises in the spectrum between a fully ACID-compliant design and a ball-of-rubberbands design.

All Berkeley DB database files in Satoshi client are "multiple database capable". In effect they are B-trees of B-trees, where top-level B-tree contains only one node with key "main".

I don't know how to get to the 2nd-level B-tree in Perl. Probably it is documented somewhere.

At this table we are playing a zero-sum game. I know slush is the "house". But who pays the rake?

But at whose expense?

Earlier I was simply "not impressed". But right now I switch my opinion to "starts to stink".

Yeah, good luck to whom?

Do a "traceroute bitcointalk.org" and answer your own question.

All protocols are equal, but some protocols are more equal than others.

Son of a Bit == Slush's Overlay Network over Bitcoin