Author Topic: Profits, Performance, Trust & Efficiency  (Read 58095 times)

0 Members and 1 Guest are viewing this topic.

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: puppies
What separates bitshares DACs from other alt coins is that bitshares DACs are designed to be profitable.  If using a metronode system means that transaction speed goes from 5 minutes to under 30 seconds, it becomes more attractive to traders.  Faster transactions mean more transactions, and more transactions mean more dividends from fees.

It also introduces numerous problem that have been listed above.  I am admittedly not Bitshares-x target audience though.  Bitshares seems to be much more decentralized than a standard (very centralized) exchange, with the same or similar abilities trade wise.  An improvement for sure, but I would still prefer a pure POS solution.  Even if it has slower transaction times, or I have to wait for confirmations.

It seems clear that Bytemaster has had a less centralized solution than a single metronome in mind all along, and has used the past few days to get us used to the idea of a single singing authority so that when he tells us there will actually be 8 and it will require a signature from at least 2 to form a block we will all be ecstatic.

None of this bothers me.  What I really don't like is the introduction of politics into the mix.  Its not the lack of decentralization.  That is of course a relative term, and is only a means to an end.  The end is the distribution of power.  Lessening the abuses of authority. 

Ultimately what we are trying to do here is to build systems that relies on the idea that even if I don't trust you, and you don't trust me, since we both trust the blockchain we have a mutual point of agreement, and a basis for doing business.  I can trust the blockchain because I can read the source code and compile it myself.  (It would admittedly take me awhile, my c++ is quite rusty, and I would have to trust some of the cryptography sections unless I wanted to spend some serious time digging in)  Alternately I could pay someone I trust to check this for me.  Adding a human element (voting, metronomes) seems to weaken this.  You're adding an unknown to the mix; human action.

Of course I know human action plays a part in the way a POW or POS system works.  I also know that all other individuals will be doing what they believe to be in their own self interest.  Whether those interests are moral, monetary, or physical, increasing the distribution of block singing power makes its much harder to apply the pressure needed to make those individuals act against their financial self interest in the dac.  Or more accurately stated it requires much more pressure applied much more widely.

As always I had plenty more to say, but lack the time and patience to attempt to make it understandable. 
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline sschechter

  • Sr. Member
  • ****
  • Posts: 380
    • View Profile
What separates bitshares DACs from other alt coins is that bitshares DACs are designed to be profitable.  If using a metronode system means that transaction speed goes from 5 minutes to under 30 seconds, it becomes more attractive to traders.  Faster transactions mean more transactions, and more transactions mean more dividends from fees.
BTSX: sschechter
PTS: PvBUyPrDRkJLVXZfvWjdudRtQgv1Fcy5Qe

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile

The good news is that I have a proposal that is more decentralized than a single Notary and a similar level of decentralization as bitcoin.

Good to know. Hope your new proposal could get the community in line.
« Last Edit: April 01, 2014, 10:36:27 pm by heyD »

Offline bitbadger

  • Full Member
  • ***
  • Posts: 95
    • View Profile
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.)
Pei5BrnEUqcCuUdffNZmBPL3rg6duj3vnU

Offline bytemaster

Quote
It seems to me that you are trying to solve a problem that the Bitcoin devs have not even implemented a solution for. (How to stop forks and the 51% attack)

Yes, I am trying to solve a lot of problems Bitcoin hasn't solved.

Quote
Why not just form a traditional corporation?

Regulatory issues and that would be more centralized than I am suggesting.  It would have so many problems I wouldn't know where to begin.

Quote
How are you going to get people to devote their own computing resources to secure the blockchain?

The network isn't secured by computing resources.

Quote
but it seem to me that the plan for development and implementation of Bitshares-X has gone off on a dangerous tangent.

I see this as no tangent, but critical to the design goals.  Forks are more harmful (even short ones) for BTS X due to the market being built in. 

The good news is that I have a proposal that is more decentralized than a single Notary and a similar level of decentralization as bitcoin. 
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 Led

  • Newbie
  • *
  • Posts: 4
    • View Profile
The result is like a 'constitutional company' where the laws are entirely defined in the constitution and the 'president' can be recalled at any time and has almost no power even when in office.

This same process can be used to resolve when a hard fork goes into effect.   

Thoughts?

It seems to me that you are trying to solve a problem that the Bitcoin devs have not even implemented a solution for. (How to stop forks and the 51% attack)

I don't think security is a problem if the companies operating within the framework of the DAC double check their transactions manually.

Yes, a DDOS could still shut down the network for a while, so I guess you just have to buy some DDOS protection from an external source. Is this doable?

You want to remove mining from the equation? Why not just form a traditional corporation? It seems to me that is what you're getting at anyway. You already control the code, so you control everything anyway. How are you going to get people to devote their own computing resources to secure the blockchain?

I have a stake, so I want it to be done right, so take as long as you need to figure out how to implement Bitshares-X. You've already taken the snapshot, perhaps to stimulate interest and discussions like these, I don't know, but it seem to me that the plan for development and implementation of Bitshares-X has gone off on a dangerous tangent.

Am I right? Am I wrong? Am I partially wrong? Am I completely wrong?

The idea of Distributed Autonomous Applications/Companies/etc are important, I think, for the future and freedom of the internet. What are you doing to this end? Is hacking together a bunch of legal rules in a legal off-chain document going to serve this purpose? Does it even serve the purposes and interests of the shareholders?

Offline Led

  • Newbie
  • *
  • Posts: 4
    • View Profile
The result is like a 'constitutional company' where the laws are entirely defined in the constitution and the 'president' can be recalled at any time and has almost no power even when in office.

This same process can be used to resolve when a hard fork goes into effect.   

Thoughts?

It seems to me that you are trying to solve a problem that the Bitcoin devs have not even implemented a solution for. (How to stop forks and the 51% attack)

I don't think security is a problem if the companies operating within the framework of the DAC double check their transactions manually.

Yes, a DDOS could still shut down the network for a while, so I guess you just have to buy some DDOS protection from an external source. Is this doable?

You want to remove mining from the equation? Why not just form a traditional corporation? It seems to me that is what you're getting at anyway. You already control the code, so you control everything anyway. How are you going to get people to devote their own computing resources to secure the blockchain?

I have a stake, so I want it to be done right, so take as long as you need to figure out how to implement Bitshares-X. You've already taken the snapshot, perhaps to stimulate interest and discussions like these, I don't know, but it seem to me that the plan for development and implementation of Bitshares-X has gone off on a dangerous tangent.

Am I right? Am I wrong? Am I partially wrong? Am I completely wrong?

The idea of Distributed Autonomous Applications/Companies/etc are important, I think, for the future and freedom of the internet. What are you doing to this end? Is hacking together a bunch of legal rules in a legal off-chain document going to serve this purpose? Does it even serve the purposes of the shareholders?

« Last Edit: April 01, 2014, 07:49:09 pm by Led »

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
The problem with delegation chains is that we will end up with essentially the same situation as Bitcoin: a mining cabal of ~15 individuals who have accumulated power, and whose decisions can affect everybody.  The "votes" will end up concentrated in the hands of a few individuals, who will all be well-informed and well-connected, but essentially you could end up with all kinds of bribery and corruption.  Say we've got 2 main candidates for Trustee, at 52% and 48%; you know the guy with 48% will be lobbying all of the 5% holders to change their vote and make him the Trustee.  Hell, the 5% guy may end up getting his jollies switching from one Trustee to the other with each block!  And sure, eventually the people who had delegated their votes to the 5% guy will switch away, but they're probably not going to get any immediate signs that something's going wrong.

I think it's a critical difference is that because stake-miners have no economies of scale there is no centralization of mining power per individual. Less opportunity for "cabals" to form because their is more fluidity at all level of the hierarchy.

Maybe you need to be able to use your vote *against* someone. Then the reddit hivemind can protect the network by downvoting bad trustees! =D
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline bitbadger

  • Full Member
  • ***
  • Posts: 95
    • View Profile
I'd prefer to trust in my ability to protect my private key than to trust a trustee. A digital company shouldn't require any voting or representatives to vote on behalf of shareholders. Otherwise it defeats the purpose of calling it a DAC because it is no longer autonomous in the slightest sense because instead of the code taking care of that now we have to rely on people.

Agreed!  Not to mention that any "voting" implies human agency as well as rapid and accurate dispersion of information, like we're all going to be sitting at our BitShares consoles all day, and browsing the BitShares forum all day, ready to change our vote if something bad happens, because the only way that we can be sure that something bad is happening would be to talk about it with others and see if they're seeing what we're seeing.  And there's going to be plenty of potential for rumor-mongering, scare-mongering, and other kinds of Social Engineering.  Not to mention just plain whining, "I submitted my transaction at 10:25 and it wasn't included in a block until 10:29, waaah waah, the trustee is blocking my transactions!"

With proof of stake your private key is your proof.   


Sent from my iPhone using Tapatalk

Do you mean private keys have to be risked with POS (forging) because they can not be used for forging when they are in cold storage?

They don't if you can sign for a delegate! Keep 90% in cold storage and have your 10% hot wallet sign for all of them. You could easily have revocation keys so you wouldn't have to take your shares out of cold storage to take away the voting power if your hot wallet is swiped.

I was thinking something similar.  Why couldn't you link your address to another address that has zero coins assigned to it.  You could then put your real wallet into cold storage and the empty wallet could provide security through POS.  If someone hacks my PC they would only get my voting power, and only until I pulled my wallet out of cold storage and used it to sign a new block with a new link.  Am I making sense?  Could this work?

Yes, one of the coins (I forget which) has a "Savings Address" (like a Savings Account vs. a Checking Account) where the Savings Address transactions are recallable/cancelable for a certain amount of time, and transaction output must go to a certain address (the "Checking" address) and to no other.  In this case, the Savings Address could assign its Stake-Days to the Checking Address, but the Savings coins themselves could be kept in a cold wallet.

I don't know that I completely understand the power that the trustee(s) have and what happens if all trustees colluded.  But, I'm willing to reserve judgement if you think it's the best system and give it a shot.

I think that if the mechanisms are not well communicated there would be a lot of FUD that would affect initial demand/value.

A trustee is just a node that asserts it saw a block by signing it. It stops forks, but gives the power to stall the network OR perform a double-spend with cooperation of a large number of shares. They would get caught though, which is actually really important.

I think that some of the concern about forks is over-wrought.  In traditional PoW coins like Bitcoin, the blocks themselves might be different, but the transactions in the blocks are largely the same.  Most importantly, the ordering of transactions can never be switched because the inputs must be validated by the miner (and indeed, all nodes).  If I've got 2 chained transactions A->B, B->C, both of those transactions can be included in the same block, or A->B in the first block, and B->C in the next, but never B->C then A->B because B will not have the input from A, and it will be rejected.

Without a trustee all other technical solutions are attempts to do the following:
1) Randomly select someone proportional to their stake in the system... they become 'trustee for a block'.
2) Pay / Punish this person for not producing a block.

As I have suggested in the past, the "Punish" option is not necessary: you could simply negate the "Stake-Day Destruction" that would have happened if they had won the block, so they can try again.  The Stake-Days are only destroyed when a block is created with those coins, and the Stake is associated with the coins, not the address.  In the imagined "send a large transaction from myself to myself in order to try for a PoS block" scenario, the same user ends up with the same stake as before, just in a different address.  If they create a transaction with a large number of Stake-Days with one of the outputs being another user's address, the recipient will now hold the Stake (and they might end up being the miner of the new block, based on receiving that Stake).

As soon as you have this random selection you simultaneously open up the network for random attacks by anonymous parties.  The sheer number of hypothetical attacks that are possible under these 'random selection' processes means that the network is likely less secure and predictable.   All of a sudden people start mining blocks that exclude bids/asks to their benefit or to trigger margin calls.   Put another way, randomly selecting people to produce blocks gets you 'average' performance and 'random' manipulation.   Delegating through your proof of stake to a trustee maximizes the predictability and fairness of the chain. 

This seems hand-wavey, is there an example of an attack which would work better on a bunch of random nodes than one one central, known node?  (Even if they had backups and multiple network locations, that's still a much smaller number of targets than the potential entire network.)

Effectively 'delegation' using your stake is exactly what I am proposing.   Person A delegates to person B, who in turn can delegate to person C.   Eventually all of the delegates have to arrive at a 51% consensus on who produces the next block.   If someone sets up some software in a 'set it and forget it' manner then the network is perfectly safe unless this person is attacked.   If they are attacked then the network can quickly appoint (probably pre-arranged) the fallback. 

At any time someone with stake can change who they delegate their vote to. 

If we can stay objective here and identify what attack we are afraid of and define what we are attempting to defend against in the most clear way possible then we can find the best solution.   Get to the *root* of the problem and solve that.

Without getting to the root we have solutions in search of problems and we end up paying for things that we do not need or even want (mining).

The problem with delegation chains is that we will end up with essentially the same situation as Bitcoin: a mining cabal of ~15 individuals who have accumulated power, and whose decisions can affect everybody.  The "votes" will end up concentrated in the hands of a few individuals, who will all be well-informed and well-connected, but essentially you could end up with all kinds of bribery and corruption.  Say we've got 2 main candidates for Trustee, at 52% and 48%; you know the guy with 48% will be lobbying all of the 5% holders to change their vote and make him the Trustee.  Hell, the 5% guy may end up getting his jollies switching from one Trustee to the other with each block!  And sure, eventually the people who had delegated their votes to the 5% guy will switch away, but they're probably not going to get any immediate signs that something's going wrong.

My hopes for BTS were not just about decentralization per se.  They were about removal of trust from any individual, or group of individuals.  Trust only the code, because you can read the code and bash the code and improve the code yourself.  Now we have to trust some set of individuals to make the right decisions?  That's BS.  I mean hell, I'll just quote Stan's definition of a DAC:

Quote
Distributed Autonomous Corporations (DAC) run without any human involvement under the control of an incorruptible set of business rules. (That’s why they must be distributed and autonomous.) These rules are implemented as publicly auditable open source software distributed across the computers of their stakeholders.
  (Emphasis added)

I know this was a long-ass post, I'm sorry but I wanted to get my thoughts out there.  I'm not even done catching up on this thread but I've got to go.  I have very serious concerns with this new direction.  I know that I'm just one voice out of many, but hopefully some of my thoughts will make a difference.
Pei5BrnEUqcCuUdffNZmBPL3rg6duj3vnU

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
Recognized by algorithm.

Transactions will not get lost if they can be migrated.   


Sent from my iPhone using Tapatalk

For example, blocks 101 & 102 generated by A are recognized as 'illegal' blocks, then another timekeeper B is selected to take charge.

1. Are you confident enough to say the 'illegal' blocks can be recognized within several blocks ?

2. Will B start with block 100, then migrate the legal transactions contained in old 101 &102 to the new 101 &102 ?

3. What if B is also hacked or dishonest? Is the network/algorithm strong enough for the next timekeeper C to distinguish the legal transactions contained in the pre blocks 101 &102 generated by A and B since the chain has been forked twice.

A time keeper could make any choice he wanted... probably going with the first transactions he saw.

Em.. I am confused.  If the timekeeper could make any choice he wanted,  doesn't it mean that the legal transactions in the illegal blocks get lost (if he abandons these blocks ), or the illegal transactions get confirmed (if he continues with that chain)?

Offline Stan

  • Hero Member
  • *****
  • Posts: 2908
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BitShares: Stan
It would be a nice touch to have a rotary-notary spanning 5 continents...
Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

sumantso

  • Guest
I still don't how exactly is the voting done. Is it like actually voting where some candidates make them known (in these forums, say), and we vote? If that is done, doesn't it make sense to start with I3 as the timekeeper anyways? I don't know anybody else but obviously trust I3.

Offline bytemaster

Recognized by algorithm.

Transactions will not get lost if they can be migrated.   


Sent from my iPhone using Tapatalk

For example, blocks 101 & 102 generated by A are recognized as 'illegal' blocks, then another timekeeper B is selected to take charge.

1. Are you confident enough to say the 'illegal' blocks can be recognized within several blocks ?

2. Will B start with block 100, then migrate the legal transactions contained in old 101 &102 to the new 101 &102 ?

3. What if B is also hacked or dishonest? Is the network/algorithm strong enough for the next timekeeper C to distinguish the legal transactions contained in the pre blocks 101 &102 generated by A and B since the chain has been forked twice.

A time keeper could make any choice he wanted... probably going with the first transactions he saw.
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 muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
Recognized by algorithm.

Transactions will not get lost if they can be migrated.   


Sent from my iPhone using Tapatalk

For example, blocks 101 & 102 generated by A are recognized as 'illegal' blocks, then another timekeeper B is selected to take charge.

1. Are you confident enough to say the 'illegal' blocks can be recognized within several blocks ?

2. Will B start with block 100, then migrate the legal transactions contained in old 101 &102 to the new 101 &102 ?

3. What if B is also hacked or dishonest? Is the network/algorithm strong enough for the next timekeeper C to distinguish the legal transactions contained in the pre blocks 101 &102 generated by A and B since the chain has been forked twice.
 
« Last Edit: March 31, 2014, 05:01:21 pm by heyD »

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
Assumptions:
With the shares system we have an easy way to vote on anything.
With the TaPOS system the transaction ledger becomes immutable automatically over time as the ledger is confirmed by everyone on the network.
Generating the next block should be as efficient as possible to maximize dividends.
Transaction validation should be as quick as possible.

Solution:
Shareholders vote (off chain) on a trustee.
Trustee generates blocks every 30 seconds (or at will..... no need to require any particular rate)
If trustee is compromised or shutdown, shareholders can elect a new trustee by broadcasting their vote.
Once a new trustee has 51% of the shareholders support the network continues.

As a trustee you cannot double spend (you will be caught and fired).
As a trustee you cannot perform Denial of Service without being caught and fired.
As a trustee you cannot be coerced without being let go.

As a shareholder this maximizes your value (dividends, transaction speed, no potential of forks).

A trustee is not a paid position and requires almost no resources to run.  A trustee could even operate behind a tor node.

The result is like a 'constitutional company' where the laws are entirely defined in the constitution and the 'president' can be recalled at any time and has almost no power even when in office.

This same process can be used to resolve when a hard fork goes into effect.   

Thoughts?
Bytemaster, it's a great idea, I like it very much, thank you!