First of all the largest shareholder in BTS systems has less than 10% and the remaining shares are divided among 1000s.
You have no way of knowing this, because you have no way of knowing the owners of the BTC and PTS addresses. Could be one guy with 1000s of addresses. Of course we can be pretty sure that it's more than one guy, just based on the people in this forum, but there could easily be far greater concentration than you are aware of at this moment.
Everyone participates in securing the network and making it immutable. No other system has this property of being immutable because it is always possible to mine longer alternative chains whether it is POS or POW. No other system has as every shareholder participating in the securing of the network and ultimately ratifying the ledger. You could say that TaPOS means that eventually every transaction is confirmed and ratified by 90% or more of the shareholders.
Mining a longer alternative chain in PoS would require very significant ownership in order of having a good chance of mining 2 or more blocks in a row. I'm pretty sure that it is way more than 51%. This is because stake is reset to 0 when a block is mined. If you have a large number of coins held by a single address, ok, that's a large stake, but it's all reset to 0 when a block is mined, so there is no chance for that address to mine the next block. If you have a large number of coins held by multiple addresses all owned by the same attacker, that's more possible, but because each of these will be reset to 0 each time, the number of blocks in a row that can be mined is very limited. Each address taking part in the attack will need to have more stake than the rest of the network combined. So the first address used in the attack will need to have 51% of all stake; the second address used in the attack will need 25%; the third address used in the attack will need 13%; and so on. So for an attack to be successful for one block, the attacker needs 51%; for two blocks, they will need 76%; for 3 blocks, they will need 89% of all stake. (Of course, this is different than owning 89% of all coins, but you get the idea.)
(Side note: It would be nice to have, somehow visible within the interface or on a website or whatever, a list of all current stake. That way we could see if stake is being built up somewhere.)
(As another thought about stake: How about making an increase in stake dependent on running a node? I don't think that this has been done before. Every block has a hash. Let's say the hash starts with ABC. Every node with address matching AxxxxxxBxxxxxxC (or some other formulation) must "check in" by sending a transaction to themselves to prove that they're connected. This transaction does not lose stake-days or coin-days, and in fact it is required in order for stake-days to be increased, which will be proportionate to the timestamp of the last block they had to "check in." If they do not "check in" within 10 blocks of the triggering block, their stake-days drops back to 0. This would prevent people from accumulating stake by simply keeping their coins dormant. In this way, NOBODY could ever accumulate significant amounts of stake; the top stakeholder would always be the most likely to produce the very next block, because they are verified connected to the network. Yes, this will require people to keep their wallets unlocked for staking. This is how all PoS coins currently work anyway. Perhaps an arrangement can be found with custodial addresses which can remain be unlocked and have 0 coins, but "manage" the stake for other addresses, at perhaps some loss to privacy.)
You could say no, they only need for each individual stake address to have more stake than any other individual address. So say that
the attacker has 5% stake in one address, 4% in another, 3% in another, 2% in another, and all individual addresses in the rest of the network only have 1% or less. The mining of a stake block is still a stochastic process. Having the largest stake does not mean that you are guaranteed the next block. The only way to guarantee it is to have 51% of all stake. (However, in the implementation of PoS that you had previously developed which depended upon transactions and coin-days-destroyed to determine who gets to mine the next block, I suppose the mining process is more deterministic. I can kind of see that you might have painted yourself into a corner by doing PoS-by-way-of-transactions instead of a more standard PoS implementation.)
There are two kinds of decentralization: power & redundancy.
Again, I would refer to the "autonomous" part of "DAC". "Autonomous" means "without human intervention". "Autonomous" means that I trust the code, not a person. I don't trust one copy of the code doing a particular thing (being the trustee/timekeeper/whatever), and my copy of the code doing something else (running a regular node); I trust that EVERYBODY has the same code and is doing the same thing. That's what Peer-to-Peer is all about. An at-least-nominally-equal playing field for every user. Now you're proposing to make some users "more equal than others". Not cool.
I touched on this last night, but I am really not seeing the "forks" problem. The fact is, most forks create blocks which contain the same transactions. As long as the transactions are recognized as valid by all nodes, a fork is not going to screw anything up.
I create a transaction. That transaction is passed to my peer nodes, who pass it to their peer nodes, etc. until it's propagated throughout the network. All nodes keep this transaction in their transaction memories, let's call this a TIM, Transaction-In-Memory. All nodes know about this transaction after a fairly short time and keep it in their TIM register. That is, until that transaction has been put into a block and that block has been confirmed by some number of blocks. If we are concerned about forks, we can make that number high, like 50 blocks for a transaction to fully confirm and it is removed from the memory of the nodes, and its place in the blockchain is solidified, so all references to that transaction now refer to the blockchain instead of the TIM.
Importantly, all nodes verify these transactions before they are added to the blockchain. In theory, any transaction which is not eligible to be placed in the blockchain will not be propagated at all. So again let's take a chained transaction pair, A->B and B->C. As long as A->B has propagated throughout the nodes and is held in the TIM registers of the nodes, all nodes will recognize B->C as a valid transaction, whether or not A->B has made it into the blockchain yet. If A attempts a double-spend and creates a second transaction A->D with the same inputs, all honest nodes will reject this transaction and not propagate it, because those inputs had already been used in the A->B transaction which already exists as a TIM.
Now what happens if A creates A->B and A->D simultaneously, and sends them to separate peer nodes, so A->B propagates through part of the network and A->D propagates through the rest of the network. So then you have half of the network saying that A->B is correct and rejecting A->D (and therefore accepting B->C since there are valid inputs into B), and the other half saying that A->D is correct and rejecting A->B (and therefore rejecting B->C).
Now, we have several ways to resolve this. The simplest one could simply be to see whichever one makes it into the blockchain first; if A->B happened to propagate first to the node that mines the next block, it will be included; and vice-versa with A->D. A somewhat more complicated but perhaps more honesty-enforcing way to deal with it would be for A->B and A->D (and any further transactions with the same inputs) to be immediately rejected (and kept in memory in a "rejected" list for a short while; perhaps A could be blacklisted as an attempted double-spender, at least for a few days). Remember, we know that A->B and A->D had to have both been initiated by A due to cryptographic signature, and any legit client software would not allow the double-spend to occur in the first place, so A would definitely be a bad actor in this case. Of course, there is always the chance that one of the two transactions would be put into a block first anyway, before the miner knows about the 2nd transaction.
The great thing about PoS mining is that 51% attacks are not possible without owning 51% of the stake; and the only real way for forks to matter is for somebody to be able to execute a 51% attack. (To refresh everyone's memory on a 51% attack: the attacker's (A) hashrate is faster than the rest of the network (B) combined. Therefore, they can produce blocks at a faster rate than the rest of the network combined. They propagate a transaction, A->C, on the B network, where it gets included in a block. C then believes that they have received payment from A. The B network can continue producing blocks and confirmations of the A->C transaction. C becomes more comfortable with the payment from A as the transaction gets confirmed multiple times. In the meantime, the A network is producing blocks faster than the B network, and keeping them hidden from the B network. The A network includes a transaction A->D, with the same inputs as A->C. At some point, once the A network has produced more blocks than the B network, the A network releases its produced blocks to the B network, and they must be accepted since the A blockchain is longer than the B blockchain. This new blockchain has A->D but does not have A->C. So C is out the coins that he thought that he had. This is a problem if, say, C is an exchange, and had credited those coins to A, who then traded them for other coins and withdrew them from the exchange, and then the exchange is left in the lurch because they are missing the coins they thought they received from A.)
Show Posts
