Author Topic: Transactions as Proof-of-Stake & The End of Mining  (Read 58456 times)

0 Members and 1 Guest are viewing this topic.

Offline boshen1011

  • Full Member
  • ***
  • Posts: 89
  • Keyhotee ID:Bo
    • View Profile
@alexkravets,  thank for your suggestion.  Would you please continue to share us with your thoguths.  :)

RL does need trust from community.

1>Ripple founders and RL will keep 45%, 5% percentage goes to rewarding system.  Is it fair?

Suppose it is fair, and 45% of xrp is deserved for their great ideas and hard works.

2> Another 50% xrp goes to giveaways' distribution system. I have asked many people, some of them are RL employees...GIVEAWAY > 

give people for free.  Correct me if my bad English leads me to a bad understanding.

In other words, another 50% xrp belongs to other people EXCEPT RL, however RL did not keep its word.

The problem is that RL has been selling xrp to people who suppose to get xrp for free as planned.

RL is rewarded 45% of xrp, how could it look at others' xrp, cashed out xrp for other people, then put the cash into its own pocket?

That is BIG centralized problem, seems like the BD of RL is the chairman of FED in digital space, even much worse...

NOTE: I still think Ripple system has a best solution for financial market in the digital space until today. But the whole business theory and logics is totally wrong if RL want to play in the decentralzed digital space. The exit strategy for RL is to be acquired by a big bank one day.


« Last Edit: December 10, 2013, 06:34:42 pm by boshen1011 »

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
I'm glad to see Ripple found a way to distribute XRP, that was for sure their biggest problem.  Do you know what % of ripple labs holdings will be distributed in this way?

They keep tuning things as they go along, their initial experiments were failures because of scams and other social factors, this mode of distribution as reward for helping cure cancer etc seems to be at least as viral as bitcoin if not more so and immune from accusations of waste.

My guess is that they will greatly expand the giveaway once they get all the kinks out to billions of XRPs and a million people.

There is also talk of including grid computing clients in upcoming iOS and android versions of the client to rule out scams while expanding the giveaway to a billion non-geek smart phone users


Sent from my iPad using Tapatalk
« Last Edit: December 09, 2013, 06:33:31 am by alexkravets »

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
I have looked into Ripples algorithm and that is the fallback... I still do not like the Unique Nodes List...

Yes, it took me a while to wrap my head around the concept too, despite being advertised as trust-free Bitcoin and all other blockchain-based systems which are pool mined ( which is an unavoidable outcome of competition ) actually all have One Giant Unique Node List today, namely ALL Bitcoin users trust top handful of pools not too collude and none of them to become too big.

What ripple does differently is to formalize exactly what such trust entails, namely only not to conspire and unlike Bitcoin, any node gets to maintain its own, not necessarily pulicised ensures that no Sybil attacks or conspiracies are feasible not only because they are exceedingly unlikely, but also because all consensus proposals must be signed by nodes private keys, any attempt at validating invalid transactions or omission of valid ones leads to immediate smoking-gun incontrovertible evidence against attackers at which point they can be dropped automatically from everybody's UNLs

Key difference is that unlike in Bitcoin, participating nodes have key pairs which must be used and which provide strong reputational naming fir the rest of the network, compare to any other coin, where participating nodes are essentially fully anonymous and therefore have many more ways to misbehave.

Meta remark: One of the attractions of the DAC concept is that it's a much higher level layer "application software"
Just like meatspace corporations can change their physical infrastructure, a DAC should be abstracted away from its consensus level "wiring" its operating activities should use higher level primitives and not be commingled with low level p2p consensus.

Should we call it VDAC for Virtualized DAC ?

I'm thinking of creating a "consensus isolation layer" akin to to hypervisor between a collection of DACs and underlying "hardware of consensus" from this point of view for example, Ripple is a cross currency, distributed market based payment DAC *commingled*  with a cryptographically secured p2p avalanching-consensus-based database toolkit.


Sent from my iPad using Tapatalk
« Last Edit: December 09, 2013, 06:32:18 am by alexkravets »

Offline Lighthouse

  • Sr. Member
  • ****
  • Posts: 376
  • Making a Market in PTS since 11/06/2013
    • View Profile
    • Lighthouse Bulk Orders and Trusted Escrow (Closed)
I'm glad to see Ripple found a way to distribute XRP, that was for sure their biggest problem.  Do you know what % of ripple labs holdings will be distributed in this way?
Before you say the price of PTS is too high, take a look at theThe Reason.  Protoshares are an entirely new type of Cryptocurrency, one that pays to hold.

Offline bytemaster

Why not simply adopt Ripple's consensus algorithm ?  It's open source and easily formalize-able into a page of pseudo-code (it will have lots of company-sponsored and independent academic backup soon)
 
If mining is now understood to be unnecessary for security and only serves to create viral adoption, why not decouple mining from the consensus agreement in exactly the same way as Ripple did ?

Until recently b/c it required and used no mining Ripple was considered not viral enough, however that changed once Ripple Labs instituted a http://computingforgood.org/ where impossible-to-scam currency distribution and viral adoption has been completely decoupled from day-to-day operation of the network. A few weeks into the program there's 7000+ mining participants growing at over 50% per week https://secure.worldcommunitygrid.org/ms/team/viewMyTeam.do

Notice, that all the immense advantages of Ripple's Consensus over block-chain-based systems will apply
https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners#Ripple_is_a_Payment_System

I have looked into Ripples algorithm and that is the fallback... I still do not like the Unique Nodes List...
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
Why not simply adopt Ripple's consensus algorithm ?  It's open source and easily formalize-able into a page of pseudo-code (it will have lots of company-sponsored and independent academic backup soon)
 
If mining is now understood to be unnecessary for security and only serves to create viral adoption, why not decouple mining from the consensus agreement in exactly the same way as Ripple did ?

Until recently b/c it required and used no mining Ripple was considered not viral enough, however that changed once Ripple Labs instituted a http://computingforgood.org/ where impossible-to-scam currency distribution and viral adoption has been completely decoupled from day-to-day operation of the network. A few weeks into the program there's 7000+ mining participants growing at over 50% per week https://secure.worldcommunitygrid.org/ms/team/viewMyTeam.do

Notice, that all the immense advantages of Ripple's Consensus over block-chain-based systems will apply
https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners#Ripple_is_a_Payment_System

Offline bytemaster

I recently came up with another system that could work, though I am not fully sold on it.

What if the share holders elected people who would sign blocks?   You vote for the signers with CDD. When they sign they spend the CDD they accumulated from people voting for them.  No one would be allowed to sign more than 1 in 100 blocks. 

This plan has many potential problems, but I thought I would add it to the idea pool.

This could actually work at first, since the majority of people would vote for the most legitimate block available. But over time people would develop software to track who was signing legitimate blocks, and then be less likely to vote for new miners. Also, how do you propose we tell the difference between individuals?

Public individuals would volunteer so people are voting for who should be the custodians of the chain.   It would be like getting to vote for who is mining BTC rather than having it go to whoever could pay the most.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline phoenix

  • Sr. Member
  • ****
  • Posts: 275
    • View Profile
I recently came up with another system that could work, though I am not fully sold on it.

What if the share holders elected people who would sign blocks?   You vote for the signers with CDD. When they sign they spend the CDD they accumulated from people voting for them.  No one would be allowed to sign more than 1 in 100 blocks. 

This plan has many potential problems, but I thought I would add it to the idea pool.

This could actually work at first, since the majority of people would vote for the most legitimate block available. But over time people would develop software to track who was signing legitimate blocks, and then be less likely to vote for new miners. Also, how do you propose we tell the difference between individuals?
Protoshares: Pg5EhSZEXHFjdFUzpxJbm91UtA54iUuDvt
Bitmessage: BM-NBrGi2V3BZ8REnJM7FPxUjjkQp7V5D28

Offline bytemaster

I recently came up with another system that could work, though I am not fully sold on it.

What if the share holders elected people who would sign blocks?   You vote for the signers with CDD. When they sign they spend the CDD they accumulated from people voting for them.  No one would be allowed to sign more than 1 in 100 blocks. 

This plan has many potential problems, but I thought I would add it to the idea pool.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline phoenix

  • Sr. Member
  • ****
  • Posts: 275
    • View Profile
Here is one additional detail that can be used to evaluate forks:  the only CDs that count toward confirming a fork are CDs earned prior to the fork.  In other words, a fork cannot confirm itself by re-spending coin-days earned after the fork.   

This particular metric is a bit tricky to maintain, but is possible to calculate.   

I also believe that this is the key to preventing CDs from being reused constantly.... you can start accumulating CD immediately after you destroy them, but if you spend them again too soon they do not count.   I think we can define 'too-soon' as before 3-4x as many CDs have confirmed your original CDD.   So, if you control 1% of the money supply and thus destroy a lot of CD at once, you have to wait until another 4% of the money supply confirms your CDD before your new CD fully vest.   In summary, CD must vest prior to being spent.

Arkanaprotego mentioned earlier about how an optimized client would essentially "game" the system automatically.   What would just embracing this?  Can there be a "mining mode" that watches the network looking for advantageous opportunities to be the biggest spender in the network at that particular instant of opportunity?   I bet given the opportunity most people would do that instead of letting their coindays acrue and requiring them to time it manually.  Would this even be possible?  Seems like the client would need to monitor transactions being broadcast and when it identifies a lot of transactions smaller than its potential CDD available it opportunistically fires a TX to itself and attempts to claim the block.  Lots and lots of clients doing this on an ongoing basis would create a very level market if I read my incentives correctly.  Latency would be an issue, opportunities would be spotted by many and fired quickly.....   Either way, you see where I'm going here.

This kind of a node would be very useful to network security, since it would only want to spend it's coin days on a legitimate blockchain. I could see people creating optimized versions of this node, that tracks what other nodes are doing, and then attempting to determine which addresses belong to a single node. The node could then have a better chance of being able to capture a block, since it could make a more informed decision about spending it's coin days
Protoshares: Pg5EhSZEXHFjdFUzpxJbm91UtA54iUuDvt
Bitmessage: BM-NBrGi2V3BZ8REnJM7FPxUjjkQp7V5D28

Offline Lighthouse

  • Sr. Member
  • ****
  • Posts: 376
  • Making a Market in PTS since 11/06/2013
    • View Profile
    • Lighthouse Bulk Orders and Trusted Escrow (Closed)
Here is one additional detail that can be used to evaluate forks:  the only CDs that count toward confirming a fork are CDs earned prior to the fork.  In other words, a fork cannot confirm itself by re-spending coin-days earned after the fork.   

This particular metric is a bit tricky to maintain, but is possible to calculate.   

I also believe that this is the key to preventing CDs from being reused constantly.... you can start accumulating CD immediately after you destroy them, but if you spend them again too soon they do not count.   I think we can define 'too-soon' as before 3-4x as many CDs have confirmed your original CDD.   So, if you control 1% of the money supply and thus destroy a lot of CD at once, you have to wait until another 4% of the money supply confirms your CDD before your new CD fully vest.   In summary, CD must vest prior to being spent.

Arkanaprotego mentioned earlier about how an optimized client would essentially "game" the system automatically.   What would just embracing this?  Can there be a "mining mode" that watches the network looking for advantageous opportunities to be the biggest spender in the network at that particular instant of opportunity?   I bet given the opportunity most people would do that instead of letting their coindays acrue and requiring them to time it manually.  Would this even be possible?  Seems like the client would need to monitor transactions being broadcast and when it identifies a lot of transactions smaller than its potential CDD available it opportunistically fires a TX to itself and attempts to claim the block.  Lots and lots of clients doing this on an ongoing basis would create a very level market if I read my incentives correctly.  Latency would be an issue, opportunities would be spotted by many and fired quickly.....   Either way, you see where I'm going here.
Before you say the price of PTS is too high, take a look at theThe Reason.  Protoshares are an entirely new type of Cryptocurrency, one that pays to hold.

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
Quote
CD can only apply to one chain at a time. So I think we are on the same page. 
Can they? I think this can be enforced, but by default it isn't, since coin age depends on the date of the last transaction, which depends on which chain you are on. After a fork, coins accumulate CDs on every chain, which is something PoW does not have to deal with.

Quote
I agree vesting would take influence from people transacting every block and give it to savers.   An attacker would then have to hold his coins longer. 
I think I see where we differ finally :)
You base your analysis on an opportunist attacker looking for an easy profit, while I base mine on a malevolent powerful entity that just looks to destroy the network. Is that it?
So in consequence you create economic deterrents while I just look to make the requirements as high as possible (owning half of the money supply).
I think both are valid concerns, but I still believe that my solution solves both.

The one question I have for you is: What is the benefit of allowing people to save CDs? If you just want to reward savers over spenders, I think we could just implement two types of CDs, security CDs (SCDs) and investment CDs (ICDs). Investment CDs can be calculated following the rules you set and be used to distribute dividends as you see fair, while security CDs follow my set of rules and are constantly spent in "security transactions" to the same address to secure the network. Just two ways of counting, I don't think the representation in the block chain has to be altered: make ICDs reset when sending to another address, and SCDs reset at any transaction. "Security transactions" don't even split the coins, which makes SCDs easier to track.
Spending SCDs continuously prevents attacks, and allowing ICDs to be saved rewards your long term investors: you get the best of both worlds.


Quote
I think we have something.
Not sure what you're thinking about, but I'll await it eagerly  :D

Offline bytemaster

CD can only apply to one chain at a time. So I think we are on the same page. 

I agree vesting would take influence from people transacting every block and give it to savers.   An attacker would then have to hold his coins longer. 

I think we have something.




Sent from my iPhone using Tapatalk
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline arkanaprotego

  • Newbie
  • *
  • Posts: 11
    • View Profile
Having to let CDs vest sounds reasonable, since that would also prevent people from spamming the network with transactions to themselves.

However I don't see the need to prevent CDs from being reused constantly, it is their purpose. I think there might be some confusion about the temporal aspect of CDs, as you seem to view coin-days only as a resource that accrues in the hands of stakeholders and that can be engineered at will.

The original idea behind coin-days is to measure how many coins back each side of the fork. A coin is detected as supporting a chain when a transaction involving this coin is added to that chain. However, if we simply summed transaction volumes, fast circulating coins would have a disproportionate weight compared to slower circulating ones, and this could trivially be exploited. So we create a new metric by weighting each transaction by (age of the coin at the moment of the transaction)/(time since reference, ex.: genesis), which ensures that all coins have a weight equal to their value, to vote by transactions on what happened between the reference time and now (because the sum of the ages of the coin at the moments of the transactions is equal to the time elapsed since the reference). Since the time since the reference is present in all weights, you can simplify the expressions by multiplying by it everywhere, and you are left with coin-days as vote weights. This is where coin-days come from.

Given expression of coin-days, the rate at which coins accrue coin-days is constant (1/coin/day), and attempts to alter it will break the proportionality between vote value and coin value if the last equality is not verified  (e.g.: with delay, the sum of weights depends on the number and spacing of transactions).
Also notice that it is tricky to use the timestamp of the fork as a reference time, since it won't exactly match transaction dates for most of the coins. As a consequence, right after the fork, branches start with non-zero and most likely non-equal supplies of CDs. In other words, one chain might have a substantial head-start.

My proposal to address this is to force the spending of CDs regularly, so that branches will always start with close to 0 CDs. This can be done by capping coin age to 1 day and by rewarding everybody for destructing their CDs. Under these conditions, the longest branch is automatically the one in which the alive nodes own the most wealth. It also prevents attackers from accumulating CDs in secret (or accumulating CDs at all).

If you really do not want to automate the destruction of CDs, another way to do would be to implicitly reset coin-days at the fork, by not counting CDs accrued before the fork.
Is it what you wanted to suggest? If you really meant not counting CDs accrued after the fork, your metric to evaluate forks would fail to confirm the right branch if the attacker has more CDs when they initiate the attack. And I think it is the only case when an attacker would bother to start a fork, or the fork could be annihilated instantly by the users of the main branch, provided they are programmed to destroy more CDs in case of a forking attempt.

If you go with the second solution (I think the first one does not really need it, but it might still be safer to do it regardeless), it would be nice to prevent CDs from the same outputs from being destroyed in several chains, as it would reduce the gap between the two chains.
The goal is to prevent honest nodes from irreversibly supporting the attack in good faith, if they mistake an attack for the rightful chain during the time it takes the main chain to reestablish its dominance.
A soft way would be to add a rule to the honest clients so they don't reuse outputs.

Offline bytemaster

Here is one additional detail that can be used to evaluate forks:  the only CDs that count toward confirming a fork are CDs earned prior to the fork.  In other words, a fork cannot confirm itself by re-spending coin-days earned after the fork.   

This particular metric is a bit tricky to maintain, but is possible to calculate.   

I also believe that this is the key to preventing CDs from being reused constantly.... you can start accumulating CD immediately after you destroy them, but if you spend them again too soon they do not count.   I think we can define 'too-soon' as before 3-4x as many CDs have confirmed your original CDD.   So, if you control 1% of the money supply and thus destroy a lot of CD at once, you have to wait until another 4% of the money supply confirms your CDD before your new CD fully vest.   In summary, CD must vest prior to being spent.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.