Search content
Sort by

Showing 4 of 4 results by mcelrath
Post
Topic
Board Development & Technical Discussion
Re: Proposal: Transaction-Directed Acyclic Graphs
by
mcelrath
on 02/08/2016, 17:16:45 UTC
This isn't a need: miners will contribute to the highest work braid/chain simply because that is the one most likely to have other people contribute to it.  No extra incentive is needed.  If there exist two childless beads (blocks), it's in my best interest to name them both as parents.  That generates a higher work braid.  Naming only one of them creates a lower work braid.

This is not that simple, as Selfish Mining paper showed, a more sophisticated strategy may be more profitable.

Selfish mining works because of the asymmetry between profit of a block that gets orphaned and one that ends up in the main chain.  There's no reason to have orphans at all with a braid.  Withholding a block doesn't buy you anything.

This is a concept I put forth in my most recent talk about braids: "equal pay for equal proof-of-work".  Selfish mining is killed by a combination of braiding (no more orphans), and removing the asymmetry by ensuring all valid PoW hashes earn a block reward.
Post
Topic
Board Development & Technical Discussion
Re: Proposal: Transaction-Directed Acyclic Graphs
by
mcelrath
on 02/08/2016, 14:20:22 UTC
People seem to have repeatedly gotten hung up on the need to incentivise miners to lengthen the braid/chain, instead of widen it.  This isn't a need: miners will contribute to the highest work braid/chain simply because that is the one most likely to have other people contribute to it.  No extra incentive is needed.  If there exist two childless beads (blocks), it's in my best interest to name them both as parents.  That generates a higher work braid.  Naming only one of them creates a lower work braid.

Note that Satoshi's analysis and the "longest chain" rule is simplistic and only works for constant difficulty blocks.  It is very straightforward to combine the work from multiple blocks even having different targets and evaluate the total amount of work.  It's not equivalent to the chain "length" but the calculation is straightforward.  I leave it as an exercise for the reader.  ;-)

Note also that my work is entirely based on proof-of-work.  I don't think proof-of-stake works and you can't apply a profit maximizing rule to a set of numbers in your computer that fundamentally have zero marginal cost.  (For more on proof of stake, read my blog: https://blog.sldx.com/whats-wrong-with-proof-of-stake-77d4f370be15)
Post
Topic
Board Development & Technical Discussion
Re: DagCoin: a cryptocurrency without blocks
by
mcelrath
on 12/09/2015, 13:49:13 UTC
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.
Post
Topic
Board Development & Technical Discussion
Topic OP
Three Challenges for Scaling Bitcoin
by
mcelrath
on 11/09/2015, 16:19:19 UTC
The right answer is to re-engineer the system to not have the [block size] problem in the first place.

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