Indeed - and there was no empirical data presented to "justify" the penalty (or whatever we call it - the *name* of it is not an issue to me - so call it "a rose" but I still think it is a kludge and I am not convinced it will help with the security of the network).


The issue I am referring to is perhaps best illustrated like this:

A1 - B
A2 - B
A1 - C
A2 - D

So assuming that A1 and A2 have the "same weight" then B here is trying to keep both A1 and A2 branches going whilst C and D have each only built on the 1 branch.

Now here is a possible next step:

A1 - B
A2 - B - E
A1 - C
A2 - D - F

Here E and F have separately chosen A2 - B and A2 - D as being "their first choice" and only built upon those (being non-malicious nodes).

So now B's attempt to continue the A1 branch has failed (that fork will likely die now) simply because E did not try to forge 2 blocks at the same height.

Now if we were instead to use the "penalty" approach then in fact we would instead have this result:

A1 - B - E
A2 - B - E
A1 - C - F
A2 - D - F

As both E and F know they are going to get penalised by one or other branch they will forge on both branches causing the branching to continue.

I hope this helps clarify what I am seeing and why I think the idea of "only forging the 1 block at the one height" is a better approach (sure people can "cheat" but as shown provided those cheating are in the minority the effect is greatly reduced).

I don't think that it requires any *changes* to the Bitcoin protocol to achieve (although you can't broadcast the refund txs *in advance* as I am pretty sure they won't get included in each node's "memory pool" but that is no big deal).

Basically *no-one has tried it* (or if they have they haven't published this to my knowledge).

My guess is that from the Bitcoin perspective it would "help" alts (so no incentive for the core devs to even bother to try it) and from the alt coin side they simply don't have any devs *capable* of doing this (as generally they are just "copy-pasta devs").

Yes - you are correct (it has been something I've been thinking about).

You always have the potential for forks (Bitcoin regularly has 2 different blocks with the same height although has rarely gone much further than that apart from when we had the DB change issue).

The resolution of a fork is when others "build new blocks upon what they see as the best chain".

The problem with a nefarious player is that they might be trying to "build a secret chain" in the background.

If it were possible for them to do so then it could easily be accepted as the "new chain" by all nodes *but* with the rule that an equal weight chain will be ignored unless it was the *first* one that the node sees will just make that attack *harder* (as other nodes will prefer to build upon the non-secret chain assuming weights are equal).

The tx uses Bitcoin "script" to check the hash of a value (so you *leave out the value*).

In reality it's a little more complicated because you need refund txs (with timeouts) but basically the whole point is that the 1st tx can't happen *without disclosing the number that was hashed* (which is all that the 2nd tx needs to become valid).

*Yes* it is the "secret sauce" to making a completely decentralised crypto to crypto exchange possible.

Assuming you have done an internet search but still not *understood* it then let me try and illustrate:

Step 1) I create a tx with a "secret" number (that you don't know) and give that tx to you (instead of the secret number there is a *hash* of it).

Step 2) You create a tx that will need the same secret number (due to needing the same hash) and give it back to me.

Step 3) In order for me to *get* your coins I have to *use* that secret number (and it is basically *impossible* to find another secret that has the same hash).

Step 4) As you can now *see* the secret you can complete your tx without fail.

This is a simplified description (use the internet to find the full description) but is perhaps an "easier read".

Without a doubt if we can achieve atomic cross-chain txs then we will have basically got rid of the business model for all exchanges that don't do fiat.

IMO "this is our job".

The future will not be centralised!

*Yes* but it is not simple, nor quick and I don't believe that anyone has actually even done it.

Also it can't apply to Nxt itself until we have AT (as we don't have the equivalent of Bitcoin "script" until then).

No-one - that is why atomic-cross chain transactions are the only *real solution* here (people trusted Gox and look where that has got them now).

For those interested in the Bitcoin *bug* that would occur in 2140 assuming it isn't fixed before then.

The relevant code from Bitcoin (in main.cpp):


A simplified program to show you what happens:


So if not fixed then Bitcoin isn't limited to 21M Bitcoins at all.

I'm afraid that I fail to see it (and posting the same stuff *again* and *again* is not productive - I am basically not even reading it now - it has become *spam* in my mind).

Again - the changes being proposed are for security not fairness (you are not focusing on the right thing).

Please do.


I did not as the attempts to model this in my simulator all came out with "disastrous" results (which are likely just due to the simulator so would not be of any value at all).


Frequent forks are *expected* to occur in a system with (compared to Bitcoin) fast confirmation times (BCNext said that in his introductory post).

By "fragmenting" the forks all over the place it will actually reduce the effectiveness of such attacks.

Actually it's not the simplest and it is far from certain that is even a solution (all attempts to even "simulate" it have failed to show any benefit at all so far).


New nodes will get their information from their peers (so whichever peer they got a branch from first is the one they will stick to in case of another equal weight branch appearing).

True - and presumably you should also be able to choose from 1 of x such 3 server gateways.

Addressing how TF will be implemented should be focused on protecting the blockchain (#1) and the network (#2).

Issues of "fairness" (perceived or otherwise) are at best a #3 priority (if even that).

AMs are not intended to hang around forever anyway (they are expected to be removed when a pruning occurs) so I don't see that as being an issue.

The point is that layers on top of the basic Nxt platform will need to use AMs (especially things like ATs) so we need to make it easier for "clients" to know how to handle different "message types".

I have been advocating for the latter (and for scrapping the idea of the former) and CfB came up with a great idea to stop the effectiveness of forgers trying to extend multiple chains of equal weight (each client will only build on the 1st chain of equal height that they see).

Understand that the *best* way to protect the blockchain is always going to be having forging power divided up into roughly equal smaller pieces (whether or not the software tries to enforce that or not).

Now that I've thought about it a bit further I think I would actually prefer that we have a fixed prefix (say 16/32/64 bit) that indicates a message type with type #0 being raw data, type #1 being UTF-8 text and type #3 being URI (and maybe we could consider using the alias system to effectively map each of these type numbers to an internet media type http://www.iana.org/assignments/media-types/media-types.xhtml).

Although it's a little ugly I've realised that otherwise ATs are going to require far more complicated code (and we don't want to force that).

(that should make James happy I think)