Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Agent86

Pages: 1 ... 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 ... 32
211
General Discussion / Re: Stolen fund alert system?
« on: August 19, 2014, 03:02:03 am »
The reality is that exchanges shouldn't keep more than 10% of their funds in a hot wallet.
I3 should probably get in contact with exchanges to make sure they are following this type of advice and that they are using good security practices, and if they are not we can warn people.

As far as I can tell the wallet is not super user friendly for cold storage, there should probably be a built in instruction guide in the wallet for cold storage.  Some posts about cold storage don't get too much response:

https://bitsharestalk.org/index.php?topic=6232

212
General Discussion / Re: Stolen fund alert system?
« on: August 19, 2014, 02:56:36 am »
I think the protection needs to be done "off chain" rather than adding a bunch complex stuff that disrupts the on chain behavior.
In my opinion... the type of numerous large thefts that have happened in NXT are unacceptable.  It is irresponsible and unfair for us go out and convince people to be a part of BitShares or hold shares or BitUSD in an online wallet if our security policy is "thefts will happen... shrug".

I think this proposal adds a very significant amount of additional security/safety and in the absence of a compelling other plan it is worth additional complexity.  I don't think this specific functionality can be done "off chain."

My feeling is that this is well worth implementing and is important.

Security is sooooo important...  all this talk about people not voting enough is more related to peoples' fear of losing their stake than anything else.

It is CRITICAL that we can explain to users and shareholders how to safely protect their stake from loss.  We need to be able to explain this in a succinct and honest way that does not sugarcoat any risks.  We should really have a comprehensive security guide for BTS holders. This is only fair.  If we want this to catch on we need to give people the tools to be able to sleep comfortably and hopefully without a huge amount of technical expertise required.

213
General Discussion / Re: Stolen fund alert system?
« on: August 19, 2014, 02:12:32 am »
Ok, I see where you're coming from now.  I was looking at your proposal from the perspective of being tricked into sending funds, rather than a key compromise.  2 of 2 multisig escrow does work for the scenario of a merchant failing to deliver goods, since the funds will be frozen until both parties are in agreement.

How I would attack a system that allowed freezing as you suggest (if I were into that sort of thing) is by only taking half of the funds from a compromised account.  Then if you freeze my half, I'll freeze your half when you try to salvage it.  This decreases the profit of compromising keys, but adds a level of uncertainty to the system that I find unpleasant.  I think it could be a good idea as on optional alternative account type, but I'm attached to the reliability of the irreversible payment account.
I don't think your method of "attack" is realistic.  First you have to somehow contact me and tell me your demands before I notice the theft and freeze the funds.  Then you have to somehow convince me to trust you in this deal...  You have to voluntarily take less than you could and then voluntarily go out of your way to alert me to the theft and to the process of freezing funds and then hope I don't freeze your funds anyway.  I don't think it's smart behavior.  Secondly, if there is community consensus that it is a theft like the bter NXT hack it could be rolled back after the funds are frozen so no need to negotiate.

214
General Discussion / Re: Stolen fund alert system?
« on: August 18, 2014, 11:23:54 pm »
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?
A multisig escrow does not accomplish the same thing.  For multisig escrow you first need to find a trusted third party entity to use as an escrow and even still there is a chance that your password to access the escrow can be compromised at the same time as your priv key.  2FA with a very good responsible trusted escrow service is certainly helpful and I support it, but it's not the same thing and we don't have any trusted 2FA escrow service for bitshares yet.

With my proposal you can generally go about business as normal unless you are dealing with large sums of recently moved money and people you don't know well.  Only if there's a problem (your priv key is stolen and you are robbed) you have a week to mark the transaction as a theft/fraudulent and freeze the funds.  You then deny the thief any benefit and if you are fortunate you may even be able to convince the community to take some corrective action.  This idea can help when a problem happens even if you were a little careless in planning and protecting your key.  I think this system will rob thieves of profit so they are much less likely to go to any effort to try.

For the record, I support multisig escrow services, offline transaction signing, all of the above in addition to my proposal.

215
Also - Is it even possible to trace funds if the thief creates a 2nd wallet.

Owner -> thief wallet #1 -> thief wallet #2 ?  Can we even detect that because of TITAN or is it necessary to do a full rollback ?
Yes, you can still trace funds; Titan just prevents you from knowing the account name that the specific address is associated with.  Even if inputs were combined you could still determine what portion of an unspent output was fraudulent funds.

216
General Discussion / Re: Stolen fund alert system?
« on: August 18, 2014, 10:54:58 pm »
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.

217
My preference is something along the lines of this: https://bitsharestalk.org/index.php?topic=5504

I would actually go further than my original conservative 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 really 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.

218
KeyID / Re: TLD suggestions for Agent86's model.
« on: August 07, 2014, 11:25:59 pm »
What do you think of having the "good" sale model be for other "TLDs" (as opposed to having a single "good model" TLD)?

So initial model names are "example.own.p2p", but then all others would be "example2.p2p" ?

Do you think there needs to be a sub-TLD which experiment with the leasing model before it is promoted to a full TLD?
+5%  these ideas seem fine to me.

219
KeyID / Re: TLD suggestions for Agent86's model.
« on: August 07, 2014, 10:53:55 pm »
I think arhag may share my view that the ownership model with fixed nominal renewal is not going to end up being very valuable and it's a shame to waste a more broadly descriptive TLD idea like .p2p on it.

I support arhag's proposed naming scheme.  I also like ".own"

220
KeyID / Re: Allocation proposal v3
« on: August 07, 2014, 08:29:32 pm »
What specifically do you hope to accomplish by launching a copy of the toolkit and calling it DNS?

I'm not trying to be a jerk, but what exactly has been accomplished toward DNS?  We had a video and short beginning draft of a whitepaper with some auction parameters and those parameters have apparently now been changed in the last month or so, but if there was an announcement I missed it.  I still haven't figured out the purpose of complex one-time auctions.  So now we are acting like we're ready for launch and you want to divvy up the allocation of stake in this well developed project?!  Where's the project?  I don't see it.

A lot of people will need to work hard to get a new DNS to get a network effect and fully reach its potential.  If you don't have a means to compensate that work and allow new people a way in, it won't work and will be overtaken by smarter competition making smarter business decisions IMO.

221
KeyID / Re: TLD suggestions for Agent86's model.
« on: August 07, 2014, 07:27:59 pm »
 +5% I generally agree with arhag's thoughts on this subject.

222
KeyID / Re: Alternative DNS White Paper
« on: August 07, 2014, 07:22:07 pm »
Arhag,
How would this sound to you:  Beginning with the initial auction, everyone is forced to pay up front for a 100 year lease and maintain it.  They are forced to extend this lease every 3 months at the current market rate or else they lose their domain.

In case you missed it, this is equivalent to your core proposal.

Your proposed additional function f(n) = 0.0025 + 0.125/n only complicates things and is not useful.  It exacerbates the squatting problem that is already present.

I think doing 100 year leases incentivizes squatting behavior too much.  I also don't like that there is no flexibility for domain holders in lease length and they have to make payments every 3 months that might rise unexpectedly.  If they ever are priced out of their lease they have only 3 months to plan for it and move (Granted they get a big payment in doing so).  Under my plan they have the entire length of their lease to plan for a move or decide what they want to do.

It's probably an improvement on Empirical's original idea or maybe it's just more specific, and I like that both of you are acknowledging the need for market based carrying cost.  But in the end I think it incentivizes squatting behavior too much and has other problems such as flexibility.  It would also be possible to use my idea with a longer initial lease or tweak it, but I don't currently see a reason to.

223
KeyID / Re: Alternate Allocation Proposal
« on: August 07, 2014, 02:49:38 pm »
Quote
I think there is no need to finalize an allocation at this point.

For what is worth I disagree.. Allocation should have been clear and should have been finalized already way before the snapshot..

If you want investors to buy  PTS they should know exactly how many bips out of the total supply they are getting in advance for the PTS that they hold during the snapshot in order to be able to speculate on market cap and make proper investment decisions.
There has been a pretty clear theory circulated that allocations that don't give at least 10% to PTS and 10% to AGS will be rejected by the market.   The initial proposal by Toast announced around the time of snapshot only gave 10% to PTS and 10% to AGS.  Investors can do as they like.  Making premature and unnecessary commitments to investors so they can make buy and sell decisions serves no purpose and will bite you in the a** when you realize the system would have greater chance for success if a change could be made.  For what it's worth, my position was that the snapshot was also premature.

224
KeyID / Re: Alternate Allocation Proposal
« on: August 07, 2014, 02:17:39 pm »
I think there is no need to finalize an allocation at this point.  I think the main priority should be getting a testnet up that has domain functionality and bidding.  I also think announcing the snapshot date before this was done was very premature.  But the date is announced so it will be used, but I don't think it's necessary to commit to an allocation scheme until it's basically ready to launch.  We should release a chain when there is a use to it or a reason to release; hopefully a functional system that can be marketed.  If we need more resources to get the development and marketing for a good rollout we could still talk to investors which would impact the allocation.  I see no point or value in rushing to release another copy of the bitshares toolkit and calling it the DNS.  It almost feels like the snapshot and allocation and naming conversations are creating an illusion of progress when progress should be taking place on getting a functional testnet.  I haven't even seen documentation for the most recent proposed algorithms.

I would also request there be no commitment yet to release the domain system I proposed on the same chain and with this snapshot date and this allocation.  Maybe that's the best thing to do and maybe it isn't.  Let's do development with the goal of getting up testnets and do first things first.

225
KeyID / Re: Alternative DNS White Paper
« on: August 05, 2014, 08:44:27 pm »
I want to add a tweak; I think using a "standardized rate tier pattern" for all domains could reduce transaction sizes and database bloat.

Pages: 1 ... 8 9 10 11 12 13 14 [15] 16 17 18 19 20 21 22 ... 32