Mining subsidy in a DAG

[Come-from-Beyond]

Any other cases I missed?

[Doublespending #1] -- {A} -- {B} -- {C} -- {D} -- ...
[Doublespending #2] -- {N} -- {O} -- {P} -- {Q] -- ...

If others add E, F, G then the hacker adds R, S, T.
If others add R, S, T then the hacker adds E, F, G.

[monsterer]

Any other cases I missed?

[Doublespending #1] -- {A} -- {B} -- {C} -- {D} -- ...
[Doublespending #2] -- {N} -- {O} -- {P} -- {Q] -- ...

If others add E, F, G then the hacker adds R, S, T.
If others add R, S, T then the hacker adds E, F, G.

The attacker must have more power than the rest of the network to pull this off?

[Come-from-Beyond]

The attacker must have more power than the rest of the network to pull this off?

No, the attacker must have less power than guys extending the other branch. There can be more than 2 branches and someone can extend attacker's branch too (because they don't see the other branch). In high-load regime with 10 near-equal branches 5% should be enough for that attack.

[monsterer]

The attacker must have more power than the rest of the network to pull this off?

No, the attacker must have less power than guys extending the other branch. There can be more than 2 branches and someone can extend attacker's branch too (because they don't see the other branch). In high-load regime with 10 near-equal branches 5% should be enough for that attack.

I agree this could be possible. It seems you need an incentive for users to merge branches, such that the effect of this kind of partitioning is minimised.

edit: etherium pays an additional subsidy to miners who merge branches, that could be one way to approach the problem.

[Come-from-Beyond]

I agree this could be possible. It seems you need an incentive for users to merge branches, such that the effect of this kind of partitioning is minimised.

edit: etherium pays an additional subsidy to miners who merge branches, that could be one way to approach the problem.

Merging of branches that contain doublespendings creates this problem. Getting rid of the problem instead of creating it and trying to solve (and it's not clear that paying more solves it) leads to a better design.

[monsterer]

I agree this could be possible. It seems you need an incentive for users to merge branches, such that the effect of this kind of partitioning is minimised.

edit: etherium pays an additional subsidy to miners who merge branches, that could be one way to approach the problem.

Merging of branches that contain doublespendings creates this problem. Getting rid of the problem instead of creating it and trying to solve (and it's not clear that paying more solves it) leads to a better design.

Merging of double spends fixes the problem because it forces the end of the partition (I've added confirmation scores to the transactions):

[Doublespending #1] -- {A₃} -- {B₂} -- {C₁} -- {D₀} -- ...
[Doublespending #2] -- {N₃} -- {O₂} -- {P₁} -- {Q₀} -- ...

after merge:

[Doublespending #1] -- {A₅} -- {B₄} -- {C₃} -- {D₂} -- ...
                                                                              -- {E₁} -- -- {F₀} --
[Doublespending #2] -- {N₃} -- {O₄} -- {P₃} -- {Q₂} -- ...

[Come-from-Beyond]

Merging of double spends fixes the problem because it forces the end of the partition (I've added confirmation scores to the transactions):

[Doublespending #1] -- {A₃} -- {B₂} -- {C₁} -- {D₀} -- ...
[Doublespending #2] -- {N₃} -- {O₂} -- {P₁} -- {Q₀} -- ...

after merge:

[Doublespending #1] -- {A₅} -- {B₄} -- {C₃} -- {D₂} -- ...
                                                                              -- {E₁} -- -- {F₀} --
[Doublespending #2] -- {N₃} -- {O₄} -- {P₃} -- {Q₂} -- ...

The score of #1 or #2 can be changed by attaching a transaction to any of A, B, C, D, N, O, P or Q even if E and F are already here. And if #1 starts winning the hacker will promote #2 and vice versa. Don't see how E and F fix the problem.

PS: Note that tie-breaker rule is not applied if difference between the scores of #1 and #2 is big enough, and the hacker can swing the balance from one to another indefinitely.

[monsterer]

The score of #1 or #2 can be changed by attaching a transaction to any of A, B, C, D, N, O, P or Q even if E and F are already here. And if #1 starts winning the hacker will promote #2 and vice versa. Don't see how E and F fix the problem.

PS: Note that tie-breaker rule is not applied if difference between the scores of #1 and #2 is big enough, and the hacker can swing the balance from one to another indefinitely.

You're completely correct. Thinking about it some more, this is a significant problem with DagCoin; and it wouldn't be a problem except for double spends, because the completely arbitrary transaction ordering only falls over in the face of double spends, which is presumably why Tangle chose to orphan branches.

There is a way around this problem, but it requires a more structured DAG and a deterministic transaction ordering.

[Come-from-Beyond]

...and a deterministic transaction ordering.

Looking forward to reading your paper on this matter...

[fbueller]

Out of the talks at Hong Kong, I enjoyed this video as an intro to DAG. https://www.youtube.com/watch?v=fst1IK_mrng&feature=youtu.be&t=2h17m20s

[monsterer]

Out of the talks at Hong Kong, I enjoyed this video as an intro to DAG. https://www.youtube.com/watch?v=fst1IK_mrng&feature=youtu.be&t=2h17m20s

That's actually a really good talk - do you know where I can get the slides?

edit: got it: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/2_breaking_the_chain_1_mcelrath.pdf

[TPTB_need_war]

Only if the merchant doesn't wait long enough, surely? At least this way, the ambiguity is removed.

How is it removed if the both are included into DAG and doublespending may eventually get more PoW? Even a year later.

This is from the DagCoin paper:



I've circled the tiebreaker rule, which for example, might use lowest txid. The only way for what you described to happen, is if that entire branch never gets extended, isn't it? Because if it continues getting extended, you can see the double spend doesn't get confirmed, but the legit transaction does?

Btw, you might want to reference the post I made within the past month or so (probably in my Decentralized thread in Altcoin Discussion) wherein I pointed out that Sergio had an egregious error in his conceptualization on that diagram.

...and a deterministic transaction ordering.

Looking forward to reading your paper on this matter...

Can't be done because of what I wrote upthread:

The simple answer is that without a longest chain rule there is no synchrony in distributed systems, thus there is no possibility that there won't be multiple branches (partitions) that can't converge (due to double-spends). This is also why monsterer's tree design can't function without blocks (and I had explained this to him in the Decentralization thread[1] but he is hard-headed).

[...]

[1]	https://bitcointalk.org/index.php?topic=1319681.msg13530099#msg13530099 https://bitcointalk.org/index.php?topic=1319681.msg13530264#msg13530264 https://bitcointalk.org/index.php?topic=1319681.msg13632887#msg13632887

[monsterer]

Btw, you might want to reference the post I made within the past month or so (probably in my Decentralized thread in Altcoin Discussion) wherein I pointed out that Sergio had an egregious error in his conceptualization on that diagram.

I'm not sure what post you refer to. The critical error, as I see it, is that you can change the weighting on historical transactions, which affects contemporary transactions.

[Come-from-Beyond]

Can't be done because of what I wrote upthread:

Well, my current knowledge lets me guess that you are right, but what if monsterer has done a break-through in distributed systems...

[monsterer]

Can't be done because of what I wrote upthread:

Well, my current knowledge lets me guess that you are right, but what if monsterer has done a break-through in distributed systems...

What I'm looking at currently, is the incentive to merge branches. The rational behavior for a participant in lieu of an incentive is not to merge branches. That has dire consequences for the consensus of the chain. DagCoin's proposed incentives don't work either - how does Iota solve the problem?

[Come-from-Beyond]

What I'm looking at currently, is the incentive to merge branches. The rational behavior for a participant in lieu of an incentive is not to merge branches. That has dire consequences for the consensus of the chain. DagCoin's proposed incentives don't work either - how does Iota solve the problem?

More branches you merge - higher chance that someone approves your transaction.

[monsterer]

What I'm looking at currently, is the incentive to merge branches. The rational behavior for a participant in lieu of an incentive is not to merge branches. That has dire consequences for the consensus of the chain. DagCoin's proposed incentives don't work either - how does Iota solve the problem?

More branches you merge - higher chance that someone approves your transaction.

Except in the case of double spends, where the more branches you merge, the lower the chance that your transaction gets approved?

[Come-from-Beyond]

Except in the case of double spends, where the more branches you merge, the lower the chance that your transaction gets approved?

In this case you ignore a doublespending and use the previous transaction.

[monsterer]

Except in the case of double spends, where the more branches you merge, the lower the chance that your transaction gets approved?

In this case you ignore a doublespending and use the previous transaction.

But what about your example earlier? Temporary partitions caused by network latency mean a double spend is not necessarily visible as such to any given payer.

[Come-from-Beyond]

But what about your example earlier? Temporary partitions caused by network latency mean a double spend is not necessarily visible as such to any given payer.

Eventually one of the transactions will win.