Asking us to port their library to JS is a major effort that is easily a month of work for someone who understands it all.   Throw in learning and reverse engineering and it could take 3 months to get it right.

I agree that it is a non-trivial effort to port the crypto library to JS, but you absolutely should not have to reverse engineer and reimplement it! Like I said before, just use emscripten to convert Blockstream's code into asm.js. Then you just need to write the Javascript interface/wrapper to use that converted code.

This is hyperbolic.

First, Chrome is closed-sourced so it can in theory be doing all kinds of things even worse than listening in.

Second, Chromium, the open-source browser that Chrome is based on, shows that the binary blob that does this listening in is in its own sandbox with a well-defined interface to the rest of the world. That interface can enable connection to the microphone if the hot word option is enabled in the browser, which is by default disabled. All of those facts can be verified by studying the interface because Chromium is open source.

Now, downloading and running binary blobs as part of an open source program may go against the spirit of open source. But the truth is that all browsers have been doing something close to this for a while now anyway. That Javascript code that the browser downloads and runs in a secure sandbox is in theory open source, but the reality is that it is usually minified and obfuscated (comments removed, variables renamed). How much more useful is that "code" in that form to an auditor / hacker than an assembly dump of the binary executable (and there can be other sophisticated tools to convert it back into C code, granted with nonsense variable names, no comments, and other oddities)?

The reality is that the modern browser is a software platform just like the OS. And I would argue that running any closed-source software on your OS is analogous to running these binary blobs in the browser, except in practice it is even worse because a modern browser has better sandboxing enforced than today's desktop OSes (mobile OSes, like iOS and Android, are much better on this front). So unless you are an open source purist [1] and every single piece of software in the stack running on your system from the user-facing applications to the kernel is open source (and I doubt the firmware to make your hardware devices work is open source), then I find objections to binary blobs running in the browser platform in secure sandboxes with well-defined open-source interfaces to be a bit hypocritical.


Edit: Anyway, apparently they now disabled it for the default build of Chromium (https://code.google.com/p/chromium/issues/detail?id=500922#c31). And I assume this will be the build configuration that will be used for official binaries provided from the repositories of popular Linux distros. Obviously Chrome (which is not open source) will be unaffected by this change.

[1] And before anyone complains, I know the difference between open source and free software. I realize Stallman would be a free software purist. But by definition free (libre) software is a superset of open source software, thus a free software purist would also necessarily be an open source purist.

So long as there are no legal restrictions on further development etc

And the costs are not too high to cripple development speed (due to lack of funds) by the nascent Cryptonomex.

And I thought Cryptonomex is only doing software development and consulting. Why should there be any need for a BitLicense in that case? If Cryptonomex does have greater plans that go beyond pure software development that may require such a license, wouldn't it be better to split that role off into another company to protect the development side of things?

The delegates will have to sell this BitUSD on the market to get BTS and then continue to fund the reserve pool.     This is not an ideal situation because it takes the delegates 2 weeks to take any action.  So I was proposing to automate the process of selling the BitUSD and funding the fee pool.

Automation would be ideal. Couldn't the transaction include operations to do the conversion via the market? For example, a fill-or-kill limit order asking for exactly the amount of BTS needed (in exchange for the BitAsset) to pay the transaction fee, where the proceeds from that immediately go to pay the fee. If the liquidity of the market suddenly becomes really bad since the transaction was created such that the full conversion cannot happen within the price limit, then the transaction becomes invalid. If the nodes reject transactions that would not be able to satisfy the fee with the state of the market at the end of the previous block (despite the risk of false positives), it could reduce the amount of invalid transactions that need to be processed in the inner single-threaded engine at the cost that users might need to be willing to accept a slightly higher limit price to get their transaction processed.

The clients could automatically modify any transactions that deal only with BitAssets to add this fill-or-kill limit order operation to pay the fee and make the process entirely transparent to the user. If the user had plain-text BTS in the account (and the client settings were set to prefer it, which would be the default), the client would prefer using BTS directly since it would make the transaction slightly cheaper. Otherwise, it would all still work without the user having to worry about manually converting the BitAssets to BTS.

Furthermore, this could be used as an alternative to the fee pools of privatized BitAssets and UIAs assuming the BTS/{BitAsset,UIA} market had sufficient liquidity. The client could even automatically calculate whether the fee pool conversion ratio set by the issuers was likely to be cheaper or more expensive compared to fill-or-kill limit order method and choose appropriately.

Quote from: arhag on June 23, 2015, 05:29:14 pm

Quote from: Bitcoinfan on June 23, 2015, 05:02:38 pm

How did bitshares ever let Roger Ver  sweep down and poach this project?

The answer to that is easy: Bitcoin maximalism.

The real question is why aren't we able to convince Augur to use our platform rather than the much slower Ethereum (plus we already have BitUSD working while they are still working on eDollar).

Why would you want Augur on your platform?   What makes you so sure Augur have the right talent when of all the groundwork was from Paul?

I would love it if Paul wanted to build a prediction market system for BitShares. I'm not holding my breath though. He seems to really dislike BitShares and pretty much any other system that could potentially compete with Bitcoin.

The Augur team seems less antagonistic against altcoins considering they're currently building their technology on Ethereum and also they are coin-agnostic as far as which coins their platform will support for betting.

Nevertheless, I predict the BitShares devs will have to end up doing the prediction market work all by themselves.

Quote from: arhag on June 24, 2015, 11:40:50 pm

Quote from: sittingduck on June 24, 2015, 11:10:07 pm

https://github.com/cryptonomex/graphene/issues/83

I'm confused by this. Does this mean that network BitAssets do not require a fee pool and the BitAsset fees are automatically converted into BTS via the markets to pay the reserve pool?

The easiest thing for us to implement is to have the network manage the BitAssets just like private BitAssets.  This would require the issuer to update the BitAsset's core_exchange_rate property and to fund the fee pool.  In this case the issuer would be the "delegates" account.

Okay. So that leads me back to my previous questions:

Where do the paid BitUSD transaction fees go to after they are automatically exchanged for BTS from the fee pool?
...
Do [the delegates] have the ability to place orders in the [BitUSD/BTS] market funded from that [BitUSD transaction fee] pool where the [BTS] proceeds automatically go into another pool collectively managed by the same group (or even directly into the fee pool)?

Also, is this not asking too much of the unpaid delegates? Are they also the ones who need to set the price feeds for the non-private BitAssets? Aren't operations that require 24/7 online servers more appropriate for witnesses? Or perhaps delegates could delegate the responsibilities (submitting price feeds and converting BitAsset collected fees into BTS to top off the fee pools) over BitAssets to other parties? And maybe a worker proposal is used to compensate these parties?

https://github.com/cryptonomex/graphene/issues/83

I'm confused by this. Does this mean that network BitAssets do not require a fee pool and the BitAsset fees are automatically converted into BTS via the markets to pay the reserve pool?

BitUSD should have its fee pool kept topped off by workers/delegates/witnesses/ automatic market actions.

Where do the paid BitUSD transaction fees go to after they are automatically exchange with BTS from the fee pool? Who controls that account? I imagine in the case of privatized BitAssets it is the creator/manager. But what about regular (public) BitAssets? Do the witnesses collectively control those funds? The delegates? Do they have the ability to place orders in the market funded from that pool where the proceeds automatically go into another pool collectively managed by the same group (or even directly into the fee pool)?