Ah, didn't notice that. Also I honestly forgot you'd mentioned you're working with 4-layer boards, guess that would drive the cost of fabrication up a bit

Have you tried Fritzing Fab? Just going from their examples it seems like they'd be cheaper. Not sure if you can have them leave the white paper off since you're working with SMD stuff (or if they leave a hole in it for the component?) but I thought I'd put it out there.

It's a terminology thing. Transactions aren't orphaned, whole blocks are and the blocks contain the transactions. My particular blocks only contained the "generated" transactions which were my reward for mining them, but they just as easily could have contained actual transactions which would have been orphaned along with the block that contained them.

Edit: Oh and for the record, your 0/unconfirmed transactions are also "at the tip of the block chain"

OK, to be a little clearer, 6 confirmations was not an arbitrarily chosen value, but an hour was. Any amount of confirmations (even zero) can be acceptable, depending on the level of risk you're willing to accept. As an example, let me share a personal experience: I was part of the i0coin launch, and was solo mining when difficulty was still something like 16. I found something like six blocks back-to-back and within two minutes every last one of them was orphaned. This is sort of an exaggerated example, the real problem being that i0coin was being so heavily mined at such low difficulty that the whole network was claiming and arguing over blocks several times per second, but the thing to take away was that in the two minutes or so those transactions were valid for, they gathered 20 or 30 confirmations and then still got orphaned. The number of confirmations is meaningless to the chances of rejection, the amount of time, among other factors, is far more important.

For in-person transactions you have little choice but to accept a transaction at 0/unconfirmed or perhaps 1/unconfirmed if your customer is patient enough. It is worthwhile to note that, while I have no data to back this up, I suspect that the number of transactions seen at 0/unconfirmed that become orphaned is SUBSTANTIALLY less than the number of transactions you would expect to see reversed in traditional credit card processing. I hope to have data to back up that claim soon.

The true "confirmation time" is NOT changeable. 6 confirmations was not arbitrarily chosen, it was chosen because it represents about an hour of the entire network crunching away at blocks after the initial transaction. For the same level of security you need the same amount of TIME regardless of how fast the blocks are solved within that time. Faster blocks simply increase the chance of orphans. If you need faster transactions than the hour required for 6 confirmations, just accept transactions at 1/unconfirmed or 0/unconfirmed - it's EXACTLY the same as speeding up the block times since TIME equals security, regardless of the number of blocks generated in that time.

Think of it this way - if I have a team of elite soldiers who are about to blow up an enemy installation and they need to be 2 miles away to be safe, it doesn't matter if they drive that 2 miles at 10 MPH or 60 MPH, they STILL won't be safe until they're 2 miles away. If they drive super fast for too little time and they're only 1 mile away they're still dead - it's the miles that count not the speed. Making confirmations take 3 minutes instead of 10 and still accepting transactions at 6 confirmations is like driving 60 instead of 10 but only driving 0.6 miles away before setting off the charge - you need at least 20 confirmations at 3 minutes each to meet the same security requirements as the original 6 at 10 minutes each.

Faster block times without longer confirmation requirements equals LESS security. That might be perfectly acceptable to a lot of people, and so it's still a valid change for the fork, but it needs to be duly noted that a SolidCoin transaction is NOT as secure as a bitcoin transaction until it has 20 confirmations.

I actually just wrote the exact same thing in the main thread but I'll repeat it here.

If we learned anything from the I0Coin startup (which was quite the fiasco) it's that faster block generation drastically increases the likelihood that two or more miners will find conflicting block solutions and that one or more of them will be orphaned. I haven't done any real tests just yet, but it's my suspicion that faster block generation times will be directly proportional to the number of orphaned blocks. This makes sense considering that block generation is the only time when a block can become orphaned and SC's ~3.3x faster block generation speeds mean that transactions are subjected to the possibility of being orphaned ~3.3x as often.

I plan on testing this thoroughly but it will take some time. First I have to mine a reasonable number of testnet coins on both networks, then I'll bash out a script that sends one tiny transaction on each network ever 15 minutes or so and let it run for... well... quite a long time to gather enough data to be statistically meaningful. It's basically a monte carlo simulation that I'm forced to run in realtime. If anyone has a better way, do let me know.

Edit: It suddenly occurs to me that certain people or companies already HAVE wallets with thousands or millions of transactions in them. If MagicalTux, for example, could do a "bitcoind listtransactions" it would be a trivial matter to go through the JSON and count the number of orphans vs the number of total transactions and it would save me a lot of time and effort on the BTC side. It would also answer one of my two questions quite quickly and I can fill in the rest with SC testing. We could also combine the counts of a large number of people. For SC tests, perhaps DoubleC could do the same with the SC exchange's wallet after a while?

After I've gathered several thousand data points I'll come back and post my results. This should also be useful for merchants since it'll finally answer the question "how often will a 0/unconfirmed transaction actually be orphaned" and we can finally decide if that number is lower than the percent of credit card transactions merchants expect to see reversed. I've long suspected that it is, but without data that's just my optimism speaking.

This one does at least seem to have some meaningful improvements over BTC unlike IXC and I0C, though once again I find myself reminding people of the same damn thing! If you make it so that we confirm 12 blocks per hour instead of 6, all you've done is lower the individual security of each block by half, meaning that to get the same security level found at 6 confirmations in the standard bitcoin client, you have to wait 12 confirmations now. 6 was chosen as the magic number of confirmations specifically BECAUSE it represents the block being buried under about an hour's processor time deep in the chain, and would therefore be quite difficult to undo. You're welcome to choose an arbitrary number that fits your needs better, but you'll be sacrificing some level of security. I personally have never seen one of my transactions get orphaned, except during the first couple hours on I0C, so for very rapid BTC transactions (like those done at a point of sale) I'd feel pretty comfortable accepting at 0/unconfirmed with the knowledge that significantly fewer transactions will be lost to orphaned blocks than are likely to be reversed if I accepted credit cards.

If anything, the fiasco that was I0C during the first few hours shows that the faster you make block generation occur, the HIGHER the chances are that your 0/unconfirmed blocks will become orphans since faster blockchains are more likely to fork under normal circumstances. This is the one feature change in SC that I don't like, and 3 minutes seems excessively fast. I'd have to run some studies to confirm my suspicions but I think all we've accomplished by changing blocktime to 3 minutes is to make it about 3.3 times more likely that a 0/unconfirmed block will be orphaned and therefore made SC 3.3 times less useable for traditional merchants.

WE DID IT!!!!! WOOOOT!

97%!!!

Another important question: what is the expected lifespan of such an FPGA board running at 100% 24 hours a day 7 days a week? 6.8 watts sounds awesome but without knowing an average lifespan to amortize the hefty initial cost over I can't say with any certainty whether this is better than GPU mining, and if so by how large a factor.

While stackable would indeed be nice, you can use splitters for the time being. Each rail on a regular computer power supply is 12v @ 5a, or about 60 watts. Even the cheapest power supplies have two rails with regular molex connectors for a total of 120 watts. If you load both rails to 80% (96 watts) you could put 7 boards on each rail, thus pulling 1.4 GH/s for less power draw than a single 5830. Of course right now that'd cost you $3,080 but who knows, given enough time price could very feasibly come down

Edit: oh yeah, and a couple USB hubs. I'm assuming the amount of bandwidth these things take is trivial, right?

Once again, for the record, decreasing the time between blocks solves nothing. There's nothing magical about that sixth confirmation except that it took about an hour of processing time to reach. If blocks were found every 5 minutes instead of 10 we'd be waiting for 12 confirmations to get the same level of security. Folks who were part of the ixcoin and i0coin launches should ESPECIALLY know this since the various exchanges and pools were all making you wait 50, 100 or at one point 1,000 blocks before coins could be considered "confirmed" because multiple blocks were being found each SECOND. It also illustrates nicely that if the amount of time between blocks were to be set too low, multiple miners would "find" a block at once and the network would argue over which was valid for a bit, which would create constant horizontal branching and orphaned transactions.

With the exception of those few numbers actually changing the shape of the distribution curve, the i*coin forks have actually been a good demonstration of why certain things about bitcoin shouldn't be changed.

So you mean it's a method for eliminating risk and maximizing profit? That... actually sounds like everything that every successful business does... ever...

I could probably hack something together. I doubt my code would be hacker-proof either but I've at least got enough knowledge / skill to put it out there and let people pentest the hell out of it and i can fix whatever they find

I'm crazy busy with work and school right now but I'll see if I can find the time.

Closed and reopened, cleared out %appdata%\roaming\i0coin (except the wallet.dat) etc. I think I'm klined from the IRC server but I don't know why none of the fallback methods aren't working either.

Sitting at 0 connections for a long time now. Any fallback nodes I could add to my config?

I'd be more for setting up some kind of web-based escrow service BACKED by human intelligence. Let there be some kind of automated system that covers all undisputed transactions but let humans settle all disputes. Your list is pretty decent so far, and though I don't have much in the way of free time I'm willing to spend some of that free time helping wherever I can. Let me know what becomes of this.

Nah, I don't think poorly of you or anything, I was just pointing out some discrepancies in your statements, that's all. I do agree with your base reasoning though, that we need to get more mom'n'pop type places accepting bitcoin. Sadly I don't see it happening at the big stores for some time either.

Wasn't comparing you to apple, necessarily, but the fact is they are one of, if not the largest merchants in this particular marketplace and whether or not it's by me, you WILL be compared to them. I understand 23% VAT is standard in your jurisdiction , which raises the price to about $1.23 or about €0.85. We can all find a "comparably priced" item marked up to insane prices no matter what product we're trying to sell. The fact that someone else is gouging doesn't mean you're not - your price is to be compared to industry standard prices, not compared to other gougers. 10% off a price that's 300% too high is still gouging.

Edit:
For example - http://www.memory4less.com/m4l_itemdetail.aspx?partno=HD-583X-ZNFV&itemid=1462346931&rid=fd_10
ZOMG only $418.62 for a 5830! That's $104.65 off their list price of $523.27!!! Or, y'know, $300 more than you'd pay from newegg...

Never said you did. IMO there's not enough here to make a meaningful case. I'm an "until proven guilty" sort of guy. The question was, why would it matter if you were Thomas - and no offense but I would indeed be worried if the maintainer of a fork of extremely non-trivial code with alpha-quality features shoehorned into a gold release was asking very green questions a mere month ago.