Vladimir and ArtForz are probably the only ones dealing with that kind of volume (if at all). But I don't know if they'll want to sell at that price.

Things like this tend to be prone to Sybil attacks. I'm not an expert but what I learned from comments like this is that there are some very good reasons why Bitcoin is based on Proof-of-Work rather than trust. Not sure if this applies to your system.

Downloading the tmx file doesn't seem to work for me.

There are a lot of subtleties with correct functioning of RTL languages in various software, some of which can't really be seen by looking at just one line, so there really is a need to look at a more "wholesome" chunk and see that it turns out correct.

I'm sure crowdin has its advantages but for me it would be much more straightforward to simply create a translated Word file and send it to you. Is that something which will be easy to import to OpenDraw? I don't know how to create the diagrams, but I can send separately a list of translations of the terms involved.

Also, I think trying to translate the bibliography is futile.

0% fee PPS (and I'm talking about real PPS, not fakes) would have been best, but in fact it's too good to be true - in pools that have this this is a promotional offer that can't be sustained over the long run. Many PPS operators don't completely understand the risks involved and their pool is at risk of bankruptcy or switching to a safer method. But if a pool does manage to offer PPS with low fees it's better than any other method with the same fees.

But it doesn't matter too much. 100 MH/s is less than what some people have but it's high enough that you don't have to worry about share-based variance. DGM, PPLNS etc. will be perfectly fine and I think this pool is better than currently existing PPS offers. Larger pools have an advantage though.

You don't really need to understand the specifics of DGM. There are good methods and bad methods, and all good methods (such as DGM) will give you pretty much the same payout over the long run.

I'm mostly referring to ideas I've expressed in the previously linked thread, to augment proof of work with proof-of-stake and circulation (possibly quantified as bitcoin days destroyed) in branch selection.

This depends on who runs the botnet.

How do you block an attack? Reject blocks that have the "evil" bit set? (Actually there are ways, but they require a fundamental change in how branches are selected)

I only did a small part but I'm not at all happy about this. I could swallow it but now I have to worry this may happen again after I spend even more time. Is it possible to access the old translations so that only copy/pasting needs to be done?

Also, if I go to the translating page now the original texts are all messed up - going to http://crowdin.net/translate/bitcoin/bitcoins.html/en-he, for me at least the texts are in a seemingly random order.

My right-to-left question still stands.

I think I now understand what you're talking about. This is basically making the computation more granular, significantly increasing the time it takes to test one value (from a microsecond to 10 minutes).

I think you'll find that still, an entity with enough resources wins, and more easily than with the current system.

You're welcome, glad to help.

That's great and all, but it looks like the work already done has vanished.

This isn't about parallelizable vs. non-parallelizable computations. Performance in serial computations doesn't scale linearly with more computing cores, but this is irrelevant. This is about the process of block finding, which is why I asked if your system diverges fundamentally in the notion that blocks are something found once in a while by people on the network. If not then it's really "if Billy and Sally each have an apple, then that's two apples" math - if in a given scenario (not in distinct scenarios) two people find 1 block each, then both of them together finds 2 blocks. If a network of 4000 people find 4000 blocks per month, each finds on average 1 block per month. This isn't enough data to know the distribution (it's possible one person finds all 4000) but the best scenario is when each finds close to 1.

It also means that if in a given situation 4000 people find 4000 blocks, each finding about 1, then if I join in it would only be fair if I also find about 1 (or, more precisely, that each will now find 4000/4001).

Yes, with parallelizable PoW you can overwhelm the network given enough time and money. My contention is that non-parallelizable makes the problem worse, not better. With fully serial only the fastest one will do anything, so noone else will be incentivized to contribute his resources. So this one person can do the attack, and even if he's honest, it's only his resources that stand against a potential attacker (rather than the resources of many interested parties).

And there's no indication that some hybrid middle ground gives better results - to me it seems like more like a linear utility function where fully parallel is best and it gets worse the closer you make it to fully serial.

Also, I hold the position that security can be significantly improved using some form of proof-of-stake (basically a more methodical version of the hardcoded hashes).

See above. I think you're going the wrong way.

I'm still not completely sure what the requirements are, this whole discussion has been confusing to me. But yes, to me it seems that from a "back to basics" viewpoint a serial computation only makes it easier for one entity to dominate the blockchain, making the "better security" requirement impossible. Again, if multiple computers don't give more power over the network, it means the attacker doesn't have to compete against multiple computers, only against one.

You mean an alternative Bitcoin-like currency, or something that doesn't look anything like it? If the former I doubt this will be applicable, if the latter I can only speculate unless you give more details about the application.

The Bitcoin code progresses slowly, probably mostly because of the sophistication of the code, but I trust that all sufficiently good ideas will make it in eventually.

Halving is not going to cause doomsday, for several reasons.
 - Capital expenditure is a major component in mining cost. First, this means that there will be plenty of people who are making more than twice their electricity cost.
 - Second, it means that in the time before halving, people will avoid buying hardware in anticipation of decreased profitability, so the difficulty will be less than it would have otherwise been.
 - The price will gradually increase in the time before halving in anticipation of the reduced supply.


Not a counterargument by itself, because the point with doomsday is that difficulty doesn't get a chance to adjust.

Ok, you're definitely confused about the capabilities of someone with >50% of the hashing power. He cannot do things like put a 100BTC generation transaction per block. Such blocks are invalid and will be rejected by the network (particularly the nodes that actually accept bitcoins for goods and services). In other words, these will not be Bitcoin blocks - the rest of the network will happily continue to build the Bitcoin chain, while he enjoys his own isolated make-believe chain.

Does your system maintain the notion that each given block is found by some specific individual? If so, if 4 people find 4 blocks in 4 months, it means each person finds 1 block in 4 months, contrary to the premise that each person finds 1 block per month...

If it wasn't clear, in this example the intention was that the 4 people aren't all there is, there are 4000 more similar people each finding 1 block per month, for a total of 4000 blocks per month. So again, if 4 people find 1 block per month each, then between them they find 4 blocks per month.

Because the pool shouldn't be the one deciding what goes in a block. As was explained, a pool is essentially just an agreement to share rewards. Even in centralized pools (and like I said there are decentralized ones), all the operator needs is to verify that miners intend to share rewards, by checking that they find shares which credit the pool in the generation transaction. But everything else can be chosen by the miner.

This is a future fix, however - currently centralized pools do tell miners what to include in the block. But miners can still verify that they're building on the latest block, so they can detect pools attempting a double-spend attack (which is the main thing you can do with >50%).

Variance in block finding times is unwanted, but I think most will agree it pales in comparison to the other issues involved. Especially since there are basically two relevant timescales - "instant" (0 confirmations) and "not instant". The time for 10 confirmations follows Erlang(10) distribution which has less variance.

By all means you should pursue whatever research question interests you, but I expect you'll be disappointed both in finding a solution satisfying your requirements, and in its potential usefulness.

I think you're confused about how the so-called "Bitcoin lottery" works. You seem to think that if I have some system and you have a parallel system with x100 the power, then you will find all the blocks and I will find none, because you'll always beat me to the punch. But no, these are independent Poisson processes (tied only via occasional difficulty adjustments) with different rates, meaning that you will simply find 100 times the blocks I will. So over a period where 1010 blocks were found between us, about 1000 will be yours and 10 will be mine.

In other words, it scales linearly - the amount you get out is exactly proportional to what you put in.

If that's all you're after, mission is already accomplished.

But if you think your "non-parallelizable PoW" system should behave differently, let's say that in this system a person with a computer finds one block per month. Then four people with a computer each should find a total of 4 blocks per month, right?. So a person with 4 computers also finds 4 blocks per month, because the system can't know who the computers belong to (and if it can then it's not at all about a different computational problem, but about using non-computational cues in distributing blocks). So a person with a special 4-CPU system also finds 4 blocks, as does a person with a quad-core CPU.


And, once more - pools are not a security threat if implemented correctly. There's no reason the pooling mediator also has to generate the work. And, there are already peer-to-peer pools such as p2pool.


Edit: Parallelism means that an at-home miner can plug in his computer and contribute to security/receive rewards exactly in proportion to what he put in. Non-parallelism means his effect will depend in complicated ways on what others are doing and usually leave the poor person at a significant disadvantage (since others are using faster computers), which is the opposite of what you want.

Block finding follows a Poisson process, which means that the time to find a block follows the exponential distribution (where the variance is the square of the mean). The variance is high, but that's an inevitable consequence of the fair linearly scaling process.

If it pleases you, the variance of block finding times will probably be less in the transaction fees era.

I think the value in translating a technical paper is fairly limited, those who want technical details would typically have no problem (and possibly prefer) reading the English original. A better thing to have in multiple languages is a paper giving a thorough, reasoned discussion about all of Bitcoin's advantages (preferably tailored to what's relevant for each specific country).

Anyway, how well does the platform handle right-to-left languages? Can you generate a pdf sample for the work done so far in Hebrew?

Satoshi understands probability so he clearly expected pools to emerge. It's likely though he didn't think they need any special consideration in the design.

No, as I explained, the miner doesn't need to get a new header when there's a new transaction. He just keeps mining on a header which doesn't include all the new transactions. When he finishes 4GH he gets a new header with all the recent transactions. That's how it's done right now, it's not a potential future optimization.

What DeathAndTaxes said, the Merkle root is the "executive summary" of the transactions. And, inclusion of transactions in the block is on a "best effort" basis - everyone chooses which transactions to include, and currently most miners/pools include all transactions they know. But it's ok if a miner is missing a few recent transactions, he'll get (a header corresponding to) them in the next getwork.

Probably. Carry on then .

Maybe not in this thread, but people have been seriously suggesting that Bitcoin proof-of-work should be based on external distributed computing projects.

Mining pools. The miner only needs the block headers.