I think 3% delegates are making about $15 per month right now so I wouldn't expect more from them then signing blocks and keeping their version up to date.

Quote from: Agent86 on May 03, 2015, 07:13:04 pm

Yea, forced conversion at 99% seems random to me, may as well just make it convertible at 100% if you are going to do it, although I'm generally not a big fan of bitAssets 2.0 formally (formerly?) 3.0.

Should we let people who are force settling at the feed place a limit on what price feed they would accept at the time of settlement?  i.e.  Some news is announced and someone with bitUSD decides BTS is cheap and they request force settlement but by the time 24hrs is over the price has moved so much they don't want to settle at that price.  Or maybe just preventing someone from being completely screwed by a momentary price feed error like a script goes awry.

The main floor on the value of BitAssets is formed by the value to shorters of freeing their collateral.  Forced settling by either expiration or other systems forms another floor at the value in BTS at which the longs expect to be able to force settlement.  With sufficient liquidity, this secondary floor should be unnecessary, but if it is considered necessary it should be at the targeted peg value, not an offset from that.

If the longs are able to cancel settlement, that defeats the purpose of the 24 hour delay I think.  In that case they might as well constantly request settlement and constantly cancel unless settlement is going to occur on a spike in their favour.  If price feed volatility is an issue, they could trigger 24 hour delayed settlement at the average feed price over those 24 hours.  Again, I think forced settling is less than ideal anyway.  The real floor should be the value that BitAssets have to shorters who need them in order to recover their collateral.

Sure, but Dan is essentially doing away with the main floor on the value of BitAssets by doing away with the rule: no shorting below the feed.  So the only floor left in bitAssets 3.0 is the forced settling.  I also wasn't suggesting allowing longs to cancel settlement; only allow them to specify a floor to the settlement up front at the time they request settlement.  Anyway, I think I'm generally on the same page as you here and I didn't say this is my preferred way of doing things.

Quote from: Agent86 on May 01, 2015, 05:49:36 pm

Quote from: btswildpig on May 01, 2015, 05:05:12 pm

Low liquidity is the issue .
If BTA demands more premium , then it'll lose attractiveness at this early age . If no premium , even with the bug fix , the high demand for BTA brings covering pressure will still makes shorts not wanting to continue anymore . Without liquidity , BTA is useless for the outside world .

Ok, I just think getting rid of bugs in the current system would give shorts more confidence

do you think one of them is the ability to use existing collateral to cover?

I think being able to cover with collateral would help things, I know there are people that forget to separate their balances or keep enough BTS to cover so they just wait it out until their short expires.

I think I'm missing the crux of the problem solved by BitAssets 3.0.  I feel like bitAssets have tracked pretty well considering some nasty bugs that should just now be fixed in the upcoming hard fork, the drop in BTS, shorters not realizing they can't cover with their collateral etc.

Will this peg "hold", yes it will.   Will it always be worth at least $1 yes.   Will the cost to buy it sometimes be far more than $1, YES.   

So we can now say that BitUSD has a FLOOR of $1 and can go up from there.   As a merchant / consumer that is all you care about (the floor).  The presence of a floor means that people can trade USD for BitUSD and purchase things with BitUSD without having to think about whether it is worth $1.    The only people that actually have to think about whether to buy at $1.05 or not are traders... they take the risk that short demand will increase and push the price back down toward $1.00.  On the other hand, in a bear market short demand may decrease and push BitUSD up to $1.10. 

I generally disagree that the price will remain above $1 or generally trade around $1.05 when it's only convertible at 99%.   I think that bitAsset holders will need to use the force settle at 99% a lot to get their value and it won't be just a theoretical backstop.  Therefore I think the price feed will have more power in this system because the price feed specifically determines the price you pay when you convert.

I think the rule no shorting below the feed was a good rule because it protected the market without specifically forcing people to do something, just preventing people from doing something they shouldn't be doing anyway.  I don't know why the desire to get rid of this rule, not sure if it's just for easier implementation.

I also feel like when you add extra parameters it makes the system sound more complicated to me and I feel like people want to know why these are the right numbers:
Settle at 99% of the feed
with 24hrs notice
with a maximum of 5% of supply convertible per day.
Shorts can vote to force settle the market with 30day notice
giving USD holders a 10% premium.

Actually no matter how you shuffle, the average interval block between public hash of secret is 101 blocks , but cannot keep all interval per delegate is 101,
because there are must have some delegates less than 101,some delegates larger than 101
so it is not really "one delegate is honest ,the random is honest" but we can very very close it .  if we make the MIN interval is larger than 90 by good shuffle,I think it is very easy . the random is honest and enough for BTS
but maybe not for game, it is the reason I suggest use two round history

I might be misunderstanding you, but even though some delegates have interval more than 101 and some less than 101, the idea "one delegate is honest, the random is honest" is essentially true for the last random number of the round under the current system, because the interval for the last revealed number in the round is at least 101.

But yeah, it's a simplification and ignores intentionally not producing a block (this doesn't allow you to determine the random number but allows you to impact it).  It also ignores skipping honest delegate's blocks on purpose.... At least these things might raise red flags or be detectable.  Newly elected delegates would have to be handled right also.

I think if we want to use random No. to play game, ,maybe we should update DPOS a little to fit the short time wait game to void the attack that delegate refuse produce block when he know he does`t win in the block his turn .
I mean though we use two round history hash. or very good  shuffle, we also cannot defense this type attack

Yea I think for gambling it's best to look at the specific application and delegate provided random numbers are likely not the best option.  Maybe Dan has other things in mind.

IMO It's better to just have delegates reveal the number they hashed 2 rounds ago instead of prior round.  The shuffling isn't the problem.  You're just trying to have a random number each block to use for gambling.  This way the random number is more robust (1 honest delegate is always enough)… it's also less complicated.  Your way, collusion of a large number of delegates (but not all) could still be a problem and it would be very difficult to detect.  I think for most gambling applications, allowing the players to participate in the secret/reveal random number gen process is probably the way to go anyway.

In the old system (assuming it is correctly implemented) this type of manipulation is not a big concern because changing the feed shouldn't force anyone to transact at that price and and people will place their orders based on the expectation that the feed will correct.

In the new/other system proposed by BM today it's a disaster-  drop the feed price to close to zero and short yourself a few million BitUSD while posting very little collateral.  You don't get margin called because you are protected by the feed - which you control.  So you could sell those "free" bitUSD to any open buy orders.

Quote from: Agent86 on January 08, 2015, 10:19:49 pm

With reversible transactions, if a hacker got your keys they could set up a script so even if you reverse the transaction to yourself they just keep sending it to themselves again and reverse any transactions you send to anyone else... so perhaps the result is pretty similar to just burning it and burning offers no incentive to the reverser to do it maliciously. 

An interesting point. I guess if we are talking about hacks and compromised wallets, it could well be that the attacker gains access to the account issuing reversible transactions... in this case the attacker could hold the coins in limbo by repeatedly sending to themselves, but not sure they can do anything to walk away with them? In the worst case this is equivalent to burning them, since they are forever in limbo... but does the attacker have this level of patience?

In short, yes the attacker has the patience.  The person being attacked is more likely to lose patience and give up then the attacker who is almost certainly technically capable of automating it.