Topic: Do you guys realize that the first coin WITHOUT A BLOCKCHAIN is about to launch? (Read 4975 times)
March 03, 2016, 08:04:05 AM
First "coin" without a blockchain...linden dollars?
March 03, 2016, 12:15:44 AM
I don't think there will be a problem at all.
I appreciate TPTB observations, but I think CFB has got this.
Microsoft seems to agree as well.
February 09, 2016, 11:45:19 AM
For how long is that gonna last? It would be interesting but blockchain is the nice thing about bitcoin.
February 04, 2016, 01:46:59 AM
We will know soon enough.
It made me a little less worried when I seen that jl777 bought tokens.
It made me a little less worried when I seen that jl777 bought tokens.
January 12, 2016, 02:18:22 PM
1. But it may not always be unambiguous or other reasons that they can't do what you think they are incentivized to do. MUST is not the same as incentive. Be very careful in analyzing the details of consensus designs.
Quote from: http://188.138.57.93/tangle.pdf#page=7
1In fact, the author's feeling is that the tip approval strategy is the most important ingredient for constructing a tangle-based cryptocurrency. It is there that many attack vectors are hiding. Also, since there is usually no way to enforce a particular tip approval strategy, it must be such that the nodes would voluntarily choose to follow it knowing that at least a good proportion of other nodes does so.
January 12, 2016, 02:14:35 AM
I will not comment because I been threatened with a lawsuit by David if I comment.
Lolsuit
January 11, 2016, 05:37:16 PM
Quote
The LCR decides. So:
Order:
D,A (chain 1), A (chain 2, invalid so not applied), E, B, F, C, G
Code:
Chain 1: A<-B-
Order:
D,A (chain 1), A (chain 2, invalid so not applied), E, B, F, C, G
I just realised I've made a horrible typo here which is not helping at all, this should read:
Code:
Chain 1: A<-B<-C
Chain 2: D<-A<-E<-F<-G
Chain 2: D<-A<-E<-F<-G
Order of application:
D,A (chain 2), A (chain 1, invalid so not applied), E, B, F, C, G
A is the transaction which is spent twice.
January 11, 2016, 04:39:23 PM
I am exasperated. Can't you see that when there is ambiguity then there is conflict. Conflict resolution is why needed LCR and blocks.
Here is an example of a deterministic LCR transaction ordering for a forked chain:
The numbers denote the order they get processed in, and the time axis shows when they actually arrive.
January 11, 2016, 04:23:35 PM
You continue to do this mistake.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Why can't the LCR just change the order the transactions get applied in, rather than discarding entire branches?
Who decides that. Why is it unambiguous.
The LCR decides. So:
Code:
Chain 1: A<-B-
Order:
D,A (chain 1), E, A (chain 2, invalid so not applied), F, B, G, C
Keep thinking until you realize there are ambiguities. You'll eventually figure it out.
Which A is valid. Duh.
The one in the longest chain.
Which isn't a static event. Did you completely forget your error when analyzing that failed design of mine yesterday.
Ok, so you're saying that the incentive to have transactions confirmed in a timely manor is not sufficient to ensure users extend the longest chain?
I am exasperated. Can't you see that when there is ambiguity then there is conflict. Conflict resolution is why needed LCR and blocks.
January 11, 2016, 04:20:43 PM
You continue to do this mistake.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Why can't the LCR just change the order the transactions get applied in, rather than discarding entire branches?
Who decides that. Why is it unambiguous.
The LCR decides. So:
Code:
Chain 1: A<-B-
Order:
D,A (chain 1), E, A (chain 2, invalid so not applied), F, B, G, C
Keep thinking until you realize there are ambiguities. You'll eventually figure it out.
Which A is valid. Duh.
The one in the longest chain.
Which isn't a static event. Did you completely forget your error when analyzing that failed design of mine yesterday.
Ok, so you're saying that the incentive to have transactions confirmed in a timely manor is not sufficient to ensure users extend the longest chain?
January 11, 2016, 04:17:03 PM
You continue to do this mistake.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Why can't the LCR just change the order the transactions get applied in, rather than discarding entire branches?
Who decides that. Why is it unambiguous.
The LCR decides. So:
Code:
Chain 1: A<-B-
Order:
D,A (chain 1), E, A (chain 2, invalid so not applied), F, B, G, C
Keep thinking until you realize there are ambiguities. You'll eventually figure it out.
Which A is valid. Duh.
The one in the longest chain.
Which isn't a static event. Did you completely forget your error when analyzing that failed design of mine yesterday.
January 11, 2016, 04:15:16 PM
You continue to do this mistake.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Why can't the LCR just change the order the transactions get applied in, rather than discarding entire branches?
Who decides that. Why is it unambiguous.
The LCR decides. So:
Code:
Chain 1: A<-B-
Order:
D,A (chain 1), E, A (chain 2, invalid so not applied), F, B, G, C
Keep thinking until you realize there are ambiguities. You'll eventually figure it out.
Which A is valid. Duh.
The one in the longest chain.
January 11, 2016, 04:13:59 PM
You continue to do this mistake.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Why can't the LCR just change the order the transactions get applied in, rather than discarding entire branches?
Who decides that. Why is it unambiguous.
The LCR decides. So:
Code:
Chain 1: A<-B-
Order:
D,A (chain 1), E, A (chain 2, invalid so not applied), F, B, G, C
Keep thinking until you realize there are ambiguities. You'll eventually figure it out.
Which A is valid. Duh.
Okay so you change the rule that all double-spends are invalid. But there is still an ambiguity.
January 11, 2016, 04:12:16 PM
You continue to do this mistake.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Why can't the LCR just change the order the transactions get applied in, rather than discarding entire branches?
Who decides that. Why is it unambiguous.
The LCR decides. So:
Code:
Chain 1: A<-B-
Order:
D,A (chain 1), A (chain 2, invalid so not applied), E, B, F, C, G
January 11, 2016, 04:06:15 PM
You continue to do this mistake.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Why can't the LCR just change the order the transactions get applied in, rather than discarding entire branches?
Who decides that. Why is it unambiguous.
January 11, 2016, 04:04:34 PM
You continue to do this mistake.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Double-spends are not unambiguous. Who decides? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
Why can't the LCR just change the order the transactions get applied in, rather than discarding entire branches?
January 11, 2016, 03:55:23 PM
2. DSPEND <- GOODA <- GOODB. How do you modify GOODA or GOODB to not point to DSPEND when you do not have the private key. And if you allow anyone to change the references, then you have chaos.
I might be missing something very obvious here, but why do you need to do that? Nodes won't apply a transaction that is invalid, so the double spend just doesn't get applied - the other transactions which are chained can still get applied without issue as long as they are unrelated to the double spend?
You continue to do this mistake.
Double-spends are not unambiguous. Who decides which double-spend is reversed? That is why we have LCR.
If nodes can ignore the cumulative work, then you have chaos. You are forgetting the most fundamental point of LCR which is that only it gets to decide. Otherwise anyone can Sybil.
This is also why eMunie can't work without blocks. Period.
January 11, 2016, 03:52:52 PM
2. DSPEND <- GOODA <- GOODB. How do you modify GOODA or GOODB to not point to DSPEND when you do not have the private key. And if you allow anyone to change the references, then you have chaos.
I might be missing something very obvious here, but why do you need to do that? Nodes won't apply a transaction that is invalid, so the double spend just doesn't get applied - the other transactions which are chained can still get applied without issue as long as they are unrelated to the double spend?
January 11, 2016, 03:46:43 PM
1. But it may not always be unambiguous or other reasons that they can't do what you think they are incentivized to do. MUST is not the same as incentive. Be very careful in analyzing the details of consensus designs.
2. The transactions that follow the double-spend must be because they include the double-spend by referencing it. You need to study more closely the concept of the DAG. The transactions reference prior transactions. I thought you know that. So if there is a double-spend, but isn't known to be a double-spend until later, then all the transactions that referenced it will be potentially reversed. But again which set? It is ambiguous.
2. The transactions that follow the double-spend must be because they include the double-spend by referencing it. You need to study more closely the concept of the DAG. The transactions reference prior transactions. I thought you know that. So if there is a double-spend, but isn't known to be a double-spend until later, then all the transactions that referenced it will be potentially reversed. But again which set? It is ambiguous.
1. Maybe, I'm no expert on Iota, I just see parallels between the LCR and longest stream of POW.
2. I know transactions reference prior transactions, I'm just trying to understand why you must invalidate transactions which chain from a double spend, when you could also just not apply the double spend and carry on?
2. DSPEND <- GOODA <- GOODB. How do you modify GOODA or GOODB to not point to DSPEND when you do not have the private key. And if you allow anyone to change the references, then you have chaos.
January 11, 2016, 03:40:54 PM
1. But it may not always be unambiguous or other reasons that they can't do what you think they are incentivized to do. MUST is not the same as incentive. Be very careful in analyzing the details of consensus designs.
2. The transactions that follow the double-spend must be because they include the double-spend by referencing it. You need to study more closely the concept of the DAG. The transactions reference prior transactions. I thought you know that. So if there is a double-spend, but isn't known to be a double-spend until later, then all the transactions that referenced it will be potentially reversed. But again which set? It is ambiguous.
2. The transactions that follow the double-spend must be because they include the double-spend by referencing it. You need to study more closely the concept of the DAG. The transactions reference prior transactions. I thought you know that. So if there is a double-spend, but isn't known to be a double-spend until later, then all the transactions that referenced it will be potentially reversed. But again which set? It is ambiguous.
1. Maybe, I'm no expert on Iota, I just see parallels between the LCR and longest stream of POW.
2. I know transactions reference prior transactions, I'm just trying to understand why you must invalidate transactions which chain from a double spend, when you could also just not apply the double spend and carry on?
Jump to: