Topic: DagCoin: a cryptocurrency without blocks - page 19. (Read 70869 times)

Outputs consumed by the tx are already linked to.

These are unrelated and should be recent tips of the DAG.

The transaction links point to related transactions, such as inputs and outputs in bitcoin, or completely unrelated?

Nice ideas and innovation of a future coin. Hope you succeed in making it happen as need something different that stands out from the rest of them. Without blocks will be different but how is this going to be controlled or being accessed. How will the distribution be provided without blocks? Am guessing going to be using a different name or distribution service to provide miners if going to be mineable or another ICO? If this becomes ICO then CMO. Stuck on my watch list for the future to see how this turns out.

Really Interesting idea, a coin without blocks can solve many problems that bitcoin is having.

I was just thinking to myself, "but how will the initial distribution be handled under this coin?"... and then I suddenly realised the problem is already solved  .

This, or similar such ideas, sound like a potential solution to the possible problems when bitcoin hits the zero block reward stage. To be exploring that area so early is an optimistic sign  

As I didn't run simulations, I was worried about how would the width vary for different loads on the network. I want users to be able to reference many parent transactions if the braid is getting "thick", and reference only one if the braid is a chain. What would be the rule for the client wallet to decide ? As processing a transaction having many parents has a cost to the network, then this amount must be linked with the transaction PoW somehow.

I read your post and some other posts about this same matter the last months, so I decided to publish my old draft paper, so that others can use those ideas. But I'm not actively working on it.
 

This smarter way may open the system to Sybil attacks if it removes "linearity", splitting/merging/recombination of transactions may give adversary an advantage in this case.



Without difficulty you don't know if someone did a lot of work or just was superlucky (and got a lot of leading zeros).

Sergio, why are you worried about the "width" of the DAG?  I would think that every miner is incentivized to extend the "tips" of the DAG.  It really comes down to the metric for "work".  Bitcoin's measure of work is extremely simplistic because of its linear structure.  With a DAG you're looking at the "work" in the set of transactions upstream of the current transaction.  If miners "widen" the DAG, they are not contributing work...all the transactions have the same amount of work -- that of themselves plus their parent.  So this seems easy to solve by computing "work" in a smarter way.

I have a couple of preliminary formulas for calculating work in a DAG under certain constant-target assumptions that eliminate your concern, I think, but I feel there's still a better solution I haven't found yet.  I also want to get rid of the target difficulty and simply combine whatever hashes show up.  (This then frees "difficulty" to be a node-specific quantity that can be used for bandwidth control and DDoS protection)

In case you haven't seen it, I propose the same thing (DAG-chain) here:

http://blog.sldx.com/three-challenges-for-scaling-bitcoin/

I have a longer draft with a lot more specifics on the DAG/braid concept that I'm not ready to publish just yet.  Only as of last week am I paid to work on bitcoin, so can actually bring it to fruition.  We should see if we can collaborate, feel free to contact me privately.

Comparing to Bitcoin, what are the advantages and disadvantages of Dagcoin?

It sounds to me quite interesting.
Actually, I had similar ideas over time, but I didn't bother messing with them.

This is true for DagCoin. If a transaction references two parents having conflicting transactions, only one of them becomes valid, and that is the one with more PoW. If both have the same PoW, then the first one is the valid one. Never a transaction validates two conflicting recursively referenced txs.

The only drawback is that which one is the valid one is not immediate obvious: you need the appropriate data structure and the whole transaction tree (up to a checkpoint) to find which one is the valid one.

I think one of the new ideas about DagCoin is that the number of parents you can reference is not chosen by the user, but by the PoW found: the lower the hash, the higher the number of parents you must reference.

It only works if there is a backlog of transactions.

The magic behind any new cryptocurrency token is that since you can create money, you can set an incentive to confirm old transactions. So you can bootstrap your cryptocurrency.

When Bitcoin has no or very low subsidy, it will need a backlog of transactions to go forward. So the problem with DagCoin is bootstrapping. If you have an application where you can keep a flow of transactions going, you can make it work. Also you can add a subsidy to each transaction that has a very high PoW, and create an inflationary cryptocurrency whose price varies with electricity cost and inflates with Moore's law.

This is very interesting.
I'm wondering though how this could ever be rolled out as it literally needs the network to be active (or not ?). If I wanna transact I need someone else to transact as well and confirm my tx with his tx. I guess I could also send some more tx myself but that's not really going to fly.

That tech was about pegging.

Does it have anything to do with jl777's Crypto777? I remember you sold some technology to jl777.

Just read the OP. That description suits on 90%.

Woho, another one. Tell us more.

No.

Is it the quorum based Qubic?

I would feel more convinced of the well behaviour of this DAG if every transaction
can be viewed as the end point of a totally ordered valid sequence of transactions.

That would prevent the situation you describe where two ancestor transactions are in conflict.
I think that should make the joint descendant transaction invalid.

For a transaction referencing k parents tx_1..tx_k, we would like to define its total
order in terms of those of its parents. Let TX be the last transaction in their
intersection. Then all these histories agree up to TX and we need to define
a valid merge of the k sequence suffixes. Some merges will have conflicts, which
is something to be avoided. The problem reduces to the question of
which of the next available transactions (whose number is between 2 and k)
should extend the total order defined so far.

Have you considered whether this approach to well-ordering is feasible?