I would go further than my original proposal.  I would say for any funds transferred out of your account you have up to a week to permanently freeze the funds.

People need to understand the concept of "seasoned" funds.  It is critical that you cannot participate in any internal BitShares market (such as buying and selling BitUSD) unless your funds have been seasoned for one week.  You must have kept the balance without moving it for one week before you can use it to participate in the market to buy/sell assets.

There is really no reason for anyone to permanently freeze funds that left their account unless it is a legit fraudulent transaction.  Also people can protect themselves by demanding seasoned funds when doing business with people they don't know well or for large sums of money.

As far as what to do with "permanently" frozen funds... I think this is a secondary issue and can be addressed in many ways that take advantage of community consensus.

The most important thing is to give people the power to freeze fraudulent funds.  DO NOT let people participate in the internal marketplace without seasoned funds.  And educate exchanges on the concept of seasoned funds.  This will be a BIG deterrent to hackers and fraudsters.

What's the advantage of this over holding funds in multisig escrow for the week in question, or for however long the specific related business is ongoing?

Incentivizing delegates to pursue consensus rather than just enough support to stay in makes sense to me.  Max Delegate Pay = (Approval Rate / Highest Current Approval Rate) could provide such incentives with less startup shock.

It seems like a lot of people missed the fact that there's a hard cap on this, possibly because some of those arguing for the gradual release of stake through delegates were also arguing against a cap.  The cap is why I stopped arguing against this, because with the cap it is nothing more than the developers delegating the distribution of their stake to the protocol, rather than true inflation.

The strength is that it allows voting on diverse delegates to receive funds for growth without relying on any bottlenecks, and could allow replacing developers.  The weakness is that delegates offering payment for votes or other "pork" spending for some stakeholders could loot the development fund if they get enough support.  I think a significant amount will still go to the intended purposes, so with the amount at risk capped I can accept that.

Quote from: G1ng3rBr34dM4n on July 23, 2014, 01:40:58 am

Quote from: bytemaster on July 21, 2014, 03:57:07 am

Quote from: BTS Ninja on July 21, 2014, 02:10:59 am

@BM

Correct me if I was wrong. I am using the Windows package. When I was tried to move the wallet from one PC to another PC. I go to roaming folder and copy the wallet folder inside the BitShares X folder along. I saw that it works fine. Is it a good way to move/backup/restore the wallet?

I see that we have the backup option to export the .json file. I think it is used for backup at this point of time. The import function doesnt work yet?

Import works, it is just not user-friendly.  Your approach also works.

Can someone explain how to do this (through the command line??). 

My wallet crashed on one computer and I couldn't re-install and get it to reopen (Mac version, reference post here: https://bitsharestalk.org/index.php?topic=5968.msg79809#msg79809  At least one other is having this problem too).

Able to get wallet operational on another computer but can't figure out how to import .json file.

HELP 

edit: I also wanted to mention this is for a registered account on the blockchain, if it makes any difference.

Alright an update on my attempts to import the .json file:

Tried to use: wallet_create_from_json <json_filename> <wallet_name> <imported_wallet_passphrase>

and then received:

Code: [Select]

wallet must be open to execute this command. You can:
(o) Open an existing wallet
(c) Create a new wallet
(q) Abort command
Command aborted
So I type: (c) and get

Code: [Select]

>> (c)

Error: invalid command "(c)"
If anyone else has figure this out, let me know... I'm not a CS savvy guy, but I'd appreciate any help.  Happy to tip you. 

Try c without parentheses.

The only way I think 2FA makes sense in this context is by using multisig.  TOTP/HOTP is useless for wallet security, as you might as well just store a 2nd key instead of a TOTP/HOTP token and eliminate the need for a trusted third party verifying your OTP.

I'm very much in favor of making things like multisig, paper wallets/cold storage, and offline signing easy and accessible through the UIs in order to give each user strong personal control more easily.  I'm against any system that puts the community in the position of taking shares from a supposed thief and transferring them to a supposed rightful owner, or allowing payer initiated chargebacks.  Such things invite more fraud than they prevent, and the new fraud is more arbitrary and less preventable than the previous.  Just look at the forum exchange scams relying on Paypal.  If I lose my shares or have them stolen, I want it to be because I was lazy or careless and didn't maintain control of my keys properly, not because a weakness designed into the system motivated a con artist to paint me as a thief so he could play the victim.

It seems like if the transaction is reversible until a certain point, you might as well just wait until that point and then send it irreversibly.  Reversible transactions just seem to invite fraud.  An escrow system that allows destruction in the case of failure to agree makes more sense to me.

The difficulty with this concept is that once a key is compromised (barring pre-established multisig), the attacker is on even footing with the victim, and there's no way to tell them apart.  The attacker can just take half, and if you report his half as stolen, he'll report your half as stolen.

It would be interesting to have a class of account that could only send to multisig accounts requiring confirmation from a designated guardian address.  That way no one who compromised the key could get the funds, but sending still makes an irreversible commitment.

I think the #1 thing that everyone here is missing in the pre-allocation vs time-release allocation is that under the time-release the shareholders have an opportunity to change who receives the funds and how much after getting to observe performance.   With pre-allocation you are effectively stuck with one development team and a fixed fee.

So from my perspective an allocation of 20% AGS/PTS and 80% delegates over the life of the DAC is greatly preferable to 20%/80% preallocation.  It is certainly more flexible, keeps the majority of the pre-allocation off of the market  and gives AGS/PTS holders 100% control over the allocation of these funds without violating the social consensus of 10/10/80

In fact the only thing that I think needs to be decided is the release schedule for the 80%.

I at least am in agreement with you on that, but the time released shares your suggesting are still preallocated and limited, which is the key point for me.

I think for completely new development with no live network, AGS was brilliant for providing time released dev funding, and allowing the community to watch development progress and fund more or less depending on promise, rather than going in blind.  Preallocated time-released shares can do the same thing for a network post launch, with the added benefit of being able to divert funds to competing groups.

There still may be some delegates who take the pork barrel spending approach, but the impact is more limited.  Before the network reaches near saturation the shareholder's interests should all be closer to aligned anyway.

Quote from: Troglodactyl on July 05, 2014, 10:10:59 pm

I would only consider a 49/49/2 (pre dilution) allocation fraudulent if the initial allocation was advertised to investors, while the fact that this was not the final real allocation because of dilution was left out.  When you asked if I would prefer 10/10/80 without dilution or 49/49/2 with dilution, the final distribution was omitted.  Without stating the final distribution, or even the maximal rate of any additional distribution, the 49/49/2 initial distribution is completely meaningless.  It's all marketing and no substance, which is a good indication of fraud.

Actually I said with "49/49/2 with reasonable dilution".  I think we can reasonably agree what I meant by that without arguing details.  You're now insisting on final allocation.  Ok....  but I did at least address that the dilution wasn't just something fixed rate without bounds.  You've ignored that though or don't remember it.  I think this points out how much people lack objectivity when looking at these things.

Sorry, I was overly harsh there.  I agree that preallocated/limited dilution can be a good way of funding ongoing development and marketing in the early stages.