even if we want less witnesses they must be dynamic auto changing...
nobody will successful accuse us for the number of witnesses when they know the decision was made from the blockchain-code and not decision's made from one individual, in our case Daniel Larimer (doesn't really matter the name)...

Quote from: spartako on September 21, 2015, 11:10:52 pm

What is the best practice for not missing any block during an update?

The update_witness command in CLI wallet allows you to change your witness's block signing key.  This architecture allows several different downtime-free update procedures according to your specific hosting situation:

(1) Create new witness on new server with new block signing key (you can use suggest_brain_key in CLI wallet, or the get_dev_key binary, to generate a new key).  When the new witness is synced, run update_witness to change your key, shutdown old witness and delete old server.  Good method if you use a pay-by-the-hour hosting provider that lets you quickly create and destroy servers (e.g. DigitalOcean).

(2) Create new witness on the same server with new block signing key in different datadir.  When new witness is synced, update_witness to change your block signing key and shut down old witness.  Good method if you have a large server capable of running two witnesses at once (e.g. dedicated host).

(3) Create temporary witness on your own personal machine.  When it is synced, update_witness to change your block signing key and cause the temporary witness to start producing.  Then shut down the old witness and spin up the new witness on the same server; it is okay if it takes some time, because your temporary witness is still signing blocks.  Then when new witness is ready, run update_witness again to change your block signing key back (or create another new key).  Good method if you have a decent personal machine you can occasionally put on witness duty for a few blocks when you're doing an upgrade, and don't want to mess with multiple VPS's as in (1) or pay for a large server as in (2).

Also note that the block signing key can be different from the active and owner keys which control account funds.  The only key which needs to live unencrypted on a machine with 24/7 internet connectivity is the block signing key; if an attacker compromises the server, the only thing they can do with the block signing key is sign blocks.

I designed this system, and my goal was to give witnesses better options for dealing with the various IT headaches of signing blocks in DPOS.

I just gave update_witness quite a real-world test on this testnet -- I initially ran all of the init witnesses in a single process on the cloud server that I used to create the testnet, then bytemaster and I migrated a bunch of them to different machines within the first day.  In prepping them for the hardfork, I've had to shut down and re-create the witnesses, and also migrated them to better balance them between the multiple machines.  I used the update_witness command for all of this and achieved it with minimal downtime.  In particular for today's hardfork upgrade, I had no downtime on block signing during the upgrade / migration, even though I had to upgrade 8 witnesses on multiple machines, and I also migrated some of those witnesses to better balance them between machines.  The update_witness code and its supporting logic in the block production loop are rock solid!

Some of my init witnesses have been down, but that's mostly due to issues in the p2p layer, the worst of which are resolved in the latest code.

I think I'll write this up in a wiki article sometime this week

I do plan to attend this event in China for Dan, since we can't have him in the air on Oct 13 or 14th.

I hope to talk about

Real Time Block Chains and the Jump to Light Speed.

What is a light speed blockchain?  Simply put, it is one whose transaction times are only limited by the speed of light and the dimensions of the planet.

And a real-time blockchain?  That’s a chain able to keep up with real world events and react to them in time to influence their outcomes. 

Applications range from global markets to video games.

Quote from: betax on September 21, 2015, 09:02:33 am

Hi what chain / snapshot are we using? **confused***

This is the chain:
https://github.com/cryptonomex/graphene/releases/tag/test3

You do know that you can list a bunch of "problems" for the most advanced aircraft carrier right ?

The competitive edge of Bitcoin is the liquidity , marketcap , network effect , not technology .

You can bash bitcoin's technology all you want , but in the end you would just push away a major community that's open minded enough to invest in something "so lame , so slow , so old" . If they're opened minded for something "so lame" , imagine what they would see in BitShares if you present it well ?

The best way to achieve the success for BitShares is to grow the whole crypto and blockchain industry instead of hoping people would abandon bitcoin and come to jesus .

Like it or not , Bitcoin will grow , the blockchain industry will grow , multiple projects will grow , even the ones lamer than Bitshares , even the ones who refuse to take BitShares's technology , even the ones with 1 hour confirmation . And investors are investing in the whole industry instead of a single project now .

You have to adjust your expectations . You don't need people to sell their bitcoin and buy Bitshares . You need people to buy Bitcoin and Bitshares because they're both awesome .

And there are many ways to show how awesome something is . Making people think they're not wise enough to choose your product is not a good way . At least not a good way for a project that's suppose to gain the most network effect as possible .

Come back to the question in OP . It's not a matter of "good" or "bad" or "problems" , it's about the suitableness in specific applications . You should link the features to a specific application to sell it , such as high volume stock trading .

Imagine a world where people use Bitcoin as currency in a major way , and businessmen use BItShares to issue and trade stocks , and Bitcoin would be still slow , lame as hell . So what ? Who says that's not a win for BitShares if other project still succeed with lame features while BitShares also succeeded ?

Quote from: betax on September 16, 2015, 08:37:22 am

Hangout Date in Question: I attended 9/4/2015 and 9/11/2015
Mumble Name; betax
Forum Name: betax
BTS Account Name: betaxtrade
Have you put in a request in the Google Spreadsheet Document?  (Yes/No) Yes now.
Other Comments: It seems that in the last hang out the logs for for after the event. (at least the ones of pastebin), either way I'm on both dates logs. Thanks fuzzy.

i see you

9/4/2015


9/11/2015