Ethereum & BitShares Partnership?

[fuzzy]

So as an update on possible collaboration, I think we agreed that keeping things informal is the best way forward at this point. No official partnerships or mergers of any companies or any coins/projects, and it doesn't really make sense to copy-paste codebases in either direction either. But we are happy to participate in standardization efforts and collaborative discussions on technical issues as long as it's an open tent where any crypto-2.0 project can participate. I think there definitely are a few areas (eg. proof of stake algos, client standardization) where that would be quite beneficial.

I could not agree more.

And I am sure that most of the Nxt Community also agrees that standardization efforts might help the crypto ecosystem in general. So, if you feel Nxt should participate in such discussion, feel free to invite us. There will be many people willing to devote their time on this.

I personally feel that this is a very important issue which needs to be considered and addressed by a broader audience.

This is a perfect place to let everyone know it is completely free to log into the Mumble Server and chat during the hangouts...or even set up your own hangouts/events.  Regardless where they are held, however, discussions need to be held and a focus needs to be found as to how to best move forward. 

One thing for consideration: Anyone who is interested should be able to attend any of these discussions on standardization.  They should also be able to easily record and report on them as they are happening, from a transparent and open forum.  This isn't simply a matter of a few dev teams working together...this is a matter that requires the input of everyone who is able to provide it over the cross-section of any interested communities (not just NXT, BitShares & Ethereum).

The pictures of golfing and everything are nice, but all I care about is that people are aware what is going on and that it is not kept to secret  meetings where only "insiders" can participate.  This is my #1 concern...and I will bark about it nonstop...because this is about more than just a few devs getting together to "help the standardize the crypto industry".  But what if that help ends up producing a product completely different from that which was originally promised? Everyone needs to have a say, and the community of investors in these projects needs to be able to form consensus on how to move forward in the case that they feel this work toward standardization moves them too far away from the philosophy behind why they originally invested.  Lots of stuff to consider...I just hope we all consider the bigger picture and realize a couple of technological geniuses making decisions for everyone is no way to move forward.  If this is what happens, I will be wholly against it.

[liondani]

Welcome Vitalik 
It's a honor to have you here.

[Riverhead]

So as an update on possible collaboration, I think we agreed that keeping things informal is the best way forward at this point. No official partnerships or mergers of any companies or any coins/projects, and it doesn't really make sense to copy-paste codebases in either direction either. But we are happy to participate in standardization efforts and collaborative discussions on technical issues as long as it's an open tent where any crypto-2.0 project can participate. I think there definitely are a few areas (eg. proof of stake algos, client standardization) where that would be quite beneficial.

I could not agree more.

And I am sure that most of the Nxt Community also agrees that standardization efforts might help the crypto ecosystem in general. So, if you feel Nxt should participate in such discussion, feel free to invite us. There will be many people willing to devote their time on this.

I personally feel that this is a very important issue which needs to be considered and addressed by a broader audience.

Awesome. It is so fantastic to see you guys being open to meetings of the minds. I'm very excited that NXT is open to these discussions and that there is a lot of common ground. We all gain from this.


Welcome to the forum!

[ChuckOneX]

So as an update on possible collaboration, I think we agreed that keeping things informal is the best way forward at this point. No official partnerships or mergers of any companies or any coins/projects, and it doesn't really make sense to copy-paste codebases in either direction either. But we are happy to participate in standardization efforts and collaborative discussions on technical issues as long as it's an open tent where any crypto-2.0 project can participate. I think there definitely are a few areas (eg. proof of stake algos, client standardization) where that would be quite beneficial.

I could not agree more.

And I am sure that most of the Nxt Community also agrees that standardization efforts might help the crypto ecosystem in general. So, if you feel Nxt should participate in such discussion, feel free to invite us. There will be many people willing to devote their time on this.

I personally feel that this is a very important issue which needs to be considered and addressed by a broader audience.

[ChuckOneX]

One of the things we have discussed is lessons learned from Ethereum and BTSX and ways to generalize things better:

1) We agree that smart contracts are useful
2) We agree that smart contracts + BitUSD are very powerful
3) I would like to see a full up relational DB with SQL support as the basic abstraction for the block chain.
    a)  This would allow constraints to be placed on the tables / rows
    c)  This would make indexes easy to maintain
4) I would want to use a lua scripting engine to validate transactions relative to the SQL database
    a) Ethereum currently runs at 1.3 Mhz with their C++ interpreter, storage access via level db is the most expensive operation right now.
    b) I think the data set should be kept in RAM validated by delegates.   Delegates may need $15K servers at scale, but that should be reasonable.
5) One of the major slowdowns for Eth. is the use of merkel trees to support light-weight proofs.  I would do away with this feature.
    a) On a proof of stake chain you cannot validate block headers independent of block contents because you can not use POW as a proxy for trust.
    b) With DPOS + Bonded validation agents you can get cryptographic proofs good enough for light weight clients.  Delegates can lose their job for lying.
    c) Merk. trees help serve as a "double check" on the "deterministic application of transactions", but otherwise are unnecessary.  The check can be performed independent of the consensus algorithm.

As you can see the idea that Eth. represents can benefit significantly by working with our team and we benefit from their challenges as well.   Whether or not Eth. implements DPOS you can bet that V. and I will probably keep pushing the technology forward for future chains.

Interesting that you brought that up. I am not sure much you dug into related work but in Nxt we are actually trying to achieve 3) and 1) with release 1.3 and 1.4. I redirected your thoughts to our developers. Feel free to discuss our implementation at https://nxtforum.org/smart-contracts/

It is also interesting to see how different people get to the same solution to common problems.

[ChuckOneX]

The main objection and concern I have for Proof-Of-Stake, is that it disallows mining.
It is impossible to mine NXT coin, for example,  if you don't own any.
This blocks the community from growth.

That is not true. You can mine NXTs. Have a look at https://nxtforum.org/nxt-indirect-mining/

[werneo]

So what I can say is that a future BitShares chain will be fully Turing Complete with the ability to run arbitrary code. 

damn straight

the best way to align our communities is to have a mutual financial interest and for that reason I could see a joint venture with allocation from both sides for the development of BitShares Turing.

another brilliant solution

Mark this date. History just changed.  Again.

[fuzzy]

I've complained many times about provocative thread titles that mislead people, specifically coming from Bytemaster, since forever. 

I agree with Adam here... Dan should know better.

For somebody that posts 75-100 post a day, I refused to post in this thread up to now.  Above is more or less the reason I did so.

http://www.reddit.com/r/ethereum/comments/2e0q0a/bitshares_guy_here_sorry_we_caused_such_a_stir_we/

Good mea culpa, although it seems Vitalik didn't agree quite as much as you thought, more that he was just very open (probably because they are actively seeking solutions and not tied into anything yet)

I actually agree on this.

As far as posting things that are misleading...

If we are going to ding people for being misleading, we should first start by calling out all altcoins that are made only for pump and dump schemes, then to projects.  I sincerely doubt, though, that Bytemaster and Stan's occasional overglorified posts are intentionally so...sometimes excitement makes people speak too soon, or do release projects too soon...etc.   We are all guilty of such things :/

[lucky331]

cool!  can't wait what's next for crypto 2.0.  you made this a very exciting time for the people who follow and appreciate the tech. 

thanks guys.  wishing you all the luck and success. 

[bytemaster]

vbuterin is man after my own heart when it comes to problem solving and attempts to be objective.   

Thanks for posting here V. 

[vbuterin]

I've complained many times about provocative thread titles that mislead people, specifically coming from Bytemaster, since forever. 

I agree with Adam here... Dan should know better.

For somebody that posts 75-100 post a day, I refused to post in this thread up to now.  Above is more or less the reason I did so.

http://www.reddit.com/r/ethereum/comments/2e0q0a/bitshares_guy_here_sorry_we_caused_such_a_stir_we/

Good mea culpa, although it seems Vitalik didn't agree quite as much as you thought, more that he was just very open (probably because they are actively seeking solutions and not tied into anything yet)

Or perhaps I just find it more productive to talk about differences, since there's no benefit in preaching to each other's choirs about what we already agree on When I say "my main concerns are", I mean "I'm 75% onboard, we already know about the 75% so here's the remaining 25%". We express our viewpoints, look for differences, expand on those differences, and see how our different approaches can benefit each other; it's a genetic algorithm approach to optimization.

We're both considerably more pro-PoS than the vast majority of the bitcoin community and I do think DPOS is one of the better approaches and does not have glaring incentive incompatibility holes like many of the other algos that are currently in use.

[luckybit]

I haven't posted it yet, but pretty sure we have the Truthcoin Devs wanting to show up for a Saturday Meetup.  I'd really like to get Devs from all different crypto-ecosystems to chat with the community so if anyone knows some, let me know!

Also, BM. Is Friday a go or a no go at the moment?

Truthcoin is a community we really need to collaborate with. They are smart, highly motivated, and working on the same problems.

[luckybit]

V and I had a great time and I appreciate him making the trip to Virginia.   

One thing that has come out of the process is that I am a firm believer in the need for a "Turing Complete" environment on a DAC.   The other thing that came out of the meeting is that the existing Eth. design has woefully inefficient abstraction for the types of data structures that DAC developers really need.  Technically it is turing complete and it is possible to do everything on their existing design.  I was throughly impressed with V's ability to solve problems on the fly and believe that Eth will be a very interesting platform and will find many solutions.   

So what I can say is that a future BitShares chain will be fully Turing Complete with the ability to run arbitrary code.   I think that we will probably have a friendly competition moving forward as we steal good ideas from each other. 

One thing I can say is that nothing replaces real-world experience writing DACs from scratch to learn what the proper abstraction layer is.  V gained some insight from our experience writing real DACs while we gained some of his experience with doing things more generally.

We also recognized that the biggest need we have is for our communities to work together rather than against one another.  It is kind of like different tribes.  It seems that the best way to align our communities is to have a mutual financial interest and for that reason I could see a joint venture with allocation from both sides for the development of BitShares Turing.

All of these things are probably a year or more away as we both have to focus on current systems.

For less experienced developers can you define what an abstraction layer is? Do you mean something like the standard library of C++? Do you mean something similar to classes or functions which help make writing contracts easier?

One thing that has come out of the process is that I am a firm believer in the need for a "Turing Complete" environment on a DAC. 

Could you please expand more on this? In particular, what would you say is the value of adding user-generated Turing complete scripts on an existing DAC over developer-generated Turing complete code implementing new features on a new DAC (or a fork of the old DAC)? I sort of think of it like the difference between compiling then running code written in a statically-typed language vs using an eval expression to interpret code written in a dynamically-typed language. If the basic framework is going to be used again and again, it would make sense to me to just implement those features in the codebase, fork, and now everyone can enjoy it. On the other hand, if these features are unique to each particular user's situation, I suppose being able to (less efficiently?) implement the custom script on an existing DAC could be useful. But I am wondering what those use cases actually are.

So what I can say is that a future BitShares chain will be fully Turing Complete with the ability to run arbitrary code.

I do think it would be pretty fun to try out a BitShares-branded DPOS DAC that has Turing complete scripts. But I want to make sure that I understand correctly; you are not advocating that core BitShares DACs like BitShares X and BitShares DNS become "Turing complete" correct?

From a developer perspective it's definitely better to have a scripting layer. That is something Ethereum really got right before everyone else. It has to be Turing complete but there is also great difficulty is doing that in a secure manner. I can only speak for myself but I'm looking forward to Ethereum because if it's flexibility and openness which could result from it's Turing complete scripting so I hope Bytemaster builds that into Bitshares toolkit at least.

But I recognize it's actually very very hard to do in a secure manner so the challenge will be to see how Ethereum manages to do it and improve on it. In order for DACs to survive they will have to be in a continuously evolving state of growth by innovation.

Having the ability to use scripting languages to modify the behavior of the DACs through Bitshares toolkit for example would allow for rapid DAC development. That would be very good for the industry because honestly few people know C++ well compared to all the scripting languages.

When you want maximum innovation then in my opinion one of the best things to do would be to invite as many developers from as many different backgrounds as possible into the ecosystem. C++ reigns supreme for Bitcoin/Bitshares but what we need is a toolkit which can accept any language or at least all the major languages.

That way people can extend the capabilities of the toolkit over time. Ethereum seems to be in a position to take over the world once they come up with a sort of development kit. So maybe that is what Bytemaster meant by abstraction? Currently the contracts are scripts, and I can read them, but where are the libraries, classes, and what not? If it's deemed too complicated looking or if there isn't a standard library then development time takes longer.

The good news is Ethereum now has the money to make a state of the art world class development kit or standard library. In addition to that there will have to be some professional documentation as well.

[Stan]

I've complained many times about provocative thread titles that mislead people, specifically coming from Bytemaster, since forever. 

I agree with Adam here... Dan should know better.

For somebody that posts 75-100 post a day, I refused to post in this thread up to now.  Above is more or less the reason I did so.

http://www.reddit.com/r/ethereum/comments/2e0q0a/bitshares_guy_here_sorry_we_caused_such_a_stir_we/

Good mea culpa, although it seems Vitalik didn't agree quite as much as you thought, more that he was just very open (probably because they are actively seeking solutions and not tied into anything yet)

Do any of you old-timers remember the antique acoustic-coupler modems and fax machines where you could hear ack/nack tones increasing in frequency until they had negotiated the highest baud rate they both could handle eventually reaching some inaudiable frequency where the two machines started flinging data at each other too fast for mere humans to follow?

http://www.youtube.com/watch?v=gsNaR6FRuO0

Yeah, it was like that.

[Stan]

I just noticed super3, was Storj also represented at this gathering?

It was a social gathering of people who only talk shop - so naturally we talked about Storj technology and its vision too.