You guys will also be interested in project maelstrom.

It's a browser based on Chromium, made by BitTorrent Inc and is basically a way to make websites into torrents. Popular websites load fast and are completely decentralized. So for example, sites like The Pirate Bay could remain active even if they lose access to every domain. And as long as you're using the Maelstrom browser, they're just as easy to access as any regular website.

Very strange.

I assume they are only useful for static content. I can't see how dynamic websites could possibly work. But I guess most things nowadays are moving to single-page web apps that communicate with the server using JSON over a REST API. So this could allow you to just use your web servers for the API and leave all other content to the decentralized network (which ideally is properly motivated through micropayments).

Cool.

Problem is his model is primarily going to be microtransactions, the thing we are not catering to in 2.0.

Well, his application requires payment channels between a specific sender and receiver. You aren't going to pay Bitcoin fees on each tiny chunk of data. You only need to pay a fee once to set up the payment channel and then another fee to close it and settle the payment. Still, Bitcoin fees are considerably less than the default fee we would be targetting for typical transactions on BitShares 2.0. But there is no reason more creative fee models couldn't be used for other transactions to make micropayments like this reasonable.

First, I think we should absolutely have a min fee, max fee, and percentage fee for transfer operations. For example, transferring X BitUSD from one account to another could charge 0.001*X as a fee converted into BTS through the fee pool, but with a lower bound of $0.005 worth of BTS and an upper bound of $0.50 worth of BTS (if there was no fee pool or set fee exchange rate, the system could default to some fixed value like the upper bound). Blinded or stealth transfers will have to assume the worst case, therefore it makes no economic sense to charge less than the upper bound (which is also why the upper bound is so low, because otherwise stealth transfers would be unreasonably expensive for regular payments).

Second, setting up a micropayment channel would take a very small fixed fee (just to compensate the network for processing the transaction and prevent spam). But for the settlement transaction on the micropayment channel to be valid, it would require an appropriate fee to be paid depending on the amount of the balance going to the recipient (using same formula as regular transfer discussed above).

Here is an example. Alice sets up a micropayment channel from Alice to Bob and initially allocates it with 10 BitUSD. The micropayment channel expires at midnight of that day (3 hours in the future) and is set up to require a 30 minute refutation period. Setting up the channel cost Alice only $0.005 worth of BTS. If no one provides a valid settlement transaction on the micropayment channel before midnight, then the first valid settlement transaction on the micropayment channel added after midnight gets immediately applied. Otherwise, when either Alice or Bob submit a valid settlement transaction on the micropayment channel before midnight, the blockchain waits for 30 minutes (or until expiration time, whichever is sooner) before applying that settlement transaction unless the other party (Bob or Alice, respectively) submits a valid settlement transaction that is more recent (based on sequence number in the signed transaction) than the previously submitted one (in which case that settlement transaction is applied immediately). Each party only gets to submit a valid settlement transaction on the micropayment channel once (and they can even be free assuming they are standard ones that are small in size). Part of being a valid settlement transaction is to account for the fees that need to be paid which depend on the amount of the balance that is allocated to the receiver (in this case Bob). So, if Bob submits the valid (signed by both Alice and Bob) settlement transaction that pays Bob 4.30 BitUSD, it must pay a fee of at least 0.0043 BitUSD converted into BTS and the remainder of 5.6957 BitUSD goes back to Alice. In this case, the total fees paid by Alice are $0.0093 worth of assets for a net transfer of $4.30 worth of assets to Bob. There would still be an upper bound on the percentage fee, so if the micropayment channel was set up with a much larger balance and at the end the settlement sent more than 500 BitUSD to Bob, the fee paid would be limited to $0.50 worth of BitUSD converted into BTS via the fee pool (for a total fee payment of $0.55 worth of assets by Alice).

So we can totally make micropayment channels economically feasible on the BitShares blockchain. In fact the BitShares blockchain is so much better for this torrenting application because you are not going to want to wait 10 minutes to get confirmation that the micropayment channel is set up before sending the data (but with 1 second blocks on the other hand...). It's only problematic when you want to send a lot of small transfers to many different people (that you haven't already set up channels with a priori) where the amounts sent are so small that the minimum fee we are willing to accept ($0.005 in my examples above) is not quite low enough.

Core command line client and basic CLI wallet will be available.

Will it be possible to serve the website from a local daemon but still have it connect using websockets to the third-party wallet host server?

I really don't want my only GUI lightweight solution available at launch to risk my private keys because of a server compromise or SSL certificate compromise.

I'm looking forward to seeing what kind of innovative privatized BitAssets people come up with. For example, nothing stops someone from creating a BitUSD5 (5% APR interest as part of the definition). I wonder how the supply and demand of that asset would work out compared to regular BitUSD as sentiment changes regarding the near future value of BTS (or whatever collateral asset is used) relative to USD. Also, privatized BitAssets could be used to implement the BitAsset 2.0 (the short-lived proposal by bytemaster before the even newer BitAsset 3.0 was renamed to the BitAsset 2.0 that Graphene uses), where the BitAsset creators force liquidation after 1 year, for example, and there could be two staggered versions of this asset. So those assets would be a 1 year bond with some prescribed fixed interest rate and minimum collateral maintenance requirements. The fact that there is a definite end date at which point there would effectively be infinite liquidity at the price feed (or 30 day average price or something) might make the shorts more willing to participate despite the additional risk added from the prescribed interest rate. The users would of course still be responsible for shifting BitUSD5A into BitUSD5B (and vice versa) once every 6 months (assuming they didn't delegate that responsibility to a third-party UIA issuer, with corresponding counterparty risk of course). The main difference between this approach and the collateralized bond market is that the BitAssets would be divisible and fungible. Therefore trading these assets for the normal BitUSD (for example to move from savings to checking or vice versa) could be easily facilitated at any time through the exchange markets on BitShares.

Yeah... this is probably why account names should be in a different namespace than domain names. Or at least fixed-fee pure-ownership account names that can also be used by clients to access a server should have a far less desirable TLD by convention. And the other namespace designed to be used for more professional domain names should have the far more desirable TLD and should be based on a leasing model.

Also, I think we need to get rid of the idea of every account having a name. I don't think assigning a random sequence of letters and numbers as a name is a good solution. There should be a separation between the fee of creating a new account and the fee of adding on a name to the account. Many accounts (especially with stealth transfers) shouldn't need a name at all. Some may even be okay with holding off on adding a name to their main account and just using their unique ID instead. User clients can always use a local alias to map to the unique account ID (and in that case they don't have to be limited to the blockchain constraints on account names, e.g. using Unicode). This also means that the blockchain can charge a far more reasonable fee for non-premium account names than just the cost of creating an account (which should remain low).

So, this thread unexpectedly got me in the mood to write some poetry about BitShares (which is completely uncharacteristic of me). I was just messing around for fun, but I liked the end result so I decided I'll share it with the community.

From the head of one bytemaster
Came ways to avoid disaster
In the cryptocurrency space
While also making blocks faster

The culprit was the proof of work
The whole concept was just berserk
Burning power for consensus
Just ASIC makers get the perk

More centralizing mining pools
Showed status quo would be for fools
A new blockchain would be needed
Made possible with brand new tools

First delegated proof of stake
BitAssets were icing on cake
Decentralized, fast and so cheap
Many of us now wide awake

The market peg just seemed to hold
We now had true digital gold
And though core stake was volatile
BitUSD price stayed controlled

Now more brilliance is on the scene
Since soon we upgrade to Graphene
Transactions per second so high
And brand new codebase that is clean

Permission system that makes sense
Referral program adds up cents
And stakeholders retain control
Their votes control blockchain expense

Who knows what else remains in store
With brilliant devs that we adore
Bringing us liberty through code
Come join us as we all explore

I have voting turned off as I realize that's a dead giveaway.

I think we really need a solution to this that could work with blinded values without compromising privacy much. Otherwise, people who really care about privacy won't vote to the detriment of the network.

I already discussed this elsewhere but I think it is important to allow some semi-trusted third party to claim vote tallies from the blinded BTS balances of some selection of accounts. But it has to be done in a way that prevents the third party from changing the votes (they could only choose to exclude accounts from the vote tally, but not use their stake to vote for someone the stakeholder didn't vote for). So let's say some subset of accounts with blinded BTS balances decide to elect a particular third party to see their BTS balance (by privately sharing the blinding factor with the third party) and aggregate their vote. The third party would specify the account IDs of all the account's vote it will be aggregating. It will also specify a blacklist of delegates/witnesses/workers that it will not aggregate votes for because not enough of the specified accounts are voting for that delegate/witness/worker (which would compromise privacy for the few accounts in the selection that were voting for that delegate/witness/worker). Then for each member in the union of the delegates/witnesses/workers that were included in the votes of the selected accounts, the third party provides a plain-text stake tally and proof that the sum is valid. This proof is a commitment of the tally and a signature proving that fact, where the blinding factor of the commitment is selected so that the sum of commitments of the BTS balances for all accounts voting for the specific delegate/witness/worker (subtracted by the sum of the commitments of the BTS balances for all accounts voting against the specified worker, in the specific case of workers since they can be downvoted) equals the commitment of the tally provided as part of the proof. In other words, for each member X (delegate/witness/worker) add all the blinding factors of accounts approving of X and, if X is a worker, subtract all the blinding factors of accounts disapproving of X to get the blinding factor for the commitment to the tally. This transaction only needs to be provided to the blockchain once per maintenance period to save costs (it is okay if there is even a 1 day delay in incorporating all the votes).

The good thing about this approach is that the third-party cannot lie about the votes (only exclude them). Aggregating the vote results from different third-parties is problematic for the blockchain if the selections of accounts for each of the aggregates have some overlap. The blockchain can always ignore valid vote tally transactions for the same maintenance period from third parties if their account selections are a subset of that of a valid vote tally transaction of the same maintenance period from another third party. But when neither account selection of two different valid tally transactions are a subset of the other but yet do still overlap, the blockchain is forced to ignore at least one of them. To avoid this, each account should only choose one third party to aggregate their vote at any given time. This selection by each account could be recorded on the blockchain, so that any vote tally transaction by a third party trying to include the votes of an account that has not specified them as the third party that is allowed to aggregate their vote is automatically dismissed as invalid. Furthermore, the accounts could publicly put some money in a fund specifically to economically motivate the third party to include them into the vote tally. The third party including an account into the aggregation of a vote tally transaction could withdraw a specific amount of funds from that account. The account may automatically pay the third party some small fee from the fund each day for each delegate/witness/worker that they voted for and that was included (meaning not blacklisted) into the vote tally for the day by the designated third party.

One way to make this better would be if the cryptography could allow each account to publish information on the blockchain that proves that they publicly provide enough information for someone who knows the private key corresponding to some specified public key (the public key of the third party in this case) to be able to derive the blinding factor for the account's BTS balance commitment (but without actually revealing the blinding factor to anyone else who doesn't possess that private key). If the cryptography could be designed this way (some kind of zero knowledge proof), then the blockchain could assume that the owner of that private key (the third party) would include all accounts which provide such valid proofs in their vote tally transaction and had set a maximum pay per day per voting item that was more than or equal to the minimum threshold defined by the third party (and of course had enough funds set aside to pay for that cost of including their votes in the vote tally transaction for that day). This would mean that the third party would not need to specify a long list of account IDs as part of the daily vote tally transactions (meaning smaller transaction size and lower costs). Obviously in that situation the third party would be forced to include the votes (with the exception of blacklisted delegate/witness/worker votes that hardly anyone voted for) of every account that elected them to aggregate the vote and provided the valid proof and had enough funds designated for the purpose of paying the necessary costs, since that is what the blockchain protocol would expect from the vote tally transaction submitted by the third party.

i maybe dumb ....but what if I change every written code to achieve the same function while there is no way that you can call me copy , will that still be IP violation ? while copying all the idea .

The true answer is who the eff really knows. But this is likely very relevant: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc..