At that time they will face a choice:

1.  Honor the vote at the time the decision to spend money was made, or
2.  Honor the vote at the time the product is delivered (if it has changed in the mean time).

Acting against the wishes of Vote 2 could get them fired if enough people disagree with them keeping the implied commitment of Vote 1.

Acting against the wishes of Vote 1 means that BitShares gets a reputation for reneging on a prior vote upon which an entrepreneur has relied.

That could have a chilling effect on BitShares ability to attract more entrepreneurs.

This means that even if some voters have changed their minds about STEALTH by installation time, they might NOT decide to fire otherwise faithful witnesses for deciding to obey Vote 1 in order to preserve BitShares' reputation in future deals.

Please explain where your think the above process could be improved, given the tools available at this time.

Make a decision (develop the hard fork or not) based on the result of a one-day poll makes much sense?

Quote from: Ray on December 19, 2015, 02:39:24 pm

Quote from: xeroc on December 17, 2015, 10:20:38 pm

Make a full wallet backup right away and store it somewhere safe TOGETHER with the passphrase ..

First, I had a the older wallet and got the password and passphrase down on paper. Does the passphrase change when upgraded to 2.0? Or is there another passphrase generated?

Thanks

The passphrase does not change. It's the same.

I do use different passphrases for 0.9 and 2.0.

Technically, the refund400k is

Code: [Select]

>>> get_object 1.14.0
get_object 1.14.0
[{
    "id": "1.14.0",
    "worker_account": "1.2.90742",
    "work_begin_date": "2015-10-20T17:30:00",
    "work_end_date": "2035-12-31T00:00:00",
    "daily_pay": "40000000000",
    "worker": [
      0,{
        "total_burned": "1742631985322"
      }
    ],
    "vote_for": "2:65",
    "vote_against": "2:66",
    "total_votes_for": "21716971826670",
    "total_votes_against": "7192913280182",
    "name": "refund400k",
    "url": ""
  }
]
Looks like the fund to this worker is "burned".

Technically, the refund400k is
>>> get_object 1.14.0
get_object 1.14.0
[{
    "id": "1.14.0",
    "worker_account": "1.2.90742",
    "work_begin_date": "2015-10-20T17:30:00",
    "work_end_date": "2035-12-31T00:00:00",
    "daily_pay": "40000000000",
    "worker": [
      0,{
        "total_burned": "1742631985322"
      }
    ],
    "vote_for": "2:65",
    "vote_against": "2:66",
    "total_votes_for": "21716971826670",
    "total_votes_against": "7192913280182",
    "name": "refund400k",
    "url": ""
  }
]
Looks like the fund to this worker is "burned". Is init0 able to change the destination of the funds in the future?

//Update:
Since this thread has been dig out recently, I'm updating this message.

The refund400k worker IS a refund worker, although it has a "total_burned" data field. init0 is unable to change the type of worker or destination of the funds.

More info in this thread: https://bitsharestalk.org/index.php/topic,20793.0.html , quoted below:

Those that have an initializer of "0" are refund, those with "2" are burn.
An initializer of "1" would be a regular worker with payout to the creator.

Also see
* http://docs.bitshares.eu/bitshares/user/worker.html
* https://bitsharestalk.org/index.php?topic=22486.0

Quote from: roadscape on December 19, 2015, 04:06:43 am

The memo key for that account is BTS1111111111111111111111111111111114T1Anm, and it appears to be the same for a few others I checked. I believe this means that it's impossible for anyone to read the memos.

Have you sent memos to collateral-holder accounts before?
Can you leave the memo blank as a workaround?

Oh, hmmmm, that's interesting. I had just assumed this was a completely normal account with a custom name. Why would it have an invalid memo key?

Interesting. Maybe something wrong with the genesis file?

So just this little item remains a mystery for me:
"Price per KByte Transaction Size" - when does it apply?

http://cryptofresh.com/fees

For example if you transfer or issue some assets with memo it will apply. Imho it's rather annoying, since most transfers are with memos, as a result fees are always different and fractional. We'd better set a "free" memo size which charges no extra per KBytes fee.

I have a couple of questions regarding transfer fees for UIAs (and private MPAs):

(1) A newly created UIA has 2.5k BTS in its fee pool. I know I can easily add funds to the fee pool but who funded the initial 2.5k BTS?

Half of the creation fee.

(2) Is it true that 100% of the transfer fees on UIAs (and private MPAs) belong the issuer? (as they show as Unclaimed Issuer Income in the GUI)

No when fees are paid in UIA, some BTS (amount is defined by the fee schedule) are deducted from fee pool and paid to the network/referral program, and UIA paid to the issuer. Except the % market fee (by now) which goes to the issuer directly.

(3) If (2) is true, does it mean that:
(a) the BitShares network alows to transfer UIAs (and private MPAs) back and forth between BitShares accounts without getting any revenue for this service?
(b) transfer fees for UIAs (and private MPAs) are exempt from the referral program?
(c) the issuer of UIA (and private MPA) can set the transfer fee on their asset to any arbitrary level (or even zero) by adjusting the Core Exchange Rate?

(4) What is the meaning of "Price per KByte Transaction Size" listed in /explorer/fees?

@jakub How about the STEALTH work proposal (1.14.18)? It seems to have already been approved.