Amount of tips is supposed to be small
This is not necessarily the case, in the heavy load regime. That could help to conduct a doublespend btw. A hacker accumulates a lot of PoW in legit small transactions forming huge amount of new tips, but doesn't broadcast them. Then he sends a legit transaction, waits for it to be confirmed, gets his purchase sent to him. Then he creates a doublespend (for example sends the same money back to himself) and floods the network with his precomputed legit transactions. So network hashpower now is spread over his tips and he needs much less hashpower to create enough transactions confirming his doublespend to overtake the first transaction. The algorithm for choosing the tips to reference "prefers" tips with larger height. Those precomputed legit transactions will have much smaller cumulative weight (than other tips), and so they will probably not be referenced by others. Correct me if I'm wrong, but what prevents the following attack?
A hacker creates two transactions, one of them will be a legit transaction, used to purchase something, another is a doublespend. Then the hacker invests a lot of PoW in confirming the second transaction. In order to do that he just creates a lot of transactions sending money between his addresses, all his trnsactions refer directly or indirectly the doublespend, so his doublespend gets huge confirmation score. Then he broadcasts the first transaction, and when it gets confirmed he broadcasts the whole doublespend branch.
Do I miss something?
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. |
|
|
|
Amount of tips is supposed to be small
This is not necessarily the case, in the heavy load regime. |
|
|
|
Confirmation is not instant, as it can be in other designs such as Lightning Networks (and also my design). Yet it will also be much faster then Bitcoin's block period. You are probably estimating at a few seconds at most assuming attacker's power is sufficiently low?
Probably yes, should be matter of seconds (in the regime where there is a reasonable flow of tx's already). The attacker's power is given by his ability to incur TX fees relative to the total TX fees being paid for TXs. This is qualitatively different situation than PoW block chains, because in a tangle every payer has to incur the cost of security by paying higher TX fees (which I assume be burned so the coin is deflationary to 0 supply, unless you burn PoW hashes instead which is what I would advise). In Bitcoin all users pay the cost of mining security as well though either through debasement or TX fees, so it seems about the same. A potential advantage for a tangle is if you burn PoW hashes as I suggest, then every user is mining, unless they delegate this hash to a server. However appears neither tangle nor traditional PoW block chain can be immune to a 51% attack, whereas in my block chain scaling design I do claim this immunity (sorry to plug my work here but is necessary in order to point out relative strengths and weaknesses of all designs available to the crypto community).
As far as I remember, there are no tx fees (CfB?..). The nodes invest only PoW. No way to prevent double-spends in partitions of the network (no fault tolerance to network partitioning). I claim to solve this in my design and I think perhaps Lightning Network is also.
In the event when the attacker's node is the only one who sees that two branches, yes. I'm not sure that would be a recurrent situation, though. |
|
|
|
Please translate that general math to some concrete examples for us, so we can compare likely confirmation delays.
Did you see the examples on p. 14 ? |
|
|
|
What is "confirmation delay"? Time before a transaction is approved by another transaction?
Comparable to a 6 confirmation probability against double-spend in Bitcoin? https://bitcoil.co.il/Doublespend.pdfHow long does it take for a transaction to become "confirmed" such that it is very, very unlikely it can't be double-spent into the DAG?
I'll leave this question for the whitepaper author, his formulas scare me.  Protest, my formulas are always beautiful  Well, in iota you cannot say anything like "cumulative weight of X is enough for a tx to be considered confirmed", since the time enters the story. For the system to be secure on its own (i.e., without additional checkpoints or smth), the ability of the attacker to issue tx's must be much less than the "natural" flow of tx's in the system. So, what you have in iota is rather statements like "if a tx got cumulative weight X by time T, then the probability that this tx can be annihilated is at most p, provided that the potential attacker's hashing power is at most h and the natural tx's flow in the system is at least m", see examples in the bottom of page 14 in the paper. In that "6 blocks confirmation rule" of Bitcoin there are some implicit assumptions as well, by the way. "Everything must be made as simple as possible, but not simpler" (c) |
|
|
|
So when can a tx be considered unreversable ?
Never, look at formula #14 in http://188.138.57.93/tangle.pdf. Just like in Bitcoin there is always a chance of doublespending. Not even when the weight cap is reached ? (The paper mentions the cap but I'm not sure it ever states if the cap will actually be applied) That cap is only for the own weight of a tx (in fact, as far as I know, the plan is to set it to constant). The cumulative weight may (and will) grow. |
|
|
|
1. Could you explain in layman's terms, why capping the amount of work per transaction makes double-spend attacks less likely to succeed? It doesn't sound intuitive.
Consider two situations: 1. You need to generate 1 block with 10 zeros in front, 2. You need to generate 1024 blocks with 1 zero. Let T be the time you need in the 1st case, R is the time you need in the 2nd. T, R are random variables, of course. Now, it is true that T and R have the same expectation, but it is *not* true that their distributions are the same. In particular, the variance of T will be much bigger. What is even more important, is the difference in large deviation probabilities. Assume that you need to complete you task within time (expected time)/10. What would you choose, 1 or 2, to maximize your chances? Well, better choose 1. That's quite intuitive. What is not intuitive, is how different these chances are. In situation 1, you will succeed with probability around 10% or so. However, in situation 2, it will be *very* low. Don't want to calculate, but it will be smth like 0.0000000000001... anyhow, practically zero. That's why, if you want to beat the rest of the network, it's much better to bet on "heavy" tx's, and so we avoid this kind of attacks by putting an upper limit on the own weight. |
|
|
|
Though I was invited to review the whitepaper, it seems all my questions remains unanswered. And section "4.1 Resistance to quantum computations" (added after my review?) seems pretty controversial by its reasoning. Anyway, Popov's work is the deepest made on DAG cryptocurrencies(all I've seen before were just forum & blog posts), I'm not sure what's presented enough to make something production-ready though. Let's see what will happen here. Have luck guys! I'm not sure if I understand what exactly your question is. If it's about submitting two conflicting tx's, then there is no problem - one will survive, and the other will die (that is, at some moment it will stop gaining cumulative weight). Besides, if you're buying smth from a merchant and submit a conflicting transaction at the same time, the merchant would call a police The attacker can leave after he received the good and then issue the double spend as said in the Whitepaper. So the merchant will not see anything until the attack succeed ( if it succeed ) EDIT : I love IOTA. Good luck guys ! That's exactly the point: if it succeeds. If the legit tx already got enough cumulative weight, then the probability of a successful attack will be very small. Exactly as in bitcoin and other cryptos. |
|
|
|
Though I was invited to review the whitepaper, it seems all my questions remains unanswered. And section "4.1 Resistance to quantum computations" (added after my review?) seems pretty controversial by its reasoning. Anyway, Popov's work is the deepest made on DAG cryptocurrencies(all I've seen before were just forum & blog posts), I'm not sure what's presented enough to make something production-ready though. Let's see what will happen here. Have luck guys! I'm not sure if I understand what exactly your question is. If it's about submitting two conflicting tx's, then there is no problem - one will survive, and the other will die (that is, at some moment it will stop gaining cumulative weight). Besides, if you're buying smth from a merchant and submit a conflicting transaction at the same time, the merchant would call a police |
|
|
|
- в целом обзор хорош и полезен (для вдумчивого читателя), но acklon правильно его прокомментировал: " производитель асиков доказывает, что PoS - фигня". Например, авторы обзора корректно описывают Nxt, в том числе основную особенность форжинга: "возможно предсказать с разумной точностью, кто откроет следующий блок". Но при обсуждении атаки "ничего на кону" ("Nothing at Stake") они не удосуживаются упомянуть, что как раз эта особенность позволяет Nxt радикально нивелировать угрозу "ничего на кону". Мне кажется, авторы обзора не отметили (умышленно?) главное. Биткоин сделал первый шаг, абсолютно революционный: впервые в истории человечества нематериальные, независимые клочки информации получили реальную ценность (стоимость). И этот первый шаг позволил сделать второй, гигантский шаг: опираясь на реальную ценность криптоакций, создать лёгкие, экологичные, изощрённые криптовалюты на основе "доказательства ценностью акций" ("Proof of Stake"). Точно также в истории жизни на Земле был первый революционный шаг - возникновение РНК. И только после этого был сделан второй, решающий шаг к тому миру, который мы знаем - миру ДНК (в котором РНК никуда не исчезла, но выполняет вспомогательную, обслуживающую роль в отношении ДНК. И вот РНК заказывает сравнительный обзор механизмов РНК и ДНК ...). Интересно, почему они мою скромную статью называют белой книгой?.. И вообще, сначала на меня наехали ("Анализ (4), проведенный в белой книге Nxt [14] недостаточно убедителен"), а потом пришли к тем же выводам, только более криворуким способом. |
|
|
|
I ponder how full node maintenance is incentivized in this architecture, if at all.
To incentivize users mining on top of your transaction, you could add a fee to be taken by the confirmating tx. But to prevent orphaning wars, the maximum fee should be limited. DECOR+ is too expensive in terms of additional overhead to implement as per-transaction basis. And if tx fees are shared, txs would need to specify an additional payout address for accumulation of fees. That is not good for a txout-based ledger, because it generates too many spamming utxos. I can work for an account-based ledger. For example, if tx1 attach a fee of F, then the first confirmation tx gets F*0.4, the next one gets F*0.3, next 0.2, last 0.1. How does the network achieve consensus, on who was the first, who was the second, etc.? |
|
|
|
Кубик это миф)))
А Jinn? ) Это не миф |
|
|
|
Como faço para acessar a conta de outro pc?
Como verifico a minha "conta"?
Tenho a minha wallet atrelada a um computador... e ele fica guardada meu nome.
Se eu por acaso for acessar de um outro local, sem a devida identificação inicial, o que eu vou precisar?
Endereço da carteira e a senha apenas?? Ou tem algum "usuario"?
valeu!!!!
Se quiser só verificar o saldo, é melhor usar um explorador de blockchain. Se for pra mexer na conta mesmo, há duas opções: 1. Pode criar um outro wallet, e importar a conta existente lá usando a chave privada dela; 2. Ou salve os arquivos do wallet (/nem/ncc/walletname.adb e walletname.wlt) em um pendrive ou sei lá onde, instale o NEM no outro computador, e copie estes arquivos lá. Isso é relativamente seguro, pois outra pessoa não poderá usar estes arquivos sem saber a senha da wallet. |
|
|
|
Что за подпись у профессора: "Crypto Alliance - Free giveaway and IPO live" и принимают ли туда не кандидатов? Ой, это я когда-то давно забыл стереть. Уже и не помню, что это была за хрень |
|
|
|
|
You can also distribute among facebook accounts (of those who apply) created before certain date. And also among bitcointalk/nxtforum users: e.g., senior and hero members get a stake for free, full members pay smth, junior members pay more.
|
|
|
|
|
please add me to the free giveaway
|
|
|
|
А вот я считаю что надо делать алгоритмы таким чтобы эффективность была обратно пропорциональная мощности
Oй, но так не бывает |
|
|
|
Как записать пароль с пробелами в конфиг mint? Записал "как есть", но mint понимает его как другой кошелек. На данный момент остается только создать новый кошелек с более простым паролем и закинуть на него 100-200 некстов(комиссия для mint транзакций) Ой ой ой! Что же это происходит, с меня в процессе добычи еще будут комиссию снимать? Будут! Поэтому ставь размер блока (параметр nxt.mint.unitsPerMint) побольше, чтоб не очень часто платить комиссию. |
|
|
|
С наступающим, народ!
Счастья и здоровья остальное купим Это точно |
|
|
|
|
Show Posts
