Author Topic: A proposal to enhance UIA in order to make DACs far more powerful  (Read 8354 times)

0 Members and 1 Guest are viewing this topic.

Offline merlin0113

  • Sr. Member
  • ****
  • Posts: 286
    • View Profile
arhag can you code? You have lots of ideas but your posts are often so long that I don't think anybody reads them. It would be useful if you could express these ideas in a more succinct way and/or possibly actually develop them.

I do read every post arhag is writing , and it does not matter how long it is, everything he's posting, to these day I've never find a fault All he's ideas have some "aha" moments for me. I will venture to say that second to bytemaster and Stan, it is arhag posts that I'm looking the most to read. Whatever he writes brings a lot a value to our forum and bitshares. It is so very few people that can understand this deep this amazing technology, that you, vikram, and I3 team are working so hard to develop.

 Your point it is fair tough I can't imagine how valuable will be arhag  in developer team ! ! I thing he should be a 100% delegate except probably he does not want it right now.

So arhag what it will take for you to be a 100% paid delegate ?  I'm pretty sure you'll have no problem to get all the votes you need.

I feel the same!

来自我的 M040 上的 Tapatalk


Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
I would change it to remove the panic consensus part as that is quite subjective and open to gaming.

That would destroy the entire security model! Then you are trusting the entire reserves to 101 individuals only. The gaming is hopefully solved by the tax on their stake if they call a false panic.


I'm imagining a future where thousands of heterogenous organisations could be operating within the BitShares system, and many private and common-use block-chains could be employed by by that organisational network, with the need to transfer and communicate between them **. A general problem to deal with will be that of delegated authority. Delegated authority is a common organisational problem where authority (and with it trust) over certain assets (or even votes and other intangibles represented on a block-chain) is delegated to another person or entity to manage. Traditional examples could be shareholders delegating to managers, managers delegating to subordinates, members delegating to boards, or the public delegating to their voted representatives. It would be useful to have flexible tools that could allow enough variation to deal with a wide number of preferred decision structures.

In that context, it seems the idea of a panic consensus is one method for dealing with the more general problem of managing delegated authority. But is the panic consensus described the most generalised form, or is it a specific form of a more general group of settings of ensuring security in cases of delegated authority? If the latter, what are the more basic ingredients? I have no view on whether it is or is not, but it would be beneficial if the settings of the IUAs allowed as much flexibility as possible for organisations to implement whatever security structures they can conceive of and agree to.

** (as an aside, it would make an interesting conversation at some point to think about how block-chain technology will most likely be implemented by society in the future, as that can lead us to design the appropriate tools and structures)


Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I would change it to remove the panic consensus part as that is quite subjective and open to gaming.

That would destroy the entire security model! Then you are trusting the entire reserves to 101 individuals only. The gaming is hopefully solved by the tax on their stake if they call a false panic.

New version: The person sending assets/BTS can define a block height for when that transaction 'clears' in the recipients account. The outputs created by this transaction cannot be spent until this blockheight and in the mean time the sender can choose to invalidate the transaction.

The problem is that this information is on the child blockchain not the parent blockchain. The parent cannot look at the child blockchain for scalability reasons. The only authority for the information of what is going on in the child blockchain are the super majority of the currently registered managers of the UIA (who should also be the delegates of the child DAC) and, as a backup measure, the stakeholders who can call a panic if the managers lie.
« Last Edit: February 17, 2015, 03:39:56 pm by arhag »

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
arhag can you code? You have lots of ideas but your posts are often so long that I don't think anybody reads them. It would be useful if you could express these ideas in a more succinct way and/or possibly actually develop them.

I do read every post arhag is writing , and it does not matter how long it is, everything he's posting, to these day I've never find a fault All he's ideas have some "aha" moments for me. I will venture to say that second to bytemaster and Stan, it is arhag posts that I'm looking the most to read. Whatever he writes brings a lot a value to our forum and bitshares. It is so very few people that can understand this deep this amazing technology, that you, vikram, and I3 team are working so hard to develop.

 Your point it is fair tough I can't imagine how valuable will be arhag  in developer team ! ! I thing he should be a 100% delegate except probably he does not want it right now.

So arhag what it will take for you to be a 100% paid delegate ?  I'm pretty sure you'll have no problem to get all the votes you need.

you nailed it! Same in my side!
Your posts are just refreshing me and giving me a differnt view on things!

 +5%

p.s.: i would definitely vote for you as a 100% Delegate!

Keep up your great work!
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline monsterer

I would go one further here and apply this to all assets, including BTS.

I would change it to remove the panic consensus part as that is quite subjective and open to gaming.

New version: The person sending assets/BTS can define a block height for when that transaction 'clears' in the recipients account. The outputs created by this transaction cannot be spent until this blockheight and in the mean time the sender can choose to invalidate the transaction.

This puts all the trust on the sender, removes the complexity of social gaming and allows entities such as BTER to cancel hacked withdrawals if they spot them in time. In addition it satisfies the legal requirements for UIAs which are partially implemented as it stands.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline BunkerChainLabs-DataSecurityNode

+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline vegolino

  • Sr. Member
  • ****
  • Posts: 450
  • Reality is Information
    • View Profile
Quote


I have no such plans for the foreseeable future.

Why?

You obviously care a great deal. You have the ability to code and Bitshares has the need.

I am sure you have RL obligations but a I would argue that a arhag working at even quarter impulse is better then sitting at the dock.

+5%
+5%
+1
+5%


Offline oco101

  • Hero Member
  • *****
  • Posts: 586
    • View Profile
Quote


I have no such plans for the foreseeable future.

Why?

You obviously care a great deal. You have the ability to code and Bitshares has the need.

I am sure you have RL obligations but a I would argue that a arhag working at even quarter impulse is better then sitting at the dock.

+5%
+5%
+1

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Quote


I have no such plans for the foreseeable future.

Why?

You obviously care a great deal. You have the ability to code and Bitshares has the need.

I am sure you have RL obligations but a I would argue that a arhag working at even quarter impulse is better then sitting at the dock.

+5%
+5%

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
Quote


I have no such plans for the foreseeable future.

Why?

You obviously care a great deal. You have the ability to code and Bitshares has the need.

I am sure you have RL obligations but a I would argue that a arhag working at even quarter impulse is better then sitting at the dock.

+5%

Offline Gentso1

  • Hero Member
  • *****
  • Posts: 931
    • View Profile
  • BitShares: gentso
So arhag what it will take for you to be a 100% paid delegate ?

I have no such plans for the foreseeable future.


Why?

You obviously care a great deal. You have the ability to code and Bitshares has the need.

I am sure you have RL obligations but a I would argue that a arhag working at even quarter impulse is better then sitting at the dock.
« Last Edit: December 29, 2014, 07:09:23 pm by Gentso1 »

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I just read this, and this sounds much better than DevShares.

This and DevShares aren't mutually exclusive. If DevShares was to be implemented as sidechain it would still require its own client, its own stake (and we would still have to decide how to distribute the stake), and its own managers/delegates.

Furthermore, DevShares is an example of a DAC I would not create as a BTS sidechain, because its whole purpose is to test all BitShares functionality. If it was a sidechain its consensus system would not be operating the same way as that of the parent BitShares DAC and also it would not be issuing its own DevUSD into existence through matching shorts and longs.

That said, there would be a place for other child sidechain DACs that experiment with interesting concepts before they get implemented into DevShares for the necessary upgrade testing before they are moved into BitShares. Or alternatively we could decide that those features aren't interesting enough to move into the parent BitShares blockchain (or perhaps it would bloat the BitShares blockchain too much) and instead just keep it in the sidechain.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I just read this, and this sounds much better than DevShares. Too bad that it got lost in this subform?

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
I agree about arhag never saying anything bad or wrong.  Yet I also have a hard time bringing myself to read so many of his posts.  He appears to not be that good at conveying his complex thoughts which is understandable.

Arhag,

I'd suggest breaking up your proposals into steps so that when people are trying to grok the idea it is easier given the context.  When everything is thrown into large paragraphs it becomes harder to follow the logic behind it.  If one loses the train of thought it is harder to go up or down a step in the process because it is all in large paragraphs.

Put your ideas into more manageable chunks with like a core example perhaps?  Then after an example go into the pros and cons?  Something like that....
I speak for myself and only myself.