Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - arkanaprotego

Pages: [1]
1
What happened to the idea of having automatic votes based on past performance as default?

2
What I don't like in Ripple is that most people cannot become validators because you need a reputation for that. And it doesn't matter who you trust, what matters is who trusts you: if everybody noticed more than half the nodes of the default UNL were subverted by some entity, no one would be able to help it, because no one would trust each other. Worse yet, the honest validators would validate the dishonest ledgers in the name of consensus.

But on the other hand I am beginning to be convinced that securing economic infrastructures with money only (in the form of ASICs, electricity, shares... you name it) is not so great, because it is quite cheap for a powerful attacker as long as the community is growing.

So distributed trust might be the safest solution for the moment... But definitely not the one I like most.

3
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.

Wouldn't that generate an awful lot of network spam? At each block, each node would have to know what each other node has voted?


I have an idea based on a lottery system.

It requires the introduction of another type of coin-days that are reset after each block. I'll refer to as BCDs, for Block Coin-Days.

After a node receives a block, it takes the hash of the block and the hash of its Bitshares address, and applies a binary AND on them. The result is a speed of BCD gain per coin.
The node can then compute the number of BCD held by its address as a function of time: BCD = time_since_last_block * (block_hash AND address_hash) * number_of_coins.
It will broadcast a block when the amount of BCD reaches a target set by the protocol, depending on previous blocks. The block must reference the outputs used to generate the BCDs.


The idea is that the node with the highest BCD gain speed ((block_hash AND address_hash) * number_of_coins) will win. As time passes, it is more and more likely that someone will meet the target (like PoW), and the randomness prevents the biggest stake-holders from always publishing the block. They still have more chance of meeting the target though, since the expected value of the BCD gain speed is proportional to the amount of resources owned (also similar to PoW).
Unlike some other lottery systems addresses, this does not reward splitting your funds into multiple addresses.

Difficulty target can be initialized analytically to target a specific block generation time, as the distribution of Protoshares can be calculated at the genesis of Bitshares. However, I think target adjustment would have to be completely empirical afterwards (increase if blocks are generated too fast, decrease if too slow).
To help constrain block generation time, I think a polynomial weighting of time could be used (e.g.: use time_since_last_block^4 instead). If time_since_last_block < 1, it is harder to reach the target. If time_since_last_block > 1, it is easier. Stronger degrees increase this effect.

Latency is not an issue, given that if you receive two blocks, you can easily see which one met the target first. However, this implies using the sum of BCDs to determine the main chain (at least to some extent).

I really like this approach and am attempting to internalize it.

Glad you like it :)

However I just realized I was a little too hasty in assuming the probability to broadcast a block was proportional to the coins you owned.
This is because when you are a small owner, you do not just need to be lucky to publish a block, you also need all the bigger owners to be (much) less lucky than you.
In other terms, it's not BCD that should be proportional to the number of coins owned, it's the probability that your score will be the highest, which is not the same.

A quick fix would be to use "lottery tickets" instead of addresses. Each ticket has a value equal to hash(signature(hash(previous_block)+sequence_number)). If you have 3 coins, you have 3 tickets (sequence numbers 1, 2 and 3. All tickets are equivalent, so this time your odds to win are truly proportional to your number of coins, i.e.: number of tickets.
Then when time_since_last_block^n * AND(ticket, hash(previous_block)) ==  target, you can claim your gains by broadcasting the new block, with your signed message embedded.
If you try to claim ticket 4, it won't work because the other nodes know you don't have 4 coins.
The use of a signature is to deter people from trying to guess other people's tickets and engineering blocks that would be better for them (adding/shuffling transactions). It might not be necessary, depending on how long/how much it takes.

EDIT: another variant, even closer to PoW. Remove time_since_last_block from the target calculation. Instead, everybody draws additional tickets every second: ticket = hash(signature(hash(previous_block)+sequence_number+seconds_since_last_block)). Now it truely is like PoW, and there is some hashing involved, but your contribution is capped by your stake and not by your hardware. If you have 1000 coins, your are capped at 1kH/s. Of course, units are arbitrary.
The benefit is that it makes block generation time less variable.

EDIT2: It seemed to me all these lottery systems are potentially vulnerable to block engineering: if someone had enough hashing power, they might be able to produce favorable blocks with very few coins, by performing minor changes on the list of transactions.
I suppose the system could be made resistant to block engineering by only taking the hash of fields in the block that cannot be altered for lottery purposes, like the signature of the reward claimer and the block height. If you have a ticket good enough to claim the reward, your only degree of freedom is to claim it or not, so your possibilities for block engineering are very limited.
New blocks still have to reference the hash of the previous full block (i.e.: including transactions) though, for obvious security/consensus reasons.

4
I just thought of a variant of the BCD system I proposed: use BCD from the Protoshares chain to secure the Bitshares chain, and issue Bitshares through subsidies, based on ownership of PTS  (somewhat like Bitcoin, but using Protoshares as "hashing power"; subsidies don't have to be for finding blocks though, read below). I haven't really thought about all the implications yet, but I realized there was no reason to keep security and wealth so tightly coupled, so I'm putting this idea on the table. All comments are welcome.

Pros:
- Strong incentive to keep Protoshares in the long run: "mining" Bitshares
- There is a public (yet pseudonymous) ledger of "hashing power" (PTS), so this mining does not require centralization and few special transactions: no matter how little you "mine", just parse the Protoshares chain to see how many Bitshares you (or anyone) can claim from "mining", and claim them at the same address on the Bitshares chain using a special transaction from time to time (e.g.: once a day). EDIT: You can also bust freeloaders: do not award subsidies if the claiming address could have published better blocks than those in the chain but did not.
- Increase liquidity of Bitshares, since you don't need to hoard more to earn more.
- Bitshares distribution is not simply the result of the snapshot of Protoshares at one point in time, but at all points in time: the wealth distribution is not set in stone; see the case of Nxt: the whole money supply was issued at launch. 70 people hold all of it and are just sitting on it, preventing any one from entering the market at a similar price.

Cons:
- You have to remember to keep an eye on the distribution of PTS to make sure it is not overly centralized.
- This might lead to an increase in the price of PTS, reducing the last pro, but if it is still easier to buy PTS than ASICs, I'll still consider this a success. Unlike ASICs, PTS do not age. EDIT: Also, no pre-orders.

5
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.

Wouldn't that generate an awful lot of network spam? At each block, each node would have to know what each other node has voted?


I have an idea based on a lottery system.

It requires the introduction of another type of coin-days that are reset after each block. I'll refer to as BCDs, for Block Coin-Days.

After a node receives a block, it takes the hash of the block and the hash of its Bitshares address, and applies a binary AND on them. The result is a speed of BCD gain per coin.
The node can then compute the number of BCD held by its address as a function of time: BCD = time_since_last_block * (block_hash AND address_hash) * number_of_coins.
It will broadcast a block when the amount of BCD reaches a target set by the protocol, depending on previous blocks. The block must reference the outputs used to generate the BCDs.


The idea is that the node with the highest BCD gain speed ((block_hash AND address_hash) * number_of_coins) will win. As time passes, it is more and more likely that someone will meet the target (like PoW), and the randomness prevents the biggest stake-holders from always publishing the block. They still have more chance of meeting the target though, since the expected value of the BCD gain speed is proportional to the amount of resources owned (also similar to PoW).
Unlike some other lottery systems addresses, this does not reward splitting your funds into multiple addresses.

Difficulty target can be initialized analytically to target a specific block generation time, as the distribution of Protoshares can be calculated at the genesis of Bitshares. However, I think target adjustment would have to be completely empirical afterwards (increase if blocks are generated too fast, decrease if too slow).
To help constrain block generation time, I think a polynomial weighting of time could be used (e.g.: use time_since_last_block^4 instead). If time_since_last_block < 1, it is harder to reach the target. If time_since_last_block > 1, it is easier. Stronger degrees increase this effect.

Latency is not an issue, given that if you receive two blocks, you can easily see which one met the target first. However, this implies using the sum of BCDs to determine the main chain (at least to some extent).

6
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

7
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.

8
Indeed, I think that vote by shares is the way to go. I am just unsure that spontaneous transactions are the best proxy for shares held, as it can be tightly coupled, but also completely decoupled. At the very least there should be an automated safety mechanism to try and reestablish dominance of your branch by destroying CD, should it become the shortest one, if you have been on that branch for long. I don't think most users would be able to override the detection of the longest chain to keep spending more CD on the legitimate branch.

PoS and PoW have similarities: if you want more power, you have to invest, either in ASIC or in shares. But then, unlike CD, hashrate cannot be saved for later. I think it would be nice to mimic this property, by having CD spent continuously on the branch you follow, like hashing power. Your idea of using transactions seems valid, and IMO is a generalization of PPCoin's PoS mining special transactions. What I propose is a reward for all destroyers of coin-days, proportionally to their coin-days destroyed, to reward them for securing the network, and the removal of the delay for CD regeneration, not to penalize transactions. What it means is that CDD/day is constant and equal to the number of coins that endorse a branch by "PoS mining" or spending on it, which is what you wanted to achieve with "votes by shares". As long as the main branch maintains more than 50% of the coins always "PoS mining" (EDIT: by honest nodes), your branch cannot be forked.

Quote
Lets assume that there is no delay in CD accumulation then an attacker with 1/50,000 of the money supply could spend enough CDD every other block to build 50% of the blocks on average. Putting a delay before CD start accumulating of 100 blocks means the attacker would only have 1% influence on block production assuming 1/50,000 of the money supply. 

Sorry I lost you there... You mean both the attacker who has 1/50,000 and the rest of the network that has 49,999/50,000 have the same influence? Unless I missed something, I think no delay only means that whoever has the most money wins, which seems fair in this kind of situation. If someone has more than 50% of the money then something is rotten in the Decentralization.

If I understood your paper well, I think your motivation to introduce the delay was to protect about people owning too many coins. But as you said yourself, if this happened, then any network would be vulnerable.

Unrelated remark:
Quote
Assuming you want to take on the role of securing the network, rather than just 'using the network' which is what 99% of users will be doing.  They may randomly profit when they happen to have the most coindays destroyed (because it is their first trx in a year).   So lets assume there is a certain base level of CDD providing security regardless of any other financial incentive.
No, this is just what an optimized client would do. Sooner or later it will be available to the public.

9
bytemaster,

Thank you for your clarifications, but I am not sure you can neglect time that easily when considering security.

1) The best usage of your CD is still to spend them when you are the most certain that you will be the biggest CD destroyer.

3) Let me try another, more graphic attack to show some issues and try to solve them.
I have 34% of the coins. I don't move them for a year, to get the maximum CD out of them. Then I transfer them all to myself. I am most likely the biggest destroyer of CD in the block. I don't sign it. Now 4 sub-cases:
a) You ban my output and start another block without it. Right after that, I broadcast my signed block. Now all the new nodes that are plugged into the network and were not there when you banned me will follow me, because I have the chain with the biggest CDD, and you cut yourself from it. They can also not trust your ban, since you look like the attacker.
b) You don't ban it and start another block without it. I wait for a year. During this year, the average coin is moved every 2 days. With the 1 day delay after each transaction, your 66% coins generated and destroyed less CD than my 34% had then. I publish the block I had saved, and instantly reverse 1 year of transactions. Note that the more you move your coins, the less I need coins.
c) You don't ban it and include it in your next block, signed by #2 CD destroyer. You are quite sure to be in the longest chain of CDD and I have lost all my CD, unless... I publish the block, which is what you wanted me to do in the first place. I must do it fast, because if I wait too much, you will add more transactions to your chain and your chain will be longer in CDD than I can make mine.
d) Same as c, but I lied and I actually had 40% of the coins. After you start on your version of the block with my 34%, I wait until you destroy nearly as much as my remaining 6% are worth in CD, and publish a block with my 6%. This might take long or not, depending on the volume of transactions.

Long story short, I think the delay on CD regeneration is dangerous, because it creates distortions that can be exploited both ways, and that counting security in CDD is quite impractical if CD are not destroyed linearly, as it exposes you to forks originating far in the past. If C coins have not moved since a date T, and CDD(T, now) coin-days have been destroyed between date t and now, then the chain can be forked back to its state at t by someone who controls the coins if:
CDD(t, now) < C*max(now-T, 1 year)
To prevent this, CDD must be high. However, due to the delay, it is faster to generate unspent CD than to destroy CD.
With no delay though, the fork that accumulates CDD at a faster rate is always the one that has the most coins backing it. If these CD were spent automatically, they would prevent forks, as well as the accumulation of CD required for a fork.

10
I think the whole concept of using transactions to secure the network is a little risky, especially during the infancy of a crypto. While there are not many transactions, the network is vulnerable. If everybody is sitting on their Bitshares, the first one to move will have a disproportionate influence. Conversely, after busy trading periods, the network will be depleted in CD because of the delay on CD regeneration after transactions. The network will be more vulnerable then as well.

The first flaw I can see in your proposal is related to this: if you only reward the biggest destroyer of CD, then you implicitly penalize the smaller. So to maximize their gains, the others will just keep their CD by hoarding old coins and spending new coins. Meanwhile the network destroys fewer coins and the network is insecure. You need to provide an incentive or a mechanism to ensure there will always be a steady flow of CD. If CDD fluctuates, the blockchain security is lowered, as periods of lower CDD are opportunities for cheap attacks.

Another thing to consider in your latest proposal is that it introduces a single point of failure (the broadcaster), even though you planned some backups.

It is quite vulnerable to a DOS attack. If an attacker were to score all the highest transactions in terms of CDD, he could delay the chain for long. The more fragmented the legitimate transactions are, the cheaper it is to attack the network.

So I think you should not restrict who can broadcast using such a serial scheme.

The issue with CDD in transactions is that they do not completely meet the non-reusability requirement that is necessary in PoW schemes, and probably in all blockchain structures. Transactions are tied to the previous block, but it does not matter what block they are included in, they are always valid. As a result it is trivial and cheap to generate a better block by simply adding a transaction to the original block. I think you need a way to make transactions depend on each other for this to work properly.

11
I think the vesting period is a brilliant idea to keep only interested investors.

However I cannot see why you would like to ruin hopes of profit for everybody by using a lottery system. Building on people's irrationality rather than rationality is a terrible choice in my opinion. This will unnecessarily decrease the attractiveness of Bitshares for rational people who are not already convinced, and I don't think many people like to think of themselves as irrational. As you have written yourself in the OP, miners who use only commodity hardware already have an edge over mass miners since they do not have an investment to recover, so I don't know why you go to such lengths.

I agree that Bitshares distribution should not reward the richest, but I think the problem can only correct itself. If there is profit to be made by cloud mining, then people will invest more into VPS, eventually lowering the profits until no one can get a ROI on hiring a VPS (provided the difficulty adjusts fast enough). But then there will still be profit to be made by single PC miners, who do not need any ROI, and they will be able to push VPS users out of the game, as the number of flesh and bones investors grows and the power shifts from mass miners to single PC miners.

If you want to restrict mining to home computers, consider involving a GPU in the proof of work. I had an idea like this: keep sealing the blocks with a CPU-only PoW, but also require some GPU-only work in the body of the block. If you are willing to surrender a little bit of decentralization, you could even make the GPU work something scientifically useful, like in Curecoin: you could make the reward of the block proportional to the points earned in a distributed computing project like [email protected] (with a cap and an adaptive exchange rate). Such scientific programs also run on CPU but much slower, so this penalizes cloud instances. ASIC are out of the question for such evolving applications. This leaves botnets: I don't think it would be very easy for a botnet operator to make a GPU scream without drawing some attention, but this is only supposition. The issue is that the point tally depends on a central authority. This could be alleviated by including other research programs. This also poses the question of how points are checked: each node of the network will need to check the points to validate the reward and the block, which will cause massive traffic on the websites of the scientific projects, and will look like a DDoS.

About decentralization, I think a giant, built-in P2Pool system could be the way to go. I am not too sure how it scales though. Pool difficulty must be high enough to avoid network spam, which means it would still be kind of a lottery system, but with lower variance. As far as I am concerned, if I am sure to get a reward at least once every 1-3 months, it could be acceptable.

Pages: [1]