Author Topic: [Proposal] Bounty for Easy to launch DAC code  (Read 5210 times)

0 Members and 1 Guest are viewing this topic.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Dan and I are working on something like this this week, check out the WIP:

https://github.com/BitShares/bitshares_toolkit
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 barwizi

  • Hero Member
  • *****
  • Posts: 764
  • Noirbits, NoirShares, NoirEx.....lol, noir anyone?
    • View Profile
    • Noirbitstalk.org
People don't seem interested. I'll leave this for now until i see interest.   ???
--Bar--  PiNEJGUv4AZVZkLuF6hV4xwbYTRp5etWWJ

The magical land of crypto, no freebies people.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
And include a Readme.txt with this https://bitsharestalk.org/index.php?topic=3482.0 content and which makes developers aware that their DAC might be forked by invictus or a community member if the social consensus is not honored. Invictus then would have the marketing power and developing expertise to outcompete their version or at least take away a market share that is bigger than the 20% they are giving away. Even without that 'competition by I3' disadvantage the adavantages named in the link above might compensate for the 20% even though not all DACs that honor AGS/PTS will get the whole list of adantages listed in the link above, which (off topic) leads me to the suggestion to make graded honoring requirements: 20% for all invictus dacs and all 3rd party dacs having the full i3 support and 10% for all 3rd party dacs using templates but having no (major) i3 support and 10% that are receiving I3 consulting and marketing support but dont use templates/tools. Just thinking out loud.
Of course in a very nice way explaining the effort I3 and the community has put to the table to enable the basis they are going to code on.

Offline barwizi

  • Hero Member
  • *****
  • Posts: 764
  • Noirbits, NoirShares, NoirEx.....lol, noir anyone?
    • View Profile
    • Noirbitstalk.org
I do wish to take on the project of creating .net wrapper classes if there's a need for a base DAC. I'm not very fluent with c++ but I have done a lot of these type of projects and there will be a huge opportunity for people with many different programming language skills.

All code that can be used for DACs is welcome in the repo, i am doing the rather straight forward stuff first then with help from other we can expand. I am hoping people decide to participate in this exercise.
--Bar--  PiNEJGUv4AZVZkLuF6hV4xwbYTRp5etWWJ

The magical land of crypto, no freebies people.

Offline rysgc

  • Sr. Member
  • ****
  • Posts: 289
    • View Profile
    • DACZine.com
I do wish to take on the project of creating .net wrapper classes if there's a need for a base DAC. I'm not very fluent with c++ but I have done a lot of these type of projects and there will be a huge opportunity for people with many different programming language skills.
DACZine.com - Receive all the latest DAC and BitShares community news straight to your inbox. Signup here or Submit news

Offline fuzzy

WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline barwizi

  • Hero Member
  • *****
  • Posts: 764
  • Noirbits, NoirShares, NoirEx.....lol, noir anyone?
    • View Profile
    • Noirbitstalk.org
Well, NRS is done. I will do PTS when i get time hopefully later today. https://github.com/DACBootcamp
--Bar--  PiNEJGUv4AZVZkLuF6hV4xwbYTRp5etWWJ

The magical land of crypto, no freebies people.

Offline barwizi

  • Hero Member
  • *****
  • Posts: 764
  • Noirbits, NoirShares, NoirEx.....lol, noir anyone?
    • View Profile
    • Noirbitstalk.org
another interesting prospect of standardizing the code is a funded drive toward merge mining. I say this because the fall in hash behind PTS saw a rise in NRS, hat is not the most desirable situation as i prefer both chains to bw working, not one at the expense of the other.

If it is a possibility, it would solve the problem of hash power being divided between chains. This also puts the possibility of modular codebase in reach.

No need for merged mining with TAPOS.

I think any "serious" DACs in the near-term future will use BTS X codebase because it has the potential to be Fast and Good.

DACs will never be as easy as launching a MSC asset because the very fact that they are intended to be highly specialized for their particular domain and so there is not much benefit in the near future to porting core BTS utilities yet.

Go has awesome interop with C++ so maybe one day dastool can merge with someone's core blockchain code and make easy-to-launch DACs.

Quote
No need for merged mining with TAPOS.

There you are incorrect, already it is evident if you look at the PTS dilemma.
...
TaPoS is a great idea, but still requires hash power behind it.

Wait what? PTS doesn't use TAPOS, and the problem that PTS is experience would not be relevant for BTS derivatives. Am I missing something? How on earth could TAPOS chains do merged mining?

I did not say it does. I am focused on the vehicles of distribution at the moment. BTS derivatives are something i think we can talk about when there actually is a working functional BTS bc with a GUI too. BTS bc isn't even running yet so creating a template of it is out of reach for the moment. Technical papers can be done now, however most initiatives will for the time being want a vehicle similar to PTS for allocation and distribution of value supply.

TaPoS by the way is unproven, perhaps we can start giving it full consideration when the system has been proven? For now i am creating templates of useable code whose functions are known to me and can be implemented at a moments notice.
--Bar--  PiNEJGUv4AZVZkLuF6hV4xwbYTRp5etWWJ

The magical land of crypto, no freebies people.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
another interesting prospect of standardizing the code is a funded drive toward merge mining. I say this because the fall in hash behind PTS saw a rise in NRS, hat is not the most desirable situation as i prefer both chains to bw working, not one at the expense of the other.

If it is a possibility, it would solve the problem of hash power being divided between chains. This also puts the possibility of modular codebase in reach.

No need for merged mining with TAPOS.

I think any "serious" DACs in the near-term future will use BTS X codebase because it has the potential to be Fast and Good.

DACs will never be as easy as launching a MSC asset because the very fact that they are intended to be highly specialized for their particular domain and so there is not much benefit in the near future to porting core BTS utilities yet.

Go has awesome interop with C++ so maybe one day dastool can merge with someone's core blockchain code and make easy-to-launch DACs.

Quote
No need for merged mining with TAPOS.

There you are incorrect, already it is evident if you look at the PTS dilemma.
...
TaPoS is a great idea, but still requires hash power behind it.

Wait what? PTS doesn't use TAPOS, and the problem that PTS is experience would not be relevant for BTS derivatives. Am I missing something? How on earth could TAPOS chains do merged mining?
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 barwizi

  • Hero Member
  • *****
  • Posts: 764
  • Noirbits, NoirShares, NoirEx.....lol, noir anyone?
    • View Profile
    • Noirbitstalk.org
--Bar--  PiNEJGUv4AZVZkLuF6hV4xwbYTRp5etWWJ

The magical land of crypto, no freebies people.

Offline unimercio

  • Sr. Member
  • ****
  • Posts: 245
  • The opportunity of a lifetime comes by every 7 day
    • View Profile
    • Conscious Entrepreneurship Foundation (CEF)
  • BitShares: unimercio
another interesting prospect of standardizing the code is a funded drive toward merge mining. I say this because the fall in hash behind PTS saw a rise in NRS, hat is not the most desirable situation as i prefer both chains to bw working, not one at the expense of the other.

If it is a possibility, it would solve the problem of hash power being divided between chains. This also puts the possibility of modular codebase in reach.

No need for merged mining with TAPOS.

I think any "serious" DACs in the near-term future will use BTS X codebase because it has the potential to be Fast and Good.

DACs will never be as easy as launching a MSC asset because the very fact that they are intended to be highly specialized for their particular domain and so there is not much benefit in the near future to porting core BTS utilities yet.

Go has awesome interop with C++ so maybe one day dastool can merge with someone's core blockchain code and make easy-to-launch DACs.

Quote
No need for merged mining with TAPOS.

There you are incorrect, already it is evident if you look at the PTS dilemma. Due to returns on mining dropping so suddenly, a lot of the hash power has moved away resulting in slower blocks. This in turn affect transactions as they are processed on a per block basis. transactions are now excruciatingly slow  and the mempool shows a huge back log, meaning that unless you pay for priority, your tx will be very late.

TaPoS is a great idea, but still requires hash power behind it. The closer you look at it, TaPoS would not have much off an effect on the primary functions, in fact it is a tertiary function that does not affect any of the areas associated with merged mining.

anyway, we can do philosophy later, this thread is about providing people with useable templates for DAC deloyment.

Quote
DACs will never be as easy as launching a MSC asset because the very fact that they are intended to be highly specialized for their particular domain and so there is not much benefit in the near future to porting core BTS

One of the most desired things by people who have tinkered with the basic codebase derived from bitcoin is a modular approach, basically pre-written files that can be swapped out to effect changes from the most basic mods to making drastic changes in chain structure and operations.

We at the Noir Investment Group are already discussing using the blockchain tech to deploy services rather than tokens, one of the mandates is to keep it modular meaning that  a seperate entity could follow our lead and create another different "plugin" that will change the function to suit their needs. Such a system will encourage other players to simply modify or create new plugins, the resulting plethora of options could very possibly be the corner stone of DACs.

 +5% anytime you can abstract complex code layers, thousands of application developer are born. 8)
Conscious Entrepreneurship Foundation (CEF)

Offline barwizi

  • Hero Member
  • *****
  • Posts: 764
  • Noirbits, NoirShares, NoirEx.....lol, noir anyone?
    • View Profile
    • Noirbitstalk.org
another interesting prospect of standardizing the code is a funded drive toward merge mining. I say this because the fall in hash behind PTS saw a rise in NRS, hat is not the most desirable situation as i prefer both chains to bw working, not one at the expense of the other.

If it is a possibility, it would solve the problem of hash power being divided between chains. This also puts the possibility of modular codebase in reach.

No need for merged mining with TAPOS.

I think any "serious" DACs in the near-term future will use BTS X codebase because it has the potential to be Fast and Good.

DACs will never be as easy as launching a MSC asset because the very fact that they are intended to be highly specialized for their particular domain and so there is not much benefit in the near future to porting core BTS utilities yet.

Go has awesome interop with C++ so maybe one day dastool can merge with someone's core blockchain code and make easy-to-launch DACs.

Quote
No need for merged mining with TAPOS.

There you are incorrect, already it is evident if you look at the PTS dilemma. Due to returns on mining dropping so suddenly, a lot of the hash power has moved away resulting in slower blocks. This in turn affect transactions as they are processed on a per block basis. transactions are now excruciatingly slow  and the mempool shows a huge back log, meaning that unless you pay for priority, your tx will be very late.

TaPoS is a great idea, but still requires hash power behind it. The closer you look at it, TaPoS would not have much off an effect on the primary functions, in fact it is a tertiary function that does not affect any of the areas associated with merged mining.

anyway, we can do philosophy later, this thread is about providing people with useable templates for DAC deloyment.

Quote
DACs will never be as easy as launching a MSC asset because the very fact that they are intended to be highly specialized for their particular domain and so there is not much benefit in the near future to porting core BTS

One of the most desired things by people who have tinkered with the basic codebase derived from bitcoin is a modular approach, basically pre-written files that can be swapped out to effect changes from the most basic mods to making drastic changes in chain structure and operations.

We at the Noir Investment Group are already discussing using the blockchain tech to deploy services rather than tokens, one of the mandates is to keep it modular meaning that  a seperate entity could follow our lead and create another different "plugin" that will change the function to suit their needs. Such a system will encourage other players to simply modify or create new plugins, the resulting plethora of options could very possibly be the corner stone of DACs.
--Bar--  PiNEJGUv4AZVZkLuF6hV4xwbYTRp5etWWJ

The magical land of crypto, no freebies people.

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
Many people have ideas but no idea how to code. I propose a bounty be posted for clean templates of the existing code bases in the community for easy use, along with detailed guides on what can be modified in graduating order from a total noob to semi-competent developers. Thus far NRS,MMC,PTS are great but anyone who wishes to use them will suffer to get things started.

Additional Bounties could be set up for introducing new useable code bases for different applications.

This will help kick start DAC deployment outside of the usual developer circles.

This is exactly what we need. We need templates so that the development process can be decentralized and we can avoid the centralization of knowledge problem that Bitcoin development has.

I have several good to great ideas for DACs. The main problem is there is no template for how to make a DAC. I don't blame Invictus for this because making a DAC is not easy.

But the sooner we have templates to make it easier the sooner we can really push the limits.

What I want to see is a code base which allows for Proof of Stake with voting, to have data storage in the blockchain, to have some sort of M of N transaction capability so that a group of people can hold angelfunds and then vote on whether or not it gets spent by signing off on it or not. Maybe the top 20 shareholders all get a vote via M of N and if 60% are in favor then it's given the green light. Maybe some other advanced scripting should be put into it too specifically to create a sort of decentralized corporation which can allow shareholders to collectively make decisions by PoS voting.

As far as the development kit and code, just make sure that it's high level enough that anyone can deal with it. C++ is not the language which anyone can deal with even if I can deal with it. It should be high level enough that any web app developer can make use of it, so Ruby, Python, C#, Javascript or even HTML. These DACs (or at least the autonomous bounty distribution DAC I'm thinking of) is something which would work well if it could be designed as a web application which people can install on their phones, in their browsers, or download as a binary.

So go with cross platform capability if possible. We need that more than anything else and we need high level, with modularity and security.
Great, i haven't looked into the BTS code properly yet. However if they take to this idea, maybe they should break it up into individual components. eg A set of BTSX bounties and a set of non BTSX bounties. One could be setting up a new github account with clean template of PTS, with a wiki that describes the process of forking and creating an alternate. This will tie in with the genesis initalization guide i wrote. Fot BTS maybe it could be a repository in the same account doing the same, even keyhotee will have a clean template. Compilation of these clean templates, the tools required and guides would be a huge step for the ecosystem. NRS code as well can be added.

Then as we progress, anyone has access and can request pulls that improve the code as a template. So much possibilities.
I've looked at some of the BTS code. It's very clear whats going on, well organized, commented. I think Bytemaster specifically wrote it in a way so that other developers can easily read and understand whats going on so +5% there.

But it's still in C++ and C++ is intimidating for most developers. Remember this is cryptography, it's not the same as writing a word processor. For that reason I think we need to interface the low level code with high level languages like Python. Fellow traveler did this to a certain extent with Open Transactions. We need something like BTSMadeEasy.

https://bitcointalk.org/index.php?topic=144879.0
https://github.com/FellowTraveler/Open-Transactions-old/blob/master/src/otapi/OTMadeEasy.cpp

another interesting prospect of standardizing the code is a funded drive toward merge mining. I say this because the fall in hash behind PTS saw a rise in NRS, hat is not the most desirable situation as i prefer both chains to bw working, not one at the expense of the other.

If it is a possibility, it would solve the problem of hash power being divided between chains. This also puts the possibility of modular codebase in reach.

Merge mining might not be such a good idea. I'm not against mining but PTS is probably mined by Botnets. We need new algorithms which cannot be so easily gamed if we are going to use mining at all.

PTS mining is probably centralized now. You cannot mine it on your CPU anymore and for that reason merge mining isn't as attractive as coming up with a better algorithm. Mining as it currently works ultimately only leads to centralized cartels similar to how we have with oil and diamonds.

« Last Edit: March 04, 2014, 05:55:20 am by luckybit »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline unimercio

  • Sr. Member
  • ****
  • Posts: 245
  • The opportunity of a lifetime comes by every 7 day
    • View Profile
    • Conscious Entrepreneurship Foundation (CEF)
  • BitShares: unimercio
In the ideal world we could leverage an existing RAD tool, working at the design level would insulate application developers from advanced lower level properties and code.
This would lend many benefits:

shorter time to market
more reliable code
simpler to troubleshoot
easier to deploy updates
greater adoption with fewer barriers to entry
lower cost to market
increased profits for DAC stakeholders
additional revenue streams for tool vendors
code once deploy many potential with cross platform tools
Conscious Entrepreneurship Foundation (CEF)

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
another interesting prospect of standardizing the code is a funded drive toward merge mining. I say this because the fall in hash behind PTS saw a rise in NRS, hat is not the most desirable situation as i prefer both chains to bw working, not one at the expense of the other.

If it is a possibility, it would solve the problem of hash power being divided between chains. This also puts the possibility of modular codebase in reach.

No need for merged mining with TAPOS.

I think any "serious" DACs in the near-term future will use BTS X codebase because it has the potential to be Fast and Good.

DACs will never be as easy as launching a MSC asset because the very fact that they are intended to be highly specialized for their particular domain and so there is not much benefit in the near future to porting core BTS utilities yet.

Go has awesome interop with C++ so maybe one day dastool can merge with someone's core blockchain code and make easy-to-launch DACs.
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.