Essentially what Bitshares is doing is selling derivatives of different cryptocurrencies in their attempt to be a decentralized exchange. Would not this ruling legally harm the protocol and those working for it? Please discuss and alleviate my concerns.


http://www.seattletimes.com/business/markets/bitcoin-community-has-its-say-on-us-commodity-ruling/

Why does Bitshares/Graphene not have a gitter? It seems that it would benefit immensely from having a gitter room where people could openly ask technical questions in real time and be responded to with the help of the community rather than communicating via slow updating forum pages.

Here's a page: https://gitter.im/home

I hope you all consider it. I think it would be a great in addition to the mumble server.

With Ethereum about to launch in about two weeks, I think it would be smart of someone to make a UIA that would be a pegged derivative to Ether. It's bound to trade in high volumes and would allow us to exhibit the greatness that is Bitshares in being a truly decentralized exchange (and the better one than Ethereum i might add).

Right now I'm thinking of how to solve a problem in a torrenting application. One of the things that I'm having trouble with is creating a multi sig address that, in the case of many parties (say over 10 for good understanding) can dynamically update if it turns out one of the parties is unreliable, drop that signature, and bring in a new signature to sign on in the span of less then a second.

I get the feeling that this may very well be possible with the application of weighted keys. Any of the devs have any thoughts?

My experience when it comes to GUIs is mostly in Angular and basic HTML and CSS (the basics), but I have no experience with React. I figure it can't be all that different. In any case, I had an idea for an animation regarding Witness scheduling and I wanted to take a shot at implementing it. Any help in figuring out where I should be looking would be greatly appreciated.

Am I hallucinating? The config file seems to have changed since I last pulled from the github....

and now I can't seem to connect the witness node. There are a lot of requests being sent out to different IP addresses with the website "pool.ntp.org" being a request I am seeing.

Anybody want to enlighten me? Should I just be patient and wait? I am trying to get my node to start making blocks. Not sure what each of these new commands mean for my attempt to do that.

EDIT: let me try deleting the config file first....I should have tried that first.

EDIT2: Yup, I'm crazy...that worked.

So I was contemplating the mumble session we had earlier today. I had asked a question regarding SPV (simplified payment verification...akin to that of a light wallet in Bitcoin) and if it was at all possible. The answer I got was that in the traditional sense (that being a trustless sense as SPV confirms based on a handful of block headers), no it is not. You will have to read from a central server website, the idea being that replication will ideally create the web of trust we are seeking here. However, there is something to be said for 'trustless' solutions. So a thought occurred to me. The witness nodes when thought of in the abstract as they are seem to form something of a ring...a ring that could be utilized as a distributed hash table methinks. So here's my proposal for a new operation in the blockchain to enable TRUE SPV.

Why not have a DHT integrated into the witness ring so that a light client could merely tap the DHT network and see the last N block headers (where N is also the number of witnesses). This could be supplemented for speed purposes by a full node broadcasting the block (we have to incentivize people to still run full nodes for the sake of security...why not create a role like witness in training or make it a worker section?) If we could find a way to prove that the "witness in training" delivered a packet of blockchain successfully to the light wallet, you may also have another way to generate economic gains to those simply running a full node. Granted that is going to be hard, but it is definitely something to think about (perhaps some form of a ranking system?)

One of the biggest problems with a DHT is the problem of Sybil attacks...something that the blockchain has effectively solved the problem of. One way we defend against sybil attacks is using the exact IDs that we have recorded in the blockchain as certified IDs. You aren't registered to the blockchain, you won't be delivered any data. Another is to find some way of implementing a proof of work, such that if a node reports that you delivered data that was incorrect (we see a node trying to fork the state), then we look for who delivered that data (not sure how exactly we do that outside of a ranking system) and can either a) impose a fee, b) kick them out of the DHT, or both. Kicking them out seems a bit harsh however, as an attacker could try to create false data and say that a full node did it, unjustly penalizing them....perhaps something involving the signing key? Another way is for a delegate/worker to administer a reverse turing test....think something like a CAPTCHA...only useful to the blockchain. Yet another way would be to simply have them pay to use the light wallet service (something like a small micropayment to access the DHT and make GET requests).

To me, this seems like it has even greater applications when we think of resurrecting DNS, content distribution, and reducing blockchain bloat. What do you guys think? Am I crazy or can this thing work?