DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?)

[Come-from-Beyond]

No, I don't see this as an excuse - in fact, I am writing a white paper at the moment which has parallels to Tangle, but it has a mining subsidy and I want to be sure that I've covered all the angles, so the fact you chose to disallow it is important to me.

Is it possible to see the draft? I wanted subsidy because 2% annual inflation is believed to be good for a monetary system. If Iota community doesn't mind we could delay the release for a week to add the inflation...

[monsterer]

No, I don't see this as an excuse - in fact, I am writing a white paper at the moment which has parallels to Tangle, but it has a mining subsidy and I want to be sure that I've covered all the angles, so the fact you chose to disallow it is important to me.

Is it possible to see the draft? I wanted subsidy because 2% annual inflation is believed to be good for a monetary system. If Iota community doesn't mind we could delay the release for a week to add the inflation...

It's very rough in its current state, I'm not sure I'm ready to release a draft yet. I can say, however, that this design has a deterministic ordering, pays a subsidy for every block, and also rewards participation on the longest chain (of branches) of difficulty.

edit: I am completely happy for you to PM me or to discuss the finer points of how this is supposed to work here, because attack vectors are hard to enumerate fully.

[Come-from-Beyond]

this design has a deterministic ordering

But how?

[monsterer]

this design has a deterministic ordering

But how?

From the paper:

Ordering transactions deterministically is key to Tree of work. Transactions are ordered from the genesis transaction to the head transaction with the highest cumulative difficulty score; this is analogous to the LCR in bitcoin. The ordering works by following the dependency relationships created by the parent and uncle references. Specifically both parent and uncle transactions must be included in the ordering before the transaction that referenced them. The algorithm recursively orders parent transactions, then uncle transactions at every node in the tree.

Code:

def order_from(early_node, late_node, carry=None):
       carry = [] if carry is None else carry
       if early_node == late_node:
           return [late_node]
       if late_node.parent_hash == 0:
           raise Exception('Root block encountered unexpectedly while ordering graph')
       main_path = exclude_from(Graph.order_from(early_node, late_node.parent), carry)
       aux_path = exclude_from(Graph.order_from(early_node, late_node.uncle), carry + main_path) if late_node.uncle is not None else []
       return main_path + aux_path + [late_node]

[Come-from-Beyond]

It doesn't look as a DAG. I saw "tree" mentioned.

EDIT: Take the picture from Wiki and do your ordering, please.

[monsterer]

It doesn't look as a DAG. I saw "tree" mentioned.

EDIT: Take the picture from Wiki and do your ordering, please.

The number of parents in a given transaction is limited to 2, so I cannot order this example... although I thought that was also true of Tangle?

[Come-from-Beyond]

The number of parents in a given transaction is limited to 2, so I cannot order this example... although I thought that was also true of Tangle?

Tangle doesn't claim it can order them, it survives in these conditions by sacrificing ability to subsidize.

[monsterer]

The number of parents in a given transaction is limited to 2, so I cannot order this example... although I thought that was also true of Tangle?

Tangle doesn't claim it can order them, it survives in these conditions by sacrificing ability to subsidize.

Does it allow more than two parents?

edit: I think if you were willing to give the DAG a little more structure, such that you have a main parent and single optional uncle, you would be able to have a deterministic ordering, but this may be too much work to change now.

[Come-from-Beyond]

Does it allow more than two parents?

edit: I think if you were willing to give the DAG a little more structure, such that you have a main parent and single optional uncle, you would be able to have a deterministic ordering, but this may be too much work to change now.

A lot of parents are allowed. We can't say who is parent and who is uncle because nodes don't see the same picture.

[monsterer]

A lot of parents are allowed. We can't say who is parent and who is uncle because nodes don't see the same picture.

Specifically, this is what stops your example from being ordered deterministically:



Node 3 is violating the parent condition by referencing node 8 as a parent, but they are in fact, siblings.

[Come-from-Beyond]

Specifically, this is what stops your example from being ordered deterministically:



Node 3 is violating the parent condition by referencing node 8 as a parent, but they are in fact, siblings.

Will your design stop working if we assume that network nodes don't see all the graph nodes?

[monsterer]

Specifically, this is what stops your example from being ordered deterministically:



Node 3 is violating the parent condition by referencing node 8 as a parent, but they are in fact, siblings.

Will your design stop working if we assume that network nodes don't see all the graph nodes?

I don't think so - as long as both parents are provably in the hierarchy at a lower 'height' than each new transaction which gets added, there shouldn't be a problem.

edit: so, new transactions depend on the entire tree below them being present, otherwise it's not possible to determine the ancestor relationship correctly. This is akin to blockchain syncing - you cannot add a block if the parent doesn't exist yet.

another edit: I cannot take credit for this design either, it is someone else's; I am just putting together a description of how it works, which turned into a white paper

[Come-from-Beyond]

I don't think so - as long as both parents are provably in the hierarchy at a lower 'height' than each new transaction which gets added, there shouldn't be a problem.

edit: so, new transactions depend on the entire tree below them being present, otherwise it's not possible to determine the ancestor relationship correctly. This is akin to blockchain syncing - you cannot add a block if the parent doesn't exist yet.

another edit: I cannot take credit for this design either, it is someone else's; I am just putting together a description of how it works, which turned into a white paper

Well, with subsidy it's more profitable to keep DAG very wide, wider DAG = less secure DAG. Without reading the whole paper I don't see why miners will behave as you expect them to behave. It's similar to Selfish Mining problem.

[monsterer]

Well, with subsidy it's more profitable to keep DAG very wide, wider DAG = less secure DAG. Without reading the whole paper I don't see why miners will behave as you expect them to behave. It's similar to Selfish Mining problem.

Why do you say that? For example, if you paid a fixed reward for every transaction, why would it be more profitable to widen the DAG instead of create one long chain?

[Come-from-Beyond]

Why do you say that? For example, if you paid a fixed reward for every transaction, why would it be more profitable to widen the DAG instead of create one long chain?

I'm talking about subsidy of 25 BTC per block. It's more profitable to cancel someone's blocks reducing effective hashrate of the system.

[monsterer]

Why do you say that? For example, if you paid a fixed reward for every transaction, why would it be more profitable to widen the DAG instead of create one long chain?

I'm talking about subsidy of 25 BTC per block. It's more profitable to cancel someone's blocks reducing effective hashrate of the system.

Are we talking about bitcoin now, or Tangle, I'm confused? 

[Come-from-Beyond]

Are we talking about bitcoin now, or Tangle, I'm confused? 

Of Tangle/DAG with subsidy.

[monsterer]

Are we talking about bitcoin now, or Tangle, I'm confused?  

Of Tangle/DAG with subsidy.

Ok, so, if you pay a fixed reward for every transaction except for orphans then it is more profitable overall for you to try and orphan the last transaction, because you put them out of business, correct?

edit: this is exactly how bitcoin works at the moment

[Come-from-Beyond]

Ok, so, if you pay a fixed reward for every transaction except for orphans then it is more profitable overall for you to try and orphan the last transaction, because you put them out of business, correct?

edit: this is exactly how bitcoin works at the moment

Bitcoin worked even when a single pool controlled 51%+ of hashing power. Anecdotal case proves nothing.

I won't post a wall of text about Nash equilibrium, we already derailed the thread too much.

[monsterer]

I won't post a wall of text about Nash equilibrium, we already derailed the thread too much.

Agreed - I've created a separate thread to discuss this further, if you are interested: https://bitcointalk.org/index.php?topic=1358760.0