Quote from: abit on December 19, 2015, 11:22:21 am

@fav I wonder why you vote against worker refund400k (1.4.0)?
And @mindphlux ?

refund400k - intentional. there's no official written proposal or explanation on it - the bare minimum in my opinion.

mindphlux - thanks for pointing that out, clearly not intentional

edti: seems like @mindphlux has no active worker

I meant @mindphlux is also voting against that refund400K proposal.

@xeroc would you please draft a document for the refund400k proposal? Or better help committee-account to create a refund proposal to replace the current one? OK let's move this discussion to worker proposal board.

Percentage based transfer fees are completely untenable. Every single other coin in the world has a low, fixed fee for any amount sent, bitshares would lose out to the competition and it would be a PR nightmare. Percentage based trade fees on the other hand, are acceptable.

If the fee is charged by IOU/Smart coin issuers then would be OK (in addition to basic network fee). Best if the issuers are able to define several thresholds and % of the fee. Under this condition the committee can control fee of transferring BTS to be low or higher (as demand). Maybe the ones who benefit by the reference program won't agree though.

No email still..

@fav I wonder why you vote against worker refund400k (1.4.0)?
And @mindphlux ?

1. when you borrow bitUSD it's no price involved anyway, although you need to put some BTS as collateral. How much BTS you put as collateral is actually as you like, however you may want to put a bit more to avoid being margin called or being forced settled, however others don't care if you're margin called..
2. after you borrowed some bitUSDs, they are "your money" in you wallet, again, you can spend them as you like, e.g. to pay your mobile phone bill. However you need to know that your collateral may become insufficient if BTS's price drops a lot, as a result you may be margin called if you don't add enough collateral or adjust your position in any method in time.
3. if you sell bitUSD for BTS (buy BTS with bitUSD), you bear more risks of BTS price drop.

Honestly I would recommend pause the bitUSD business plan before you understand the bitUSD product itself. It may cause huge risk to you in the future, as which to bitcrab already.

Quote from: xeroc on December 18, 2015, 05:58:04 pm

Quote from: roadscape on December 18, 2015, 04:57:42 pm

Why do we need stealth when you can just create and claim into an anonymous account?
Stealth funds need to go back into a visible account to be tradeable anyway.
And the people who really want to spy you have *plenty* of other ways to find out what you're doing.

But hing the amount and not showing involved parties at all is considered WAY
better privacy.

Quote

This has a higher priority than say, MAKER, only because the cash is on the
table, right? If we put up more bids/depth on the MAKER market than the STEALTH
market, would that be enough for CNX to reconsider priorities? If MAKER had just
13M BTS in bids, that's $45k right there.

Great observation.
What the MAKER speculators may not know is that the STEALTH proposal is VERY
VERY important for the Fee Backed Asset idea. even though they are independent
proposals (BSIP7 and BSIP8), creating and issuing a FBA under a STEALTH/PRIVATE
account is very important for regulatory reasons!!!
Otherwise people that want to innovate and have t funded via FBA might run into
legal trouble quickly. Read BSIP7 for more details about it.

Quote

Finally, on an ideological note: we've never seen a true global free market, and
we have no idea where it will lead society. It could be really good, it could be
really bad. I posit that stealth is only desirable because of
short-term/reactionary fear. And when people act out of fear they make
bad (I mean truly horrible) decisions.

The Stealth proposal is not only about hiding funds or transfers or privacy. It
is also about making sure not to run into regulatory issues and let more
innovations enter the system more easily.

Aah... good point., I forgot that this was sort of a prerequisite for some FBA's. BSIP7 is helpful, thanks. I now understand that even if MAKER doesn't depend on STEALTH, there might be other important/interesting FBA's which could only be released in a 'counterparty-free setting'.

So why not just make a work proposal for FBA only, but made a proposal with 45K$ Graphene-STEALTH-GUI in high priority in a same "package" and which changes the under protocol of STEALTH feature?
1. Anyway, people are already able to do stealth transfer via CLI wallet NOW, although the feature is not currently perfect. Who has big money and wants to keep privacy may be willing to learn how to use CLI, or has a technician help her.
2. If current proposal get approved, users of other GUI products (e.g. moonstone) would have to pay to OnceUpon for using STEALTH feature, but it's likely that OnceUpon won't fund all GUI products for the same feature.

As bm mentioned, current implement of STEALTH transfer is lack of unlinkability as well as untraceability. So it's just like TITAN in bts 0.x (although in 2.0 it does more than TITAN by hiding the amount of transfer), which just let people feel like that their have privacy, but their don't really have. It's dangerous to encourage people to use such non-perfect feature. Personally I don't like to use it nor recommend to other people.

Quote from: monsterer on November 19, 2015, 09:41:14 am

Quote

Privacy/anonymity consists of:
A. unlinkability (can't tell two transactions are to the same recipient): stealth (or just not reusing addresses)
B. untraceability (can't trace paths between tranasctions): ring signatures (or coinjoin, coinswap, though with many complications and hazards, etc.)
C. content privacy (can't see amount being spent): CT (or limited ambiguity of which outputs are change)

Bitshares with CT gives you A and C, but nothing at all for B. Monero gives you A and B, and somewhat C (via ambiguity of change outputs). Monero with ringCT will give A,B, and C, for a comprehensive solution.

Under BitShares 2:
You cannot tell two transfers were to the same recipient.... until they spend them together. 

With current API we can't control how to NOT spend them together.

When they are spent together you don't know which output was to someone else and which was change.... unless one of the outputs is combined with another output for which you know the owner.
Through tracing of blinded balances back to their public source you can calculate an upper bound on the value of a blinded balance, for example we know the total value of all blinded balances is the clear upper bound on any individual blinded balance.

There are only two kinds of attackers on your privacy:

1. 3rd parties whom you have never done business
2. Those with whom you have done business.

Under BitShares 2 you are completely protected from 3rd parties, but have slightly less protection from those you do business with. If I send you a lot of payments I may be able to identify a large subset of the blinded outputs that belong to you, but I would be unable to learn your balance. If you then transfer the blind output I gave you to a 3rd party then I know the upper bound on all outputs derived from the one I sent you.   

The conclusion is that the BitShares wallet should always combine all of an individual's inputs in every transaction. This will provide a similar protection to ring signatures (preventing those who sent you funds from being able to know the upper bound on downstream transactions). 

At the end of the day the only information leaked is that "you received payments from multiple people".   With every subsequent payment the probability that an individual output belongs to the same person falls by 50%.

Privacy is therefore most compromised around the edges of the blinded/stealth transfers when users convert to/from public/private it leaks some information.

Adopting ring signatures would therefore increase your privacy by increasing the "upper bound" value for an output by merging in outputs that don't belong to you and by not grouping multiple transactions as being to/from a single party.

So for almost every conceivable use case what BitShares provides is more than sufficient even if ring signatures are technically better privacy. 

What I would like to know is what kind of size and computational penalty one takes for adopting the more comprehensive solution.

Of the things proposed by anonymint the ones I actually think are worth something are:

1. smaller proofs
2. ring signatures that allow you to combine any random set of outputs.

CN (one-time rings) mixes payer's identities which adds the untraceability.