BitShares X Status Update

[Amazon]

Is dan still working on BitsharesX? His last commit was almost 2 weeks ago...

There is a new sticky post to track the development status:
https://bitsharestalk.org/index.php?topic=3812.0

[bytemaster]

Prep for conference plus travel plus website has taken a lot of my time.   I was coding on the train.  Also a lot of time was spent designing dpos.


Sent from my iPhone using Tapatalk

[CrazyCriple]

Is dan still working on BitsharesX? His last commit was almost 2 weeks ago...

[cass]

So now that NYC is over, when BTSX will be make liquid?

As soon as possible. 

We are taking the long train home tonight.

Get home safely

[Stan]

So now that NYC is over, when BTSX will be make liquid?

As soon as possible. 

We are taking the long train home tonight.

[BldSwtTrs]

So now that NYC is over, when BTSX will be make liquid?

[JoeyD]

Piggy-backing is not the only way for 3rd parties to interface with the protocol though, while at the same time not communicating or cooperating with "core-devs". Similar problems could arise if those 3rd parties build on the use of bitsharesX, not that unfathomable should it become popular enough.

Demanding that everyone who wants to write software to work with the bitsharesX-protocol to be open-source as well, might not be possible. However I don't think that it would hurt to mention that that does not exclude them from the open-source process or at least warn people of the potential hazards that custom closed source solutions might have, like for example mtGox.

It might be perfectly obvious for everyone here that open-source is the only secure and transparent way to go and that nobody here would even consider using blackbox closed-source software for anything valuable. That however does not change the fact that the majority of desktop/tablet/phone-users still have no idea what open-source even means or why it's important and that includes a significant amount of software-developers.

[bytemaster]

BitShares has no room for 3rd parties to piggy back on our chain because we don't use scripts that can contain arbitrary data.  You would have to embed the data in the addresses in the blockchain.   We also charge transaction fees on a per-byte basis so this would become very expensive to require at least 256 bytes of data for 20 bytes of payload, especially when there is a minimum output amount.

[JoeyD]

The critical difference is that XCP depends on the bitcoin blockchain and cannot "ignore" an update. Each DAC developer should of course be careful to make sure they don't pull in breaking changes...

Still should any of the bitshare-projects achieve even partly the current popularity of bitcoin, then similar problems might occur when updating the software and 3-rd party software that's running on top gets broken.
Might be a ways off in the future, but the more free-market voting, concensus style of working might come as a shock to people new to the Bazaar way of doing things.

[toast]

but bitshares doesn't use the bitcoin blockchain.

Don't know if you were commenting on my post, but for the moment I assume you did.
The argument arose, because people were trying to build stuff on top of bitcoin, but did not actually inform or involve the bitcoin-devs in their projects, neither did they propose solutions or improvements via BIPs. Something similar could happen to bitshares as well, where people just build on to of bitshares in isolation and suddenly throw a fit when a bugfix seems to have fixed an exploit they were relying on for their project.

Spinning this as bitcoin-devs being "against" them is a little far fetched in my opinion, but that does not mean that the same false arguments could not be directed at bitshares-devs for similarly strange reasons (because of unfamiliarity with the open-source way of doing things).

The critical difference is that XCP depends on the bitcoin blockchain and cannot "ignore" an update. Each DAC developer should of course be careful to make sure they don't pull in breaking changes...

[etherbroker]

Don't know if you were commenting on my post, but for the moment I assume you did.
The argument arose, because people were trying to build stuff on top of bitcoin, but did not actually inform or involve the bitcoin-devs in their projects, neither did they propose solutions or improvements via BIPs. Something similar could happen to bitshares as well, where people just build on to of bitshares in isolation and suddenly throw a fit when a bugfix seems to have fixed an exploit they were relying on for their project.

Ah, thanks for the clarification.

[JoeyD]

but bitshares doesn't use the bitcoin blockchain.

Don't know if you were commenting on my post, but for the moment I assume you did.
The argument arose, because people were trying to build stuff on top of bitcoin, but did not actually inform or involve the bitcoin-devs in their projects, neither did they propose solutions or improvements via BIPs. Something similar could happen to bitshares as well, where people just build on to of bitshares in isolation and suddenly throw a fit when a bugfix seems to have fixed an exploit they were relying on for their project.

Spinning this as bitcoin-devs being "against" them is a little far fetched in my opinion, but that does not mean that the same false arguments could not be directed at bitshares-devs for similarly strange reasons (because of unfamiliarity with the open-source way of doing things).

[etherbroker]

but bitshares doesn't use the bitcoin blockchain.

[JoeyD]

Amen. I was thinking the same thing when I read that.

Can I get a link?

This is the link

http://www.coindesk.com/developers-battle-bitcoin-block-chain/

I think that article was only written as an opportunity to bash Bitcoin and plug Ethereum.  I don't see how it would make sense otherwise to even mention a completely irrelevant "solution", particularly if the quoted persons say the same thing. (Their Disqus-moderator also didn't take to kindly to me pointing that out, which makes me doubt their objectiveness even more.)

I've read parts of the discussion on the forums and it seems the issue is one that could affect everyone in this space. They did not communicate or involve the developers of bitcoin in their plans and then act a bit like spoiled divas. I think this might be because of a cultural problem of being unfamiliar with how open-source projects and development works.

Open-source might be open and free, but that doesn't mean you don't have to make your own sandwich. Counterparty (don't know if mastercoin was the same) are complaining they are not being catered to and project themselves as the end all be all of Bitcoin and all bitcoiners should carry the burden of their plans, no questions asked. As far as I could tell, the bitcoin devs were not unwilling to develop a more elegant solution instead of the current exploit-hack and even proposed a few temporary workarounds until such a solution was found, but judging from the reactions I doubt we'll see a BIP anytime soon from the Counterparty and Mastercoin teams.

In short I think we should be prepared for similar cultural/perspective problems over here as well.

[jwiz168]

Amen. I was thinking the same thing when I read that.

Can I get a link?

This is the link

http://www.coindesk.com/developers-battle-bitcoin-block-chain/