IOTA

[stdset]

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.

My picture contains as low amount of transaction as possible, just to express the idea. You can imagine several more transactions of the honest network on top of the green tip, but many more red transactions above the second doublespend.

[Sebastien256]

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.

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

I agree that it would be nicer to do something else than an ico.
CFB, I see you did not come up with a better idea. In the recent past, if im not mistaken, you were looking at a way to distribution to unique user. Why not pay a third party to do this verification process?

[Come-from-Beyond]

My picture contains as low amount of transaction as possible, just to express the idea. You can imagine several more transactions of the honest network on top of the green tip, but many more red transactions above the second doublespend.

Your picture is very unprobable in this case, odds that other transactions (legit ones) don't reference legit payment after the adaptation period is over are near zero.

[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.

My picture contains as low amount of transaction as possible, just to express the idea. You can imagine several more transactions of the honest network on top of the green tip, but many more red transactions above the second doublespend.

Our point is that normally the left yellow tx would be referenced e.g. already by the second green tx.

[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?

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.

But that default doesn't seem to be the correct game theory? This is Prisoner's Dilemma game. Afaics, lower incentive to go first on including a new tip. Just noticed yesterday this research on cases where the pessimistic Nash equilibrium is claimed not to hold (but on quick glance I ponder if they have overly simplistic assumptions in their models).

Obviously if everyone defects to making their own branches (maximally broaden the tree), then no one's tips get lengthened and thus the entire system doesn't function. But is the optimum strategy the default that you assume?

[Come-from-Beyond]

I agree that it would be nicer to do something else than an ico.
CFB, I see you did not come up with a better idea. In the recent past, if im not mistaken, you were looking at a way to distribution to unique user. Why not pay a third party to do this verification process?

No a better idea. It's impossible to prove that we don't buy our own coins, if we kept some coins as premine we still could buy extra coins, so we put ourselves into the most unprofitable position to lessen advantage of our position to the max degree.

[stdset]

Our point is that normally the left yellow tx would be referenced e.g. already by the second green tx.

The attacker doesn't publish it untill he has enough transactions referencing the second doublespending transaction.

[Sebastien256]

I agree that it would be nicer to do something else than an ico.
CFB, I see you did not come up with a better idea. In the recent past, if im not mistaken, you were looking at a way to distribution to unique user. Why not pay a third party to do this verification process?

No a better idea. It's impossible to prove that we don't buy our own coins, if we kept some coins as premine we still could buy extra coins, so we put ourselves into the most unprofitable position to lessen advantage of our position to the max degree.

There are way to validate unique user, it only required a trustable third party.

[smooth]

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

We know that mining can't be used here because CfB has stated that it undermines the security model.

If the idea is bootstrapping the distribution and not raising money, then spin off from an existing coin, preferably a widely used one. Multiple coins are even okay but make sure the weighting bears some sane relationship with fair market value (does not have to be exact).

If the idea is raising money while unambiguously complying with all the (perhaps mutually contradictory) laws in the world while at the same time using a structure that achieves a widespread distribution in practice, and is verifiably resistant to cheating, well good luck. I don't know how to do that either.

[Come-from-Beyond]

We know that mining can't be used here because CfB has stated that it undermines the security model.

If the idea is bootstrapping the distribution and not raising money, then spin off from an existing coin, preferably a widely used one. Multiple coins are even okay but make sure the weighting bears some sane relationship with fair market value (does not have to be exact).

If the idea is raising money while unambiguously complying with all the (perhaps mutually contradictory) laws in the world while at the same time using a structure that is achieves a widespread distribution in practice, and is verifiably resistant to cheating, well good luck. I don't know how to do that either.

The idea is to raise money for hardware supporting Iota.

[Come-from-Beyond]

The attacker doesn't publish it untill he has enough transactions referencing the second doublespending transaction.

The second doublespending won't be referenced because the longest tip already contains the legit transaction.

[stdset]

The second doublespending won't be referenced because the longest tip already contains the legit transaction.

That's why the transaction which references both the legit subtangle and the second doublespend is red on my picture.

[TPTB_need_war]

I agree that it would be nicer to do something else than an ico.
CFB, I see you did not come up with a better idea. In the recent past, if im not mistaken, you were looking at a way to distribution to unique user. Why not pay a third party to do this verification process?

No a better idea. It's impossible to prove that we don't buy our own coins, if we kept some coins as premine we still could buy extra coins, so we put ourselves into the most unprofitable position to lessen advantage of our position to the max degree.

Sorry I don't follow this logic. Can you unpack that and make it more clear? I don't see any way around what I wrote.

[mthcl]

Our point is that normally the left yellow tx would be referenced e.g. already by the second green tx.

The attacker doesn't publish it untill he has enough transactions referencing the second doublespending transaction.

Then why the merchant would accept it?

[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.

But that default doesn't seem to be the correct game theory? This is Prisoner's Dilemma game. Afaics, lower incentive to go first on including a new tip. Just noticed yesterday this research on cases where the pessimistic Nash equilibrium is claimed not to hold (but on quick glance I ponder if they have overly simplistic assumptions in their models).

Obviously if everyone defects to making their own branches (maximally broaden the tree), then no one's tips get lengthened and thus the entire system doesn't function. But is the optimum strategy the default that you assume?

We assume that the node knows that most nodes will behave well, and so it's obliged to behave well too.

[stdset]

Then why the merchant would accept it?

It is released and confirmed. If necessary the attacker himself provides the first confirmation, which connects it to a recent tip. The transaction looks legit.

[mthcl]

Then why the merchant would accept it?

It is released and confirmed. If necessary the attacker himself provides the first confirmation, which connects it to a recent tip. The transaction looks legit.

But the cumulative weight of that tx is not so big, so why the merchant should accept it?

[iotatoken]

In short: yes we could take up loans by people to buy up IOTA token. There are plenty of these opportunities if one wants to and this would not change if we had premine either, it would just give us even more IOTA.

As for verification process: there is no way to beat sybil, there would be numerous ways to fool this third party too. We could just pay some random people to buy coins via their IDs and then send them to us.

We wont cheat the system, it would be a detriment to IOTA and thus a larger detriment to ourselves than the profit we could get out of manipulating the ICO. This boils down to how inclined you are to believe in conspiracy theories. Fortunately participating in ICO is 100% voluntary.

[mthcl]

The attacker doesn't publish it untill he has enough transactions referencing the second doublespending transaction.

The second doublespending won't be referenced because the longest tip already contains the legit transaction.

Anyhow, we are discussing now with CfB ways to define better referral algorithms, which would permit to fence off such attacks in a more efficient way.

[stdset]

But the cumulative weight of that tx is not so big, so why the merchant should accept it?

NP, the merchant waits of course for normal amount of confirmations.