IOTA

[mthcl]

If the attacker started to create his double-spending subtangle long time ago, then the initial tx's of this subtangle reference some rather old tx's, with not-so-big cumulative weight. While the attacker waits, the cumulative weight of the legit tangle continues to grow, so he won't be able to catch up.

Of course, this assumes that the attacker's max possible tx's rate is much less then the "usual" tx's rate of the rest of the network.

The first (legit) transaction references the same old transactions as the doublespend. The attacker doesn't need to compete with the rest of network.

OK, but the legit tx quickly starts to accumulate weight (as the honest nodes reference it, directly or indirectly), so, by the time the merchant accepts it, most of the tips of the legit tangle are already referencing it.  Even if the attacker publishes his subtangle at that moment, why the honest guys would reference it? The tips from the attacker's subtangle have smaller cumulative weight, and, in the event a honest guy tries to reference a legit tip and the attacker's tip, he'll detect the contradiction and won't do it. Therefore, the attacker's subtangle will be abandoned.

[1713910778]

1713910778

[1713910778]

1713910778

[1713910778]

1713910778

[tromp]

in the event a honest guy tries to reference a legit tip and the attacker's tip, he'll detect the contradiction and won't do it. Therefore, the attacker's subtangle will be abandoned.

This requires not just an honest guy, but a diligent one as well.
The risk is that honest guys will be lazy and rely on others to go far back in history to check all tx for double spending.

Even in bitcoin we've seen some miners being too lazy to do full node checking and instead relying on SPV, and thus risk building on top of invalid blocks.

[Come-from-Beyond]

Even in bitcoin we've seen some miners being too lazy to do full node checking and instead relying on SPV, and thus risk building on top of invalid blocks.

This reminded me that miners are that lazy that don't even do double-spends when control 51% of hashing power (Deepbit).

[stdset]

The algorithm for choosing the tips to reference "prefers" tips with larger cumulative weight. Those precomputed legit transactions will have much smaller cumulative weight (than other tips), and so they will probably not be referenced by others.

Isn't there are problem with merger of a split tangle then. If the network was split, then tips of the stronger part will have greater cumulative weight and will always be chosen to be referenced. The weaker subtangle just dies off.

[mthcl]

in the event a honest guy tries to reference a legit tip and the attacker's tip, he'll detect the contradiction and won't do it. Therefore, the attacker's subtangle will be abandoned.

This requires not just an honest guy, but a diligent one as well.
The risk is that honest guys will be lazy and rely on others to go far back in history to check all tx for double spending.

The lazy guys risk that their tx's will be abandoned, because the majority of the nodes won't reference them.

[mthcl]

The algorithm for choosing the tips to reference "prefers" tips with larger cumulative weight. Those precomputed legit transactions will have much smaller cumulative weight (than other tips), and so they will probably not be referenced by others.

Isn't there are problem with merger of a split tangle then. If the network was split, then tips of the stronger part will have greater cumulative weight and will always be chosen to be referenced. The weaker subtangle just dies off.

The party which is interested in the survival of the weaker subtangle would "connect" it to the stronger subtangle by referencing 1 tx from here and 1 from there. If both subtangles are legit, they'll quickly merge.

[Come-from-Beyond]

Isn't there are problem with merger of a split tangle then.

Maybe, I'm just not sure what you mean.

Is here our scenario:



Black squares are double-spends. Green ones - legit tangle, red - non-legit. Legit tip has score 11, attacker's tip has score 10.

[myagui]

So transaction security is actually reliant on the subsequent transaction volume for the overall network?
I imagine that the picture above would look quite different if the attacker simply chooses to mount his attack during a period of negligible transaction volume (thus low weight build-up on the legitimate tangle). I'm probably missing something (or a lot)...

[Come-from-Beyond]

So transaction security is actually reliant on the subsequent transaction volume for the overall network?
I imagine that the picture above would look quite different if the attacker simply chooses to mount his attack during a period of negligible transaction volume (thus low weight build-up on the legitimate tangle). I'm probably missing something (or a lot)...

Yes, we assume that there is a constant flow of transactions. If it's not the case (for example, tangle runs in North Korea where noone spends money during night time) then merchants should rise confirmation threshold during such hours.

[TPTB_need_war]

in the event a honest guy tries to reference a legit tip and the attacker's tip, he'll detect the contradiction and won't do it. Therefore, the attacker's subtangle will be abandoned.

This requires not just an honest guy, but a diligent one as well.
The risk is that honest guys will be lazy and rely on others to go far back in history to check all tx for double spending.

The lazy guys risk that their tx's will be abandoned, because the majority of the nodes won't reference them.

That is precisely how I would have answered. It is quite clear that everyone has a strong incentive to be on a correct branch, else any time down stream someone can broadcast a notice that a branch is incongruent then that branch gets abandoned.

But doesn't this mean that there is a great incentive to not include tips in your branch, because these don't yet have enough veracity to be sure they won't end up being a double-spend. In your system there is often no way to prove which of the double-spends were first, so they both are invalid.

Seems to me no one has an incentive to lengthen instead of broaden the tree. But I haven't absorbed the white paper. Did you address that?

[crazywack]

Awesome a real project, good luck to you and will follow closely.

[mthcl]

in the event a honest guy tries to reference a legit tip and the attacker's tip, he'll detect the contradiction and won't do it. Therefore, the attacker's subtangle will be abandoned.

This requires not just an honest guy, but a diligent one as well.
The risk is that honest guys will be lazy and rely on others to go far back in history to check all tx for double spending.

The lazy guys risk that their tx's will be abandoned, because the majority of the nodes won't reference them.

That is precisely how I would have answered. It is quite clear that everyone has a strong incentive to be on a correct branch, else any time down stream someone can broadcast a notice that a branch is incongruent then that branch gets abandoned.

But doesn't this mean that there is a great incentive to not include tips in your branch, because these don't yet have enough veracity to be sure they won't end up being a double-spend. In your system there is often no way to prove which of the double-spends were first, so they both are invalid.

Seems to me no one has an incentive to lengthen instead of broaden the tree. But I haven't absorbed the white paper. Did you address that?

Yes. As mentioned somewhere above on this page (or maybe on the previous one), the (default) referencing algorithm works in such a way that it prefers tips with bigger height. So, if you're too lazy and reference some very old tx's, you take the risk that your tx won't be referenced by others.

[Come-from-Beyond]

In your system there is often no way to prove which of the double-spends were first, so they both are invalid.

If we can provide deterministic way to order double-spends then we can include both and ignore the younger one. It's not related to Iota though, just an idea.

[mthcl]

In your system there is often no way to prove which of the double-spends were first, so they both are invalid.

If we can provide deterministic way to order double-spends then we can include both and ignore the younger one. It's not related to Iota though, just an idea.

Anyhow, for that to happen, both double-spending tx's need to be broadcast more or less at the same time. Doesn't sound as a good idea for the attacker...

[tromp]

If we can provide deterministic way to order double-spends then we can include both and ignore the younger one. It's not related to Iota though, just an idea.

That puts undue stress on others. For instance, it no longer suffices for a merchant to see a payment confirmed by tons of PoW from followup tx.

She additionally needs to go all the way back in history to check for potential double-spends that change the status of the recent payment to "please ignore".

[Come-from-Beyond]

That puts undue stress on others. For instance, it no longer suffices for a merchant to see a payment confirmed by tons of PoW from followup tx.

She additionally needs to go all the way back in history to check for potential double-spends that change the status of the recent payment to "please ignore".

Valid point.

[stdset]

Maybe, I'm just not sure what you mean.

This is the scenario I'm talking about. Green filled, black edged are transactions of the honest network. Red edged - are transactions of the attacker. The doublespends are filled with yellow.
As far as I understand your algo, weight of the red tip is greater by 3 than weight of the green tip.

[TPTB_need_war]

0% of the coins go to the team. The team will be compensated via funds raised in the ICO, no pre-mine. We'll have to buy our tokens just like everyone else.

ie. we will have no reason to continue working on the coin as we will not be vested in it and have already received another currency we could cash out into FIAT

I have no problem understanding this concern, given the space that we're in (crypto is the wild wild wild west after all), but your assumption here is blatantly wrong. We chose 0% premine because that is what is the absolute most fair to every party involved. We are basing our entire start-up around IoT, which we've been working on in stealth for a year, as explained in OP this is what prompted us to develop IOTA. It is a necessary ingredient for the vision of IoT that our start-up is focused on. On top of this all of us will invest our personal funds into IOTA, so no we have a ton of incentive to make IOTA a success.

how is a 0% premine any more fair than you raising BTC and repaying yourself for the coins you "purchased"?  
either way you are receiving BTC and you are using BTC to buy said coins.  they're free coins for you...

It is more fair because it means it's entirely up for grabs to anyone. There is no coins arbitrarily set aside for the developers...

This is still a form of premine. You can convert all of you ICO funding to coins in any scenario while paying those funds to yourself. Since you can pay yourself numerous times, and recycle the funds to pay yourself again, there is no limit to the number of coins you can buy from yourself.

Even if you require all funds to be presented up front, that doesn't prevent you from taking out a loan which you can pay back fully because you buy the coins from yourself.

Even if you limit the supply of coins and force all offers to be tendered at once and randomly choose in a publicly verifiable process, you can still stack the bids to be sure you get the % of coins you want.

If you instead have a market driven price for the ICO and a fixed supply of coins, then you can bid on your own coins driving the price higher and generating more funds while obtaining some of the coins cheaper than others who have paid you to buy your coins cheaper.

The only way around this would be to verify the identify of every purchaser and make this information public (or audited by a trusted entity), which I doubt most purchasers would agree to.

The only solution I see for this dilemma is to identify each purchaser, but do it in a convenient and non-intrusive way. That is why I have been thinking to only sell up to say $500 to each user (no investors! so as to avoid creating an illegal unregistered investment security so you all don't all end up in jail in the future) and allowing these purchases only by credit card (or verified bank account funding via Paypal to avoid chargebacks) with an auditing process that insures each name on the card is unique. I suppose you are clever enough you can pay people to let you use their credit cards (or steal them), but this is a crime and probably easy to track down (especially during any SEC investigation), so it is very risky and one would assume legit developers won't risk crime (heck they are talented, and can earn a lot of money taking programming jobs outside of crypto).

The only other way is some mining distribution, but wastes resources that could be better used to fund development.

Or you can just tell everyone honestly that all they know is how many coins they have and the total supply of coins, but they can't know how many coins you have unless all the buyers get together and tally their purchases.

This a serious dilemma. I have thought about it a lot. Has anyone else devised a better solution?

[Come-from-Beyond]

This is the scenario I'm talking about. Green filled, black edged are transactions of the honest network. Red edged - are transactions of the attacker. The doublespends are filled with yellow.
As far as I understand your algo, weight of the red tip is greater by 3 than weight of the green tip.

Does this assume that the merchant waited for enough confirmations? Because his transaction seems to have very little confirmation.

[mthcl]

This is the scenario I'm talking about. Green filled, black edged are transactions of the honest network. Red edged - are transactions of the attacker. The doublespends are filled with yellow.
As far as I understand your algo, weight of the red tip is greater by 3 than weight of the green tip.

Does this assume that the merchant waited for enough confirmations? Because his transaction seems to have very little confirmation.

Yes, normally the left yellow tx would have been referenced by many green ones already.