The Account Creation Decentralized Autonomous Cooperative is Ready for Test/Iterate Cycles

avatar
(Edited)

Introduction

image.png
Recently I published some information about the DAC I've been working on to solve some of the on boarding issues that Steem has.

Now it's time to discuss how the whole program works and why any account wanting to onboard people to STEEM may want to run this or take advantage of this program in other ways.

Configuration

At a minimum this program will require your Steem name and active key. The active key is required to sign delegation and and Account Creation Token, ACT, operations. There are a few other variable that can be user defined but the current market rate information is the default.

You can find out a little more about this at the Github repository

Initial Startup

There is an initial state that is programmed in to the system. As people start using the DAC their accounts will place custom JSONs with IPFS hashes of the agreed upon state into Steem. This means that any account running this software should have at least 150 SP. Once anybody is running this software and a consensus is formed the accounts will start to work together. Simply starting this program should auto-join the network (Line 502), restart with consensus information (Line 743 / 518). Then begin to work together.

Multi-Sig Escrow

Due to the collaborative nature of this software and guidance put out by certain governments it was imperative to build a networked fund. This means that interacting with the DAC will be done through a shared multi-signature account.

To make this possible several things had to be built and programmed that from my knowledge didn't yet exist.
Daily; the accounts cooperating with the DAC will be pushed one by one on to a multi-signature account. This will be done via polled active public keys. Currently up to 11 accounts will be autonomously elected to share the responsibility of the funds.

To autonomously sign multi-sig operations these accounts will poll data such as a time each believes is 9 minutes in the future as well as reference block and prefix numbers. Every 5 minutes with consensus these will be counted and one set of expiration time/ block number/prefix will be used to build a multi-sig transaction. This means that these operations will not be passed between the parties... and just the signature for the operations will be submitted in the 5 minute period custom json used for consensus. Once the threshold of signatures is collected the operations will be broadcast to Steem. These multisig operations will be payments for creating accounts and completed delegations to these new accounts.

Review and Feedback

This software is ready for test iteration and is NOT ready to be deployed on Steem as is. I would love to find interested parties to help with the testing and refining of this software... not only for the the backbone distributing ACTs but for all third party trusts that are currently on steem. For instance the account currently holding @steemp for Steem-Engine can use this multi-signature paradigm to alleviate the only real legal concern their platform has currently.

I'm specifically asking for @yabapmatt, @blocktrades, @oracle-d / steem-ninja, @gtg, and @stoodkev to look over this software and ask questions so we can start building software and communities with higher legal and technical resilience using these paradigms.

As always this is part of my work that I'm trying to be paid for with the SPS via Proposal 11. Which you can Approve via this Steemconnect Link



0
0
0.000
8 comments
avatar

Congratulations @disregardfiat! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :

You distributed more than 900 upvotes. Your next target is to reach 1000 upvotes.

You can view your badges on your Steem Board and compare to others on the Steem Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

To support your work, I also upvoted your post!

Vote for @Steemitboard as a witness to get one more award and increased upvotes!
0
0
0.000
avatar
(Edited)

Interesting! I've scanned broadly over the code, but I will take a more detailed look at it once I've got a bit more time on my hands, but generally speaking: using multi-sig for account creation is very much needed. And any work in that area is highly appreciated in my opinion.

Regarding your proposal: it's always better to have leaner and more detailed proposals, rather than one that somehow does everything.

0
0
0.000
avatar

Again, I don't understand the problem you're trying to solve. Creating an account, I get. You're skipping some key things because I don't see how custom_json + IPFS are involved in account creation. I suspect it has to do with storing application code and assets. But that hasn't been defined as a thing anyone needs.

I get that there's a VR demonstration that makes use of this. But from what I can tell, it's really just a clunky blockchain explorer.

I just can't get behind your proposal if there's no obvious use case for it. I do not dispute that there is a use case. I just don't see it. You need to walk me through it. Let me give you an example:

"As a _____, I want to _____, so that I can _____."

This is a format I like to use when defining a feature or requirement. For example:

"As a service dog trainer, I want to publish a list of serial numbers representing dogs that have been trained by my company, so that when someone later looks up the serial number they can verify the dog has in fact been trained by my company."

Another alternative method:

Given: ___
When: ___
Then: ___

Which might look lile:

Given: A valid serial number
When: Someone does a look-up on that serial number
Then: I return details that about that dog

With these kinds of descriptions, we can articulate a problem to solve. You can imagine a blockchain solution for this dog-trainer scenario that might benefit from a custom_json + IPFS solution. It might do a look-up on the serial number stored in the blockchain and find an IPFS volume with certification information and photos.

So my question is, would your tools be able to solve this problem? Do you think you can come up with more of these scenarios to help people wrap their heads around concrete problem/solutions your tools can provide?

0
0
0.000
avatar
(Edited)

Ah thank you for these questions! I've been in my own little world as far as my side-chains go for quite some time so I haven't been able to articulate the need for several of these pieces. IPFS is a p2p file system that stores it's contents by the hash of its contents and not the name of the file. Why this is necessary(and has very little to do with the VR explorer) is thus: For collaboration to happen each party needs to agree on what the other parties know and intend on doing. For instance ACTs are non-transferable therefore if funds were sent to the multi-sig account it's possible several of the people running similar software would try to create these accounts and the cooperative nature would be lost. So what is stored in IPFS is a list of information such as who is selling ACTs and for what price. Who is in the queue to create accounts. What the price for accounts and delegation for 30 days is. What the ref block and expiration time for multisig operations are. etc. This information determines the state that needs to be agreed upon. Using IPFS a matching hash not only is proof that you agree upon a state, its also the address of the state so anybody can join the network and start participating in it with out having to replay from genesis. The state stored in IPFS is the consequence solely of information that exists in the streamable blocks. Other information like how many ACTs or SP an account has comes from the Steem API, what time it is is generated locally... these are polled from participants and also published with the custom jsons to make it in to the state file. After about 24 hours the information that was stored in IPFS gets garbage collected and the cooperative doesn't need to worry about older information(which can be found simply by replaying from genesis).

This is how the group shares and verifies information... including who is responsible for broadcasting operations like delegation/undelegtion/account creation. This paradigm will work to alleviate the need for any thirdparty trust in situations such as insurance, banking, brokers and betting.

0
0
0.000
avatar

Yep. We went right back into the weeds. Believe me, I understand this tendency. But it is unhelpful in convincing the average person that you have a viable solution to their problem.

I don't know what to tell you. Everything you've said seems legit, but simultaneously unhelpful.

A technical person unfamiliar with your prior work could claim you were just spewing buzzwords. I know better, but that doesn't mean anything either.

0
0
0.000
avatar

This post has been included in the latest edition of The Steem News - a compilation of the key news stories on the Steem blockchain.

0
0
0.000
avatar

the more initiatives the better, until this place is like a windows store or something but in essene it costs 6 steem to create one atm ... i personally simply havent found anyone interested enough after i explain they cant do anything with it unless they pay for it lol ... "the masses" so to speak (but maybe i just know the wrong people" ...

0
0
0.000