Ah. Now I understand! But— instead you could use a soft forking rules (not a hard fork) to prohibit those txn in the chain.  That would also avoid the potential omg-bitcoin-takes-my-money confusion.

How would that be superior to simply disallowing those transactions?   Beyond being a hardfork, what you're describing may have the unwelcome surprise of your funds being taken from you in some cases.

I am disappointed in this turn of events.

Though I disagreed with the whole approach of setting a bunch of rules instead of building a community, I thought it wise to hack at the proposed rule a bit in case they were eventually applied.

The page sat with edits made by myself, Ripper234, and Luke in a single state for about two weeks with no further edits— one might have assumed that we'd found a formulation that no one interested found horrible.

Then today in a single series of edits Ripper234 performed a substantial rewrite and declared the page official policy.

This isn't how a community process works and I am disappointed.  I've provided additional commentary at the talk page and I'd suggest further discussion be moved there since the forum appears to be failing as a discussion mechanism for Wiki content in this case.
 

Would be nice if it generated compressed public keys instead. Doing so shouldn't take any longer, may even be faster— the compressed key is just the x part of the public key with the initial byte set based on Y being even/odd. The uncompressed forms result in keys that take up almost twice the space when spending.

Well— for some level of DIY—  someone like RPH who feels at home skillet reflowing $150 FPGAs might consider it one.   I'm mostly surprised that none of the companies making S6LX150 devices (ztex, x6500, etc.) have produced a device based on 28nm FPGAs for sale. Availability has been good, they could have even beaten Avalon to market... and at the moment there is so much demand for ASICs you'd think you could make some good sales with something that was at least ASIC-competitive but with a lower time to market.

I'm surprised to not see some small mining devices based on artix7.  I would expect their power usage to be basically competitive with Avalon... and the retaskability of FPGA is worth paying a bit of a premium for...   Seems odd to me that there hasn't been any motion in that direction.

Ohhh. Close but not quite.

The behavior of the chain proves that that much computing power was not being applied to mining in the first year, otherwise the difficulty would have become 1.66 when it couldn't actually sustain 1. I continue to be impressed at how much you insist on the hysterical speculations and conclusions rather that just going and measuring the speed of the old openssl sha256 as I had.

Scrypt is irrelevant here— they're just as vulnerable to people bouncing between coins.

Merged mining was created to solve this.

"Retep" does kinda have the same ring as "bernanke"…

More seriously, I know Retep has been working with trusted computing and remote attestation.  A quorum of trusted computing signers that securely talk to a great many nodes (need authenticated p2p and a WOT) and will never sign blocks that continue a fork that cuts back a previously existing chain valid chain by more than N blocks... would be pretty neat. Though its sort of outside the Bitcoin security model. You could even fidelity bond them, but fat lot of good that would do since the underlying currency where the bonds are would be destroyed by their defection in the event that it ever mattered.    Perhaps such a device with bitcoin fidelity bonds would be a good way of securing an altchain.

The original software is far slower than you give it credit for... I benchmarked old openssl code on a contemporary P3 a while back and got about 47KH/s as I vaguely recall. Why don't you go test it instead of making guesses from comments.

I would also not assume that the timestamps on the pre-public blocks are accurate— all we really know for sure was that there were at least two blocks created between 03/Jan/2009 and 11/Jan/2009. Rounding that down to 7 days suggests a lower bound hashrate of 14 KH/s.  Even if Satoshi had more computing power he might have simply been borrowing it for testing.

The guesswork that more work was done on the initial block is not supported by the low extranonce— you can't just say "more zeros == more work", for example:  http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d   has an "apparent" difficulty comparable to the total work ever done on the blockchain.  Sometimes low values happen.

Because its required to have at least that much, the difficulty cannot go below 1.

I think you're confusing miners with people who sell their computing power to miners. Someone who has no knowledge or interest of the integrity of the blocks they are producing are little more miners in the language we'd use to describe the security properties of the system than AMD or a random electric company is— the only difference is that they potentially have a kill switch which they could use long after its too late.

Maybe! I hope so too.

But I also think the burden of proof when arguing to degrade security should be to show that some compensating thing exists and works, not arguing that _maybe_ it will come into existence.   It's hard to put the loss of trust genie back into the bottle: "Well we haven't been totally compromised... yet". But once we have been, it's too late.  (This has now been pretty thoroughly demonstrated by altcoins: They don't achieve adequate security, someone comes in and reorgs them and then they're dead)

If it's obvious that size X will be safe, then increasing the acceptable size to ~X should be pretty straight forward, and if people can't be convinced that its safe— it ought not be increased.


I took a couple days to wait and contemplate this and took time to reread the thread and the other responses...  Because I can't figure out where Mike did this, or why you believe it.

What Mike pointed out is that people can create additional transactions that give away funds to miners.  They can be redeemed by _any_ miner— ones mining an honest chain or a dishonest one that reverses the current consensus, one where difficulty is increasing or decreasing, one which includes one set of transactions or another.   Mike doesn't explain why Patron organizations will perform these acts of charity as opposed to sitting back and hoping that other people perform them,  he doesn't explain why people who want to fund security in this model wouldn't just mine themselves (and then at least they know their resources aren't being spent on a chain that rips them off), he doesn't explain how in this CommunistMinerUtopia the Patrons know how much security is actually required except by getting attacked (something no alt-chain has survived),  he doesn't explain how the Patrons can afford to make offerings which are sufficiently large to achieve adequate POW when— with "infinite" blocks— _honest_ miner's have "infinite" cost in just processing/validating/transmitting blocks.

He even alleges that "There's no downside to [500,000 micropayments] being able to benefit", when there are substantial costs to transmitting, validating, and storing additional transactions— and that these costs make it more costly for all the honest participants to enforce the honesty of the system.  Perhaps the cost is worthwhile, but I don't think we can have a good discussion when they're falsely set to zero.


In short— Mike hasn't answered the question at all. He uses a lot of words (pot kettle black, I know) to point out that people can make additional transactions for the pure purpose of jointly giving coin to miners and then basically says that people will do it because it's a public good.

The joint mechanism itself is a distraction: In the proposed protocol the miner can just add his own outputs to the contract and snarf up any amounts offered, so it would appear to buy nothing— just using plain transaction fees at least has the advantage that if the txn in question falls out of the chain the miner doesn't get paid.

If something being a public good is sufficient then why doesn't it work for altcoins?  How can you be 100% confident in something which has demonstrably failed to protect other cryptocoins?

I agree that transactors becoming miners actually works in preserving the interests of people making transactions... Mike argues that assurance bond payments would be provided by Patrons who had major interests in the security of the coin, presumably under the miners themselves argument these same parties would be the only miners and validators for the "infinite block case", but then the result is not well distributed the control of the system would rest in a few large hands (presumably nation-states). In that case perhaps mutual distrust keeps the POW from racing to the bottom, but that conclusion has other problems.

He did not. I mined during that time— so did many other people I've talked to. As you're probably aware the original software mined _very_ slowly, and contemporary hardware was slow. Heck even a fairly current machine with state of the art software can just barely do enough hashrate for difficulty 1. (and god, before more handout requests come: Bitcoin was worthless then, the software was annoying windows-gui only— I ran it in wine+vncserver, and I didn't keep my original wallet)

Its nice when bad arguments are so easily falsified.

The coins created by the genesis block are forever unspendable.

Now someone needs to make a simple tool that checks twitter over tor and talks to bitcoind via RPC and sounds klaxons if twitter seems to be claiming a longer chain.

It would be trivial for MtGox to prove that they were not fractional-reserve, and as a community we should demand it from all bank like services. (Unless they explicitly claim to be fractional reserve).   Lets be clear though, right now you're accusing MTGOX of being thieves and liars— substantial claims require substantial evidence.

This has been asked before— and I think it's an important question. We shouldn't just assume that any feature is good.

After extensive consideration, I think I can answer this with an emphatic "Yes".  Without good anonymity the fungibility of Bitcoin can be substantially degraded.  The road to fungibility loss is paved with good intentions, but the end result makes Bitcoin less useful as money.   "We're really sure that _this_ bitcoin was stolen" ... "We're quite confident that this person is bad" ...  but if Bitcoin is to be trustworthy you must never have reason to feel that you'll wake up on the wrong side of a kafkaesq heuristic, or that you'll have to fight for what is rightfully yours even if there is due process, having to defend yourself means you already lost.

I believe that the ultimate social good that comes out of weaker anonymity for Bitcoin like activity is fairly limited: Bad-guys will generally figure out good ways around the lack of transaction anonymity, but still get caught based on their other activities even when transactions are strongly private. The harms from not having good anonymity— the losses of privacy, the danger to fungibility— hurt everyone.

Then there is the question of should it be in the system or outside of it.  If we ignore the implementation cost, I think here again the answer is emphatically that it should be inside the system:  Putting it outside greatly reduces its effectiveness.   But right now implementation costs are non-trivial and so I don't think there is much of a question of including it in the system—  and, if people build it outside of the system: we can't stop them even if we were to agree that it were a bad thing.
 

... I'm really boggling at why someone would be constructing an S6-LX150 based miner right now when the 28nm FPGAs are shipping in volume now.

My initial read of their paper was interesting, but it was two to three orders of magnitude more resource intensive than would be required to make it actually viable.  ... This is still impressive since 1000x too big/slow is still way better than infinite, which was the best alternative I had for something that was actually decentralized.

(The lay explanation of Bitcoin was _meh_ as it glosses over the blockchain which is the only really novel and somewhat non-obvious part of the system at large)

My greatest concerns were: 50Kbyte transactions with 0.5 second validation time, stored in a step-2-then-a-miracle-occurs (DHT, presumably an attack resistant one created by unicorns), with a cryptographic accumulator which grows without bound and can't be pruned like the block-chain or compactly zero trust queried like the UTXO can if we add a commuted UTXO tree.

Something like this could be used in an external system and tied in via N of M multisig, and the authors acknowledge that but if you're going to take accept a (distributed) point of trust for that, you can use a chaum token like service can be constructed less computationally and bandwidth intensive than this.

On the plus side— approaches can only get better.

A useful way of thinking about it is this:  What would happen if the block time were infinitely small but latency was not?    Nodes would all have solved their own new block before a block from a peer showed up— each node would be its own network never (or at least infrequently) to converge with anyone else.

The same applies for speeds which are fast compared to latency:  They cause long delayed convergence events.  The particular number for 10 minutes is debatable... there is nothing that gives you that particular value .. it's just a security/scalability/network-radius vs confirmation speed tradeoff.

The infrequent blocks also keeps costs down on lite nodes which must process all the headers.