look at this <<Death and Bitcoin>>
 https://letstalkbitcoin.com/blog/post/death-and-bitcoin

do we have more graceful method to resolve this at Bitshares 2.0?

Use the withdrawal permissions with a start date 1 year into the future and really high withdrawal limit that your beneficiaries are authorized to withdraw from. Then once a year (before the start date is reached) update the withdrawal permissions to push it forward another year into the future. You can also create multiple ones (or at least I hope you can) that are staggered (say by two weeks), each with their own authorization on who can withdraw. That way you can have fallbacks in case some of your beneficiaries are also dead or otherwise incapacitated, in which each beneficiary in the queue has a two week opportunity to claim the inheritance before it moves on to the next in line. The last fallback could, for example, be a withdrawal permission that your favorite charity has authorization to withdraw from.

But I can imagine it might be possible to create UIAs on the bitShares block-chain that are backed by BTC, LTC, NXT, you-name it, as long as there are ways to minimise counter-party risk through appropriate operations like multi-sig, escrow or the like. To be honest I don't know if side-chains help with that or not, I'm naive in that area, though I've asked the question before.

Yes, UIA gateway assets (like GATEBTC) + the new privatized BitAssets should make this possible. The only question is if the trust can be decentralized out to many parties to keep the counterparty risk is low enough for people to use it for more than just a means of quickly getting value in an out of the system to/from assets without counterparty risk. On the BitShares side, the new multisig features provide a lot of flexibility for managing the UIA properly (e.g. not diluting its value). The limiting factor is on the Bitcoin side. It doesn't make sense to have more decentralization on the BitShares side than on the Bitcoin side when the UIA could become worthless if the reserve is stolen. Ignoring advances in ECDSA threshold signatures (and assuming Bitcoin does not adopt new cryptography like EdDSA or radically increase the limits on their scripts), we are currently limited to an M-of-15 multisig for the BTC reserve backing the gateway UIA. You want M to be large to reduce the risk of compromise but obviously not too large that it dramatically increases the risk that the reserve holders get locked out of access to the reserve because some of them become unresponsive or disappear. Not sure what would be the ideal value for M, but the main question is if a well selected group of 15 individuals/organizations can be trusted to not collude to steal a potentially huge reserve. If not, very few people would trust holding the BTC-backed UIA for long term or holding BitAssets that derive their value from such UIA.

By the way, I agree with others in this thread that side-chains are not the way to go (for technical reasons, e.g. PoW) to bring BTC tokens into the BitShares blockchain.

By the way starspirit, I don't see how the BitAssets backed by a mix of collateral types would be fungible unless a fixed mix ratio was specified as part of the BitAsset definition that all shorts of that privatized BitAsset had to satisfy. And in that case, I would imagine the only practical way to short new BitAssets with mixed backing collateral into existence would be through a self-short. The logic for margin calls would also get more complicated with mixed collateral.

Well first all these numbers including the total supply can be changed with hard forks if there is enough shareholder approval. But let's consider what is possible without hard forks. Also, let's assume another change to increase total supply above 3.7 billion BTS is so undesirable that we would "never" hard fork to do it. If the rate at which BTS is pulled from the reserve pool follows the same hard-coded rules of the current BitShares system (5 BTS/sec and halving every 4 years), then there is effectively no difference from a dilution standpoint. However, if a majority of the delegates are able to change this number, then that is a different system than what we currently have. Dynamically adjusting the number makes it much easier for a large enough quorum of stakeholders to effectively retroactively reclaim funds that we earlier "burned" (but still never exceeding the 3.7 billion BTS hard limit, assuming no hard fork). But I don't think that is necessarily a bad thing. I would like clarification on whether the rate that is pulled from the reserve pool is set by delegates or hard coded (or maybe it is set by delegates but with a hard-coded upper limit?).

Regarding the bond market, I have some other concerns actually, but I rather just wait until more information is provided. Personally, I consider it a work-in-progress that will likely be greatly improved over time. I'm just glad that it is being considered a priority though.

Regarding the high transaction fees, I believe different operations can have different fees set by the delegates (is that correct?). If so, my concerns about the fees is greatly reduced. I think that certain operations like updating an account's votes and placing and cancelling limit orders should have very low fees (in fact, I think we could just get away with making cancelling orders free without worrying about spam issues). We shouldn't penalize people who update their votes because they help keep the system secure and running properly. And high fees on placing and cancelling limit orders hurts bots which will hurt market makers and thus liquidity. I would rather have very low fixed fees on placing market orders and have percentage fees on the matched volume instead (but still at a lower rate than our centralized exchange competitors). But I am fine with all other operations (including transferring assets from one account to another) having the higher fixed fees for the sake of the referral system.

I'm wondering what will be the practical hard limits on the number of delegates, witnesses, and worker proposals that an account can vote for.

I also worry that managing the worker proposals will be a little challenging. The order of the workers is very, very important in terms of who actually gets funding. But the voting process does not allow a user to represent the ranking they would like via their slate selection. Approval voting is great for the delegates and witnesses where the actual order is not as important (as long as you are in the top N), but I am wondering if there is potentially a better voting system for aggregating stakeholders' preferences for worker proposal rankings into a single global ranked list of worker proposals.

Also, I think it would be a huge improvement if worker proposals could specify daily payment in units of some BitAsset and the blockchain could use the daily moving average of the price feed of that BitAsset to dynamically calculate the amount of BTS to add to their account for that day (assuming the budget allows of course).

Wow, great work. Can't wait until it's released.

A few things I was pleasantly surprised to hear:

• The new blockchain processing architecture changes (and corresponding performance improvements) sound really amazing.
• The new permission/authorization system is also really great.
• Transferable account names!
• Finally the recognition that maintenance collateral is all that matters to support the peg. I assume this means shorts will be able to adjust collateral levels up and down as long as it satisfies the maintenance collateral limit, and actual partial covering is possible. Also, I would like to hear more about what a forced margin call is like in the new BitAsset system.
• Actual limit orders! No WYAIWYG.
• Bringing back TaPOS for added security (though it is optional).

I'm a little sad to hear that even the minimal existing barriers (in the form of TITAN) to prevent people from getting your transaction history and balance amounts will be removed (even though to someone sufficiently motivated they weren't actually protecting anyone's privacy), but I guess I expected that and it does provide a lot of other benefits. I just wish we can have some other tools later to help manage our privacy better.

One thing I am a little concerned with is if the fact that unique IDs are used rather than hashes means there are more vulnerabilities for successful attacks from a fake blockchain attack. If someone is able to fork everyone over to a new blockchain history with changes in that last 10 blocks or so could they possibly somehow cause someone elses transaction that was meant to send someone else funds send the attacker the funds instead if the attacker is able to "take over" the ID number the transaction was referring to? I guess I would need to actually understand how this new BitShares 2.0 blockchain engine works before I can better articulate this concern. Perhaps TaPOS where the transaction refers to a recent block on the correct chain could help prevent any potential attacks like that (if such attacks even exist)?

Another thing I was thinking about while reading about the changes was how the state is committed to disk only on exit. I understand that it stores the blocks to disk as it receives them so that it can always recover the database state from scratch if necessary. But I don't see why it couldn't periodically commit the database state to disk so that if it fails it doesn't need to replay from the last time the program successfully exited (which may be a long time ago). In fact, if memory usage is so low, I think it would be cool to use just double the memory by using some memory page copy-on-write system to take a snapshot of the memory state while continuing to evolve the other copy, and then asynchronously serializing the snapshot copy to disk. Then when that serialization is done, the memory of the snapshot copy can be freed from RAM to repeat the process over again by taking a snapshot of the evolved copy. In fact, maybe the serialization can be delayed by some period to ensure that the time limit for chain reorganization has passed and so that you know you (almost never) would need replay the blockchain from any committed state older the most recent one, which is probably less than 5 hours old.

Then there are the few things I would have really liked to see if we were going to have such a huge change that requires a complicated migration strategy, even though I of course didn't actually expect to see them. The biggest would be a way of repeatedly and asynchronously committing a snapshot of the state (one that could be agreed upon via the consensus protocol) to a single cryptographic hash that could be committed and approved by all the witnesses as part of their responsibilities. This could allow users to quickly bootstrap to the current state of the database using a copy of a recent serialized snapshot state (which would be less than a day old) and a trusted hash of a recent block. I know that the new engine should speed up replay dramatically, but this would also allow the node to not need to download the entire blockchain either (and they may be constrained by bandwidth more so than CPU speed) as long as they didn't care about transaction history. And in the long term, one of the old snapshot states (that everyone for sure agreed was valid) could effectively act as the new genesis state and allow for blockchain pruning to save disk space. Furthermore, if the commitment of the state snapshot to a single hash was done intelligently, it could allow anyone to provide small proofs of the existence of objects in the database state at the time of the snapshot, where the verifier only needs to trust that the majority of witnesses at the time they committed the hash of the state snapshot to the blockchain did not collude to provide a false proof. This could allow lightweight clients and hosted wallets to (independent of further participation by witnesses) provide the user extra assurance that their view of the database is correct (even if that extra assurance is delayed by a few hours).

Finally, I hope you guys haven't given up on the following:

• Hosting the web-based GUI interface locally. I of course would expect to be able to run a full node and have the web-based code running in my browser to connect the local daemon running on my local machine. But I would also like to be able to run a lightweight setup where the browser-based GUI securely connects to a trusted public server instead even if I am serving the browser code locally rather than from some other server. I don't want the only official lightweight GUI setup for using BitShares to require us to hope that a MITM attack (likely made possible with compromised certificate authorities) hasn't replaced the browser code with a version that phones home private keys. For regular users, I hope this also means that you are still working on a Chrome web app packaging the browser-based GUI to reduce the chances of a MITM attack.
• Will you still be working on the mobile QML wallet? Will the new web-based GUI be responsive and adaptive enough to be used on mobile? Even if so, I can't imagine that it could be as capable as an app specifically designed for the mobile platforms (Android and iOS). Will you not focus on this and instead allow third parties (e.g. ElMato's LimeWallet) to build the mobile-optimized BitShares clients?

I think hard forks should be few and far between so everyone can rely on a stable platform rather than a moving target.

Agreed, but that is very different than "our LAST hard fork".

Also, as long as the API for Turing complete smart contacts (or DApps, etc.) does not change with the hard fork, I see no problem with having hard forks as frequently as once a year (if there is something worth to update that is). Changes of that nature would not affect any of the work other developers have done to build on top of BitShares but could provide much needed improvements to the protocol.

You can find that information here: http://whatarenotes.info/

Under "NOTES VALUE":

Quote

One of the differences between the current BitShares blockchain and the upcoming BitShares Music blockchain is that the BitAsset market engine will be removed. BitShares Music will serve as a distributed, on blockchain, market for all UIAs. This includes both artist tokens and USD pegged IOUs created and issued out by gateways that protect all users and artists from volatility.

Gateways provide the on and off ramp to/from fiat_USD to crypto_USD.

Those that fear counterparty risk from the gateways (you must trust the gateways to redeem the IOU_USD for a real USD) can move their funds into BitAssets, like BitUSD, BitCNY or even BitGOLD, on the BitShares blockchain since BitAssets are free from counterparty risk.

Under "UPCOMING WALLET":

Quote

Moonstone.io will be integrated seamlessly within PeerTracks from day one. Moonstone allows for low trust crypto-to-crypto exchange between multiple different blockchains. This will provide much needed initial liquidity for BitShares Music. Initial crypto pairs available on Moonstone include:

    Bitcoin
    BitShares (Including all UIA and BitAssets like BitUSD and BitCNY)
    BitShares Music (including all artist tokens and gateway IOUs)
    BitShares Play

Moonstone provides a simple exchange interface for both markets within the corresponding blockchains and in between blockchains.

Hope that helps.

Thanks.

I can understand Moonstone providing some ACCT functionality for trading between assets of different blockchains. But I was surprised to learn that BitUSD on the Music blockchain has essentially been replaced by IOU_USD (I guess I missed that change). But I think the claim that those who want to be free from counterparty risk should just hold BitAssets on the BitShares blockchain is a little misleading. I don't think you will be able to use the BitUSD on the BitShares blockchain to buy music directly. You would need to do a two-step process. First do ACCT of the BitUSD with the IOU_USD and then use the IOU_USD to buy the music on the Music blockchain. This is because I imagine the blockchain mechanisms (having some percentage of purchasing funds go towards to the artist and some to NOTE holders) require that the purchase operation be done on the Music blockchain with tokens that exist on the blockchain (which BitUSD does not).

Also, although apparently Moonstone will allow you to do ACCT of BitUSD on the BitShares blockchain with artist tokens on the Music blockchain (therefore only needing one step, not two, if your goal is simply to get the artist tokens), it is still not the same as trading on a DEX. A DEX allows you to place your orders without the couterparty of the trade known a priori and just wait until it is automatically matched and filled by the blockchain with no further effort necessary from you. ACCT don't quite have those nice properties. My guess is that Moonstone will not try to use ACCT between two different parties but will rather act as the sole liquidity provider for Moonstone client users that want to (conveniently) trade between assets of the blockchains listed above. So you may not necessary get the best deal available, but that is the cost the user must pay for convenience.

The other thing I am wondering is whether Peertracks actually expects to have a fiat gateway available by the time they launch? Are they going to go through all that regulatory process to provide the USD gateway? And what about initially providing a multisig BitUSD gateway (since that doesn't have regulatory issues) if getting the fiat gateway online ends up adding too many delays to the initial release?

Basically, a new DAC is launching to focus on entertainment startups that want to leverage the functionality of BitShares. This DAC won't have market pegged assets and will function autonomously from BitShares. Multi-currency wallets such as moonstone will act as the bridge between multiple chains, so one can still trade between artistcoins issued on the Entertainment DAC and bitUSD issued on BitShares.

Citation needed.