Bitcoin Forum
May 08, 2024, 09:25:37 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 »
  Print  
Author Topic: DECENTRALIZED crypto currency (including Bitcoin) is a delusion (any solutions?)  (Read 91075 times)
devnu11
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
January 13, 2016, 01:13:30 PM
 #401

Reading my newest thread in Altcoin Discussion reveals that none of the other designs improve upon Bitcoin in terms of the decentralization, permissionless attribute. And I strongly expect that designs without a block chain (Iota and eMunie) will be proven fundamentally flawed.

Open-transactions anyone?  Roll Eyes

Hey n00b, this white paper is nonsense because no where does it mention "double spend". My comment included the requirement for decentralization. The entire OpenTransactions concept is flawed. I had long ago critiqued it. It is crying shame to see someone waste so much effort implementing something that was not even well researched. Sigh.
Thanks, got more? Still, the notary model, with multi-sig voting pools or other mechanisms mentioned in the paper, is a demonstration to what you said is not possible. Last I checked, even Monetas was doing a great job to make in happen IRL.
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, which will follow the rules of the network no matter what miners do. Even if every miner decided to create 1000 bitcoins per block, full nodes would stick to the rules and reject those blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715160337
Hero Member
*
Offline Offline

Posts: 1715160337

View Profile Personal Message (Offline)

Ignore
1715160337
Reply with quote  #2

1715160337
Report to moderator
1715160337
Hero Member
*
Offline Offline

Posts: 1715160337

View Profile Personal Message (Offline)

Ignore
1715160337
Reply with quote  #2

1715160337
Report to moderator
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 01:16:06 PM
 #402

I skipped deep understanding of it and just noted it was for defeating lie-in-wait attack chains

Let me furnish you with a deep understanding of this monte carlo sampling technique; for the uninitiated, monte carlo sampling is a technique which takes a very complex data set, and samples it at random locations in order to build a probabilistic model for the truth of the underlying system, which may itself be intractable to process directly.

An example, here is a monte carlo rendering of a scene at an increasing number of samples:



The idea being that this sampling process is orders of magnitude faster than processing the full data set (in this image, it would be fully raytracing the entire scene, with multiple light bounces / radiosity etc).

In Iota, this technique is simply used to find the tips with the most cumulative weight (as I have been saying all along) but without having to process the entire set of transactions all the way back to genesis from every tip, which would be too slow. This is their game theoretically optimal choice as participants who want timely confirmation of their transactions.

TLDR; Iota uses monte carlo sampling to find the tips with the most cumulative weight in order to decide where to extend the DAG.

That is wonderful technology. And I am sure it made you guys feel proud (which probably blinded you to the higher level generalized flaw).

But often in life, higher level semantics roost.

In this case, we can't prove that all actors in the system are going to be incentivized to follow any specific selection algorithm for choosing which transactions to reference in their new transactions. The game theories are unfathomable. Again if you can show a comprehensive math of all the game theories as Satoshi has done, then you will be on par with the trust in Satoshi's design. Until then, you've got some fancy math without a fundamentally sound home.

Iota can I am sure get many n00bs to think you have something valuable. Perhaps that is why you don't like when I call a n00b a n00b. I will not be be actively trying to spread any information about Iota. I am interested in the technical understanding for my own work.

Corporations and serious users will be concerned with the fundamental soundness of the security.

TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 01:24:28 PM
 #403

Reading my newest thread in Altcoin Discussion reveals that none of the other designs improve upon Bitcoin in terms of the decentralization, permissionless attribute. And I strongly expect that designs without a block chain (Iota and eMunie) will be proven fundamentally flawed.

Open-transactions anyone?  Roll Eyes

Hey n00b, this white paper is nonsense because no where does it mention "double spend". My comment included the requirement for decentralization. The entire OpenTransactions concept is flawed. I had long ago critiqued it. It is crying shame to see someone waste so much effort implementing something that was not even well researched. Sigh.
Thanks, got more? Still, the notary model, with multi-sig voting pools or other mechanisms mentioned in the paper, is a demonstration to what you said is not possible. Last I checked, even Monetas was doing a great job to make in happen IRL.

Are you retarded? I wrote in the prior post that it isn't not a counter example about the decentralized, permissionless attribute which is the attribute I am writing about in this thread. Of course anyone can make a centralized payment system. Please stop posting noise here. Bye.

Your level of technical understand is entirely inadequate to even comprehend what you are writing about. Please it is noisy and painful to watch you demonstrate in public that you are an utter fool and hiding behind a newbie sock puppet account.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 13, 2016, 01:28:11 PM
 #404

@Come-from-Beyond in Iota, do branches ever get orphaned? The whitepaper isn't clear on this.

All valid transactions (even conflicting) exist in the tangle and are not removed from it. "Orphaning" makes no sense in this model.
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 01:29:51 PM
 #405

@Come-from-Beyond in Iota, do branches ever get orphaned? The whitepaper isn't clear on this.

All valid transactions (even conflicting) exist in the tangle and are not removed from it. "Orphaning" makes no sense in this model.

Yet the word 'orphan' is in the Iota/Tangle white paper and he is obscuring from you what is your misunderstanding monsterer. Wait I will be replying to your posts monsterer because you continue to make the same egregious error because you still have not yet comprehended a DAG at all.

The attacker's idea is to make the nodes reference the parasite chain, so that the "good" tangle would become orphaned.

Read-only eh?  Wink

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 13, 2016, 01:38:15 PM
 #406

@Come-from-Beyond in Iota, do branches ever get orphaned? The whitepaper isn't clear on this.

All valid transactions (even conflicting) exist in the tangle and are not removed from it. "Orphaning" makes no sense in this model.

That's what I thought.

So, for clarity's sake, if there is a double spend on a branch, and valid transactions reference the double spend, are the subsequent valid transactions rendered invalid?
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 01:39:39 PM
 #407

@Come-from-Beyond in Iota, do branches ever get orphaned? The whitepaper isn't clear on this.

All valid transactions (even conflicting) exist in the tangle and are not removed from it. "Orphaning" makes no sense in this model.

That's what I thought.

So, for clarity's sake, if there is a double spend on a branch, and valid transactions reference the double spend, are the subsequent valid transactions rendered invalid?

Please stop and wait for my eludication. You are asking questions that don't make any sense. Your graphs are irrelevant. The security model is probabilitistic, not deterministic! You can't seem to get that into your hard head.

If you didn't study computer science, please understand that you do not then understand the distinction between a probabilistic and deterministic algorithm.

Wait I need to eat breakfast first. I went directly from bed to posting. Need to eat (being that I am still partially human in spite of my Cyborg implants).

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 13, 2016, 01:46:43 PM
 #408

Read-only eh?  Wink

Your childish behavior is not the fault of monsterer, it would be impolite to ignore his question.

"Orphaned" indeed is used in the whitepaper, but if you re-read my reply you'll see that my answer doesn't contradict it. I don't quote your post, so you have a chance to edit it and keep the renome of an intelligent person.
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 01:48:22 PM
 #409

"Orphaned" indeed is used in the whitepaper, but if you re-read my reply you'll see that my answer doesn't contradict it.

You are good at obfuscation and word-smithing. You know damn well that he doesn't understand that a DAG is probabilistic and not deterministic. And you are not trying to help him understand. Instead encouraging his myopic posts that assume a DAG has some deterministic structure.

There is nothing childish about my responses. Purely facts.

Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 13, 2016, 02:06:55 PM
 #410

That's what I thought.

So, for clarity's sake, if there is a double spend on a branch, and valid transactions reference the double spend, are the subsequent valid transactions rendered invalid?

I think the confusion arises from ambiguity of "transaction" definition. There are two DAGs - approval and payment graph. A single payment transaction can be "wrapped" into several approval transactions. Answering your question - it's impossible that a valid transaction contains a double-spend, it would be a violation of the protocol. We could imagine a being existing outside of the time that observes the entire timeline and knows what subtangle is adopted by the majority. Such the being could call some transactions double-spends, but we can't do it. What we see depends on the point of view that can be changed every second. I'm against simplified definitions and analogues to Bitcoin blockchain. They confuse people and hide that tangle is more powerful than blockchain. Sticking to classical definition - yes, a single double-spend invalidates all transactions referencing it. Once this happens the players will clone the invalidated transactions, for a particular transaction it will be the sender if he hasn't received the purchased service yet, or the recipient (because he doesn't want to lose money). But again, all this happens within the adaptation period.
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 13, 2016, 02:13:37 PM
 #411

Sticking to classical definition - yes, a single double-spend invalidates all transactions referencing it. Once this happens the players will clone the invalidated transactions, for a particular transaction it will be the sender if he hasn't received the purchased service yet, or the recipient (because he doesn't want to lose money). But again, all this happens within the adaptation period.

If this is the case, why can't an attacker simply place a double spend into every single chain head, and force all subsequent transactions to be invalided?

Wouldn't that bring the entire tangle to permanent halt since there would be no valid heads left to extend?
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 13, 2016, 02:16:02 PM
 #412

If this is the case, why can't an attacker simply place a double spend into every single chain head, and force all subsequent transactions to be invalided?

Wouldn't that bring the entire tangle to permanent halt since there would be no valid heads left to extend?

If one of the transactions is a double-spend then another is legit, right?
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 13, 2016, 02:19:09 PM
 #413

If this is the case, why can't an attacker simply place a double spend into every single chain head, and force all subsequent transactions to be invalided?

Wouldn't that bring the entire tangle to permanent halt since there would be no valid heads left to extend?

If one of the transactions is a double-spend then another is legit, right?

So, I guess in the best case, only one chain head survives this attack?
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 02:20:48 PM
 #414

Sticking to classical definition - yes, a single double-spend invalidates all transactions referencing it. Once this happens the players will clone the invalidated transactions, for a particular transaction it will be the sender if he hasn't received the purchased service yet, or the recipient (because he doesn't want to lose money). But again, all this happens within the adaptation period.

If this is the case, why can't an attacker simply place a double spend into every single chain head, and force all subsequent transactions to be invalided?

Wouldn't that bring the entire tangle to permanent halt since there would be no valid heads left to extend?

Because the "selection algorithm" (c.f. my prior posts on my meaning of that term) attempts to make this too costly for the attacker. Now you start to understand why it is a probabilistic security and not a deterministic one. Are you starting to understand now why your upthread posts were so irrelevant?

P.S. I am trying to teach (and hand slap) you that you can't go analyzing designs piecemeal based on analogies to other designs such as what you did with Fuserleer. That annoyed me incredibly that you were spamming the thread with irrelevant analysis because designs can only be analyzed holistically. Again you were attempting to analyze a DAG piecemeal based on your understanding of a Satoshi block chain, which is entirely erroneous. Ditto your analysis of Raiblocks was analogously flawed.

TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 02:24:35 PM
 #415

If this is the case, why can't an attacker simply place a double spend into every single chain head, and force all subsequent transactions to be invalided?

Wouldn't that bring the entire tangle to permanent halt since there would be no valid heads left to extend?

If one of the transactions is a double-spend then another is legit, right?

So, I guess in the best case, only one chain head survives this attack?

No necessarily! You still don't understand!

You are thinking about the model entirely wrong. Wait let me compose a post for you. Please wait. Stop posting (stop spamming the thread). And wait.

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 13, 2016, 02:28:33 PM
 #416

Because the "selection algorithm" (c.f. my prior posts on my meaning of that term) attempts to make this too costly for the attacker. Now you start to understand why it is a probabilistic security and not a deterministic one. Are you starting to understand now why your upthread posts were so irrelevant?

I admit that my examples and ordering diagrams are suitable only for a tree and not a DAG. A node in DAG can have multiple parents, so there is no one consistent ordering, however, a tree is a different matter, and since we are not solely discussing Iota here, they are still pertinent.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
January 13, 2016, 02:34:20 PM
 #417

So, I guess in the best case, only one chain head survives this attack?

No, all heads that don't lead to conflicting ledger will merge. In case if it's not obvious, the number of heads is equal to the number of transactions. In ABCDEF sequence someone can still ignore "F" and pick "E" as a head. From the global point of view all heads will exist, "survives" doesn't make sense just like "orphaning". I find it very hard to explain the idea of Tangle, but once you get this idea you will see that if you send a double-spending right after the legit transaction you increase security of the tangle, not attack it. This is because you fight not only against the system but also against other attackers. "Enemy of my enemy is my friend" perfectly works here.
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 02:35:34 PM
Last edit: January 13, 2016, 03:32:37 PM by TPTB_need_war
 #418

There are probably several different ways to try to explain how the security of a DAG works. For example, Come-from-Beyond characterized it as "two DAGs", one for payers and another for acceptance. My understanding is it is not that there are actually two data structures, but rather that the way the DAG is interpreted mathematically is analogous to two models (which actually depend on each other in some sense so perhaps let's say a unified model overall).

First you need to grasp that unlike in Satoshi's design where we have one single longest chain rule as acceptance truth, in a DAG there are many competing chains vying to be truth and no globally enforced protocol rule to select between them. The DAG's truth is the payer's model of how payers select which transactions to reference in their transactions and a second acceptance model of how we calculate the probability that the first model will select a conflicting double-spend. Thus the security is never based on any particular deterministic chain in the graph, but rather on the models that the payers and payees are using to model the DAG.

Until you understand that, you understand nothing about a DAG.

Whether that is more powerful or less secure than Satoshi's design is what CfB and I are debating and discussing.

My point has been that each payer and payee can choose a different model so the game theory of the security is unfathomable. The white paper shows that under a given model,  certain attacks are too costly. But the white paper can't show what happens under all game theories and thus can't present any holistic model of attack cost.

So, I guess in the best case, only one chain head survives this attack?

No, all heads that don't lead to conflicting ledger will merge. In case if it's not obvious, the number of heads is equal to the number of transactions. In ABCDEF sequence someone can still ignore "F" and pick "E" as a head. From the global point of view all heads will exist, "survives" doesn't make sense just like "orphaning". I find it very hard to explain the idea of Tangle, but once you get this idea you will see that if you send a double-spending right after the legit transaction you increase security of the tangle, not attack it. This is because you fight not only against the system but also against other attackers. "Enemy of my enemy is my friend" perfectly works here.

Piecemeal details like this will just cause the thread to become noisy because they won't help the reader gain understanding of the real way a DAG security works. Discussing the deterministic structure of the DAG is misleading discussion. We need to first explain the above as I did.

monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
January 13, 2016, 02:44:35 PM
 #419

No, all heads that don't lead to conflicting ledger will merge. In case if it's not obvious, the number of heads is equal to the number of transactions. In ABCDEF sequence someone can still ignore "F" and pick "E" as a head. From the global point of view all heads will exist, "survives" doesn't make sense just like "orphaning".

Understood. So, what stops people from inserting transactions into past history by referencing really old transactions in order to change historical  ordering?
TPTB_need_war (OP)
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
January 13, 2016, 02:49:35 PM
 #420

No, all heads that don't lead to conflicting ledger will merge. In case if it's not obvious, the number of heads is equal to the number of transactions. In ABCDEF sequence someone can still ignore "F" and pick "E" as a head. From the global point of view all heads will exist, "survives" doesn't make sense just like "orphaning".

Understood. So, what stops people from inserting transactions into past history by referencing really old transactions in order to change historical  ordering?

Damn it monsterer. If you are too lazy to understand and you continue to ignore what I am trying to teach you, then you are really pissing me off. You are rapidly losing the respect I had for you.

You can only see things one way and you can't change your perspective to the probabilistic model. This is a sign of a lower IQ.

You already know that there is no way to insert a transaction into an existing DAG chain. And yes a given selection rule can choose to reference an old transaction, but that creates a new tip (a new chain). But asking it the way you did shows that you are still thinking about irrelevant structure and not thinking about the model of the security as it is HOLISTICALLY probabilistic not locally deterministic to any given chain structure. The only deterministic rule is that transactions may not reference tips that would put a double-spend into the merged chains.

You need to invoke math here, not just analyzing a chain structure. I believe this is beyond your comprehension.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!