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 - arhag

Pages: 1 2 3 [4] 5 6 7 8 9 10 11 ... 81

Some additional (long) thoughts on the project:

The SBD (which seems to be a USD pegged asset with a possible interest rate bonus on top) is interesting...

Now the question is will bytemaster's strategy work, or will it cause the Bitcoin community to treat this DAC like a pariah and stubbornly refuse to use it while yelling out words like "instamine." I can't wait to find out.

Is this already mostly coded?

Everything I described in my post about STEEM was from my review of the existing code in GitHub. So, yes.

If so can it be forked onto BTS or a separate DAC with an allocation strategy that greatly favours BTS holders?

The BTS SuperDAC was created with the intention of forking competitors where possible/valuable and this seems like such a scenario given it's based on BTS compatible code?

I was going to say yes, but apparently as bytemaster mentioned previously in the thread, STEEM is released under a non-free license. Regardless of licensing issues, let me procede with why it may not make sense to bring SBD with interest into BitShares, which I believe is what you are mostly concerned about.

The problem with the SBD asset is that it forces all STEEM holders to back it, which means a risk of significant STEEM inflation to cover the price stability of SBD. We would not want to force all BTS holders to back an SBD equivalent on BitShares. Furthermore, users cannot create as much SBD as they wish on STEEM (which I think is good because that limits the liability of STEEM holders). That works fine for its intended purpose as rewards for content creator and curators, but I would say for something like BitUSD, our existing mechanism of borrowing with collateral makes more sense.

Regarding interest on market-pegged assets generally, let me just add a few comments on my personal/philosophical views about it. If I remember correctly I believe you are a proponent of paying yield on BitUSD. I don't agree with that unless it was done in a very different way than what was done previously due to yield harvesting. First, I disagree with the idea of BTS workers paying for the yield. This means I also disagree with the SBD interest mechanism being used in BitShares since ultimately it means the core asset holders (STEEM in the case of the Steem DAC, BTS in the case of BitShares) are paying for it through dilution. I think any smartcoin yield we may choose to have should come from the smartcoin borrowers. Second, due to yield harvesting, it only makes sense to pay yield to smartcoin holders if the instantaneous dynamic interest rate is always less than the current smallest interest rate paid by smartcoin borrowers. The way yield payouts would need to be calculated would also need to be more sophisticated than what was done previously with BitAsset yields. I could go into more depth on the technical details of how such a smartcoin yield system could work, but I think I won't bother doing that here and now. The short version of it is that the smartcoin manager would provide a dynamic feed of smartcoin holder interest rate, smartcoin borrower interest rate, and a smartcoin borrower max interest rate; and borrowers would have to pay a dynamic interest rate (with a ceiling set to the maximum interest rate from the feed at the time of borrowing which they implicitly agreed to by going through with the borrowing) and smartcoin holders would get paid a dynamic interest rate set to the smaller of the feed's smartcoin holder interest rate and the lowest interest rate paid by the smartcoin borrowers at the time.

General Discussion / Re: STEALTH Status Update
« on: April 05, 2016, 06:09:31 pm »
I don't like private profits being made from something that should be a core feature of bitshares.

I understand and appreciate that [member=49]onceuponatime[/member] has taken on risk and reduced sell pressure on BTS get Stealth asset implemented but I think this feature would be better as just a standard feature .

I'd like to see [member=49]onceuponatime[/member]  to sell this feature to bitshares and delete the Stealth asset.

He could sell it for whatever he paid +25% to cover costs and make a profit. This could be done as a worker proposal.

I've never thought Fee Backed Assets for core bitshares functions made any sense whatsoever.

Well, the community had a chance to fund it and would up relying on private investment.  To lobby after the fact to change the rules is very damaging to the possibility of further such investment.  It's really the same bad rep we get when someone starts a worker project and then gets voted out before they can finish it.  I, for one, will have no part in trying to pressure Onceup to give up what he took the ultimate personal risk to make possible.

I think we need to figure out some community rules for how FBA features could potentially be given back to BTS holders in the future for any new FBA we wish to approve.
For example, perhaps if more than 90% of a FBA holders vote to hand back control of their feature to BTS, that gives the community permission to:
1) choose some "fair" price of the FBA based on the recent market price history of the FBA trading on the DEX; and,
2) with the permission of the majority of BTS holders, hard fork the DAC to pay all FBA holders (other than the committee account) at the previously mentioned price (using sufficient funds accumulated in the committee account), destroy the FBA, and allow control of the FBA's feature to be given fully to the DAC.

If all FBA investors know these rules ahead of time, it becomes appropriate for BTS holders to optionally support the following procedure to gain control over the FBA feature:
1) BTS holders vote for workers that pay the committee account for the sole purpose of using those funds to buy the FBA over time at "reasonable" prices.
The worker would have to include some kind of information of what maximum price the committee would be authorized to pay for the FBA, although the committee would try to be smart about the orders they place to try to get good deals even if that delays acquiring the FBA. BTS holders could always stop voting for existing workers and vote new workers to change the price limits on the orders they are willing to authorize the committee to make.
2) As the committee accumulates the FBA they buy, they would also be accumulating the fees from the usage of the FBA's feature. It would be the committee's responsibility to either use these fees to buy more of the FBA or instead send those fees to the BTS reserve pool depending on what the currently active worker authorized them to do.
3) If the committee ends up accumulate more than 90% of the FBA supply, they would lock in the "fair" settling price at that time. They would then move onto the second stage which is to continue raising enough funds from workers to pay off the remaining less than 10% of holders at the "fair" price. The worker voted by BTS holders to pay them would also act as support from BTS stakeholders to do the hard fork later when possible.
4) Finally, when enough funds have been accumulated for this purpose in the committee account, everyone would update to a new client which would trigger the hard forking mechanism described above to pay the remaining less than 10% the "fair" price using the funds in the committee account, and then destroy the FBA so that the feature ends up fully in the control of BTS holders.

If everyone investing in new FBA assets understands these rules (that more than 90%, or whatever threshold we think is appropriate, of FBA holders can, with the agreement of the majority of BTS holders, force them out of their position at a price that is not determined by them but is nevertheless hopefully not too unreasonable) then BTS holders get a fair mechanism to potentially take control over features that they weren't able/willing to fund back when the feature was considered necessary to have. In fact, if we could get [member=49]onceuponatime[/member] to agree to a rule like this prior to selling any STEALTH, then we have a mechanism to potentially allow BTS holders to get back control over stealth features.

I think this is very important because I agree with [member=37127]JonnyBitcoin[/member] that stealth is a core feature of BitShares and I very much dislike the idea of BTS holders not having sovereignty over their core features. I preferred funding stealth GUI features with workers rather than the FBA for this reason. Now if we ever want to change the way stealth operations work or interact with the rest of system (the rate-limited free transaction feature or funding the referral program are perfect examples) it is no longer just the decision of BTS holders. It now requires complicated (and less likely to succeed) negotiations between BTS holders and STEALTH holders. This rigidity can prevent us from making the smart decisions to most effectively grow BitShares.

At the same time, not having a way to practically use stealth features could likely have also hindered BitShares adoption. And the fact is that due to the anti-dilution camp, if it wasn't for [member=49]onceuponatime[/member] we likely wouldn't have a practical way to use stealth for the foreseeable future. So I am thankful for that. I just want to make sure we have some mechanism that is fair to all parties involved which allows us to go back to the better way of managing these features (controlled solely by the BTS holders) in the future when hopefully BTS holders are more willing to dilute.


The true purpose and scope of Steem will be revealed in a couple of weeks, but for now it is open for everyone to look at the code.

Perhaps something like a decentralized alternative to threaded discussion forums, e.g. Reddit self posts (though limited to STEEMIT_MAX_COMMENT_DEPTH == 6 nested comments, which I guess is a reasonable number),
except with the distinguishing feature of economic rewards for good comments ("What do you mean internet karma points don't have to be worthless?" ;)).
Though perhaps that could backfire as well: redditors take karma too seriously as it is even though it currently provide no economic value whatsoever. But it would be fun to see how economic incentives modify social behavior online.

I look forward to hearing more about this project in the future.

Some additional (long) thoughts on the project:

The SBD (which seems to be a USD pegged asset with a possible interest rate bonus on top) is interesting. There is a DEX on the network with just a single market STEEM/SBD (plus there are subsidies to liquidity providers which is great addition), but yet it seems pretty clear that SBD is not BitUSD/Smartcoins. Specifically, there is no SBD borrow with collateral mechanism available. It is possible to convert SBD to STEEM but the blockchain just destroys the SBD and prints enough new STEEM to satisfy the conversion at an exchange rate (after a 7 day delay) at the given median price feed provided by the witnesses. Thus, I think it is safe to say that all STEEM holders are effectively forced to take the "short position" against the SBD. By holding STEEM they are betting that its price should outperform the USD plus blockchain-declared interest rate. And this is despite all the other inflation of the STEEM supply to pay for block producers (witnesses and occasional PoW miners), the liquidity provider subsidy, the content/curation rewards, and especially to try to keep the vested STEEM balances deflationary. The one upside is that SBD longs cannot just demand to be issued as much SBD as they want, so the STEEM holders' exposure to losing on the STEEM/SBD price change gamble is somewhat limited. It seems SBD are only issued into existence as a reward for comments (and even then only half of the comment reward is in SBD while the other half is provided through VESTS). And the total amount of annual inflated STEEM funds dedicated to comment rewards is limited to 5% of the total STEEM supply (another 5% of the supply goes toward curator, i.e. comment voter, rewards in the form of VESTS).

It seems to me that STEEM holders will be getting diluted like crazy to pay for all of this. But I guess that is what VESTS are for. You give up your ability to quickly dump/transfer STEEM on demand by vesting your STEEM in order to avoid the extreme dilution of your stake while you hold. And in fact your percentage ownership of the total stake should actually increase as long as less than 90% of the total STEEM is being vested in the network (though apparently more than 80% of the current STEEM supply is already vested, so who knows how likely it actually will be that the network will normally be vesting less than 90% of the total STEEM supply).

It seems like an interesting economic experiment.

I think it is particularly interesting that the nature of VESTS (2 years until you can fully withdraw all of your funds) means that it would be foolish for exchanges to try to vest any STEEM deposited by their customers. This means two things:
1) the exchanges would not have the power to vote for witnesses (sinces only VESTS assets have voting power) which is good for network security; and,
2) it is foolish for the buy-and-hold investors to keep all their stake on exchanges in an attempt to avoid the inconveniences of using the client software because that would force them to keep all of their stake in the highly inflationary STEEM asset rather than the more profitable VESTS asset (thus they have an economic incentive to download and use the client, which is a great thing).

It isn't completely clear to me where the revenue for this DAC would come from. All that inflation needs to be paid for somehow in the long term. The obvious answer is that the revenue could come from transaction fees on posting comments. And that could certainly be a viable business model for the DAC if people are willing to pay per post. But nickel-and-diming people per post is a pretty annoying user experience, so it isn't clear if that business plan could actually work in reality. There is potentially an alternative strategy, which may already be what this DAC is aiming for (I don't know for sure, I wasn't able to tell from my brief review of the code). People might be willing to buy STEEM and turn it into VESTS even if it isn't as profitable of an investment as other altcoins, simply to gain access to the services provided by the DAC. The rate-limited free transaction mechanism being added to BitShares could also let this DAC allows users to submit comments and posts for free, but at a limited rate which is proportional to the amount of VESTS they hold in their account. Effectively, users would be paying for the comments/votes through the lower returns on their "investments" compared to the returns they would have gotten had the comment/vote transaction had a transaction fee. This solves the nickel-and-diming user experience problem, but it is still not clear whether users would find the higher costs (even if hidden and implicit) to be justified for the unique features of decentralization and also profiting from karma, or if they would rather prefer sticking with the existing centralized systems that are cheaper/free (or more precisely: paid for by advertising).

Finally, I find the low-profile/vague announcement strategy used by thereverseflash to be both amusing and perfectly rational.
Creating a new mining algorithm only to highly deemphasize it in favor of DPoS only 1 month after launch,
underselling the potential and ambition of this DAC (it is presented as yet-another-simple-alt-coin and not as an attempt to create a decentralized Reddit),
leaving in technical barriers to joining in on the initial mining; it all makes sense when you read this blog post by bytemaster and accept it as the guidebook for launching this DAC.
Now the question is will bytemaster's strategy work, or will it cause the Bitcoin community to treat this DAC like a pariah and stubbornly refuse to use it while yelling out words like "instamine." I can't wait to find out.

Random Discussion / Re: Where is Arhag?
« on: December 01, 2015, 10:13:52 pm »
yep i'm missing him as well :( [member=18133]arhag[/member]
Status "Online". But keep silent. Why? [member=18133]arhag[/member]

Still here. I've just been really busy lately and barely have the time to keep up with the forum threads anymore.

General Discussion / Re: Randomness of Witness Scheduling
« on: August 28, 2015, 05:51:23 am »
Couldn't the witness just change other data in their block until they get an s value that they like?

Yes, you are correct. I don't know what I was thinking.

So we would still need a 20-byte commit in the previous round, however, not of some other 20-byte random data but rather of the r value instead. The r value would still be revealed along with the s value in the signature, but it would do double duty as the entropy source. This would save only 20 bytes per block rather than 40 bytes (so 0.6GB per year rather than 1.2GB per year).

Also, to clarify an unrelated point, anytime a witness was producing a block in a round in which they did not produce a block in the previous round, the blockchain would allow them the option to use an r value that is not consistent with the last commit of an r value that is associated with their witness, in order to avoid producing a signature that could reveal the signing key.

So, I guess it may not be worth it to try to preserve the provably fair RNG functionality of witnesses and leave that role to something else in the blockchain.

However, I did like the idea of witnesses being an entropy source for the blockchain, and I do have another idea for how we could get that "for free" with another functionality that I find very useful. If you take a partial Schnorr signature of the previous block digest by some subset of the active witnesses and combine them together, you get a Schnorr signature of the previous block digest signed by a key that is the sum of public keys associated with the block signing keys of the witnesses in that subset. The point of the nonce value of the combined signature is also random if any of the witnesses in the subset used a random nonce in their partial signature. So the block producer could collect these partial signatures from all the witnesses (they can be of the previous block or perhaps the block before the previous block to help with latency issues), combine them together, and include it in the block header. The blockchain would only accept that signature in the block header (by the way, this is in addition to the block signer's regular signature of the block they are producing) if all of the active witnesses contributed to the signature. This signature would act as a much faster checkpoint signature than waiting for 0.51*(number of active witnesses)*(block interval) seconds for the same confirmation security, at the cost of an extra signature per block. Of course, if a block producer is not able to get all the partial signatures in time they would exclude the combined signature from the block header which they are allowed to do. In that case clients simply have to fallback to waiting longer until they get the confirmation.

By using the latest point of the nonce in the combined signature as part of the random number generator, we get a RNG that has the same properties as the current RNG (in that as long as a single witness is honest, the generated number is random). However, a new random number is generated (and thus new entropy is available to the blockchain) much faster in practice (the random number generated each block is provably fair, rather than having to wait a full round to guarantee that you get new entropy that is provably fair in our current system), but in theory it may take an indefinite amount of time to actually generate a provably fair random number since each block producer could exclude the combined signature from block header (for example because there is a single active witness who is not complying with the process). Of course this functionality comes at a cost. Instead of reducing the blockchain bloat by 1.2GB per year by getting rid of the RNG, it would add 0.8GB per year for these combined signatures (we could instead get similar functionality while reducing blockchain bloat by 0.2GB per year instead of 1.2GB per year if we only allow combined signatures on every other block at the cost of slightly longer waiting to get the faster confirmation). So, it all comes down to how much the faster confirmation feature is worth it to people.

General Discussion / Re: Randomness of Witness Scheduling
« on: August 27, 2015, 08:46:16 pm »
1. removing random number generation from witnesses which will reduce block header size by 46% and saving an "empty" blockchain 1.2GB per year.

I like the random numbers built into the blocks and would love to find a way to keep them, which I think requires no witness gets to sign two blocks in a row.  I just think having a provably fair RNG built into the blockchain is a good thing.  I would consider it worth a couple of hours of compute time on a witness node per year.

We already have an entropy source from the witness signature. Why not simply require the nonce of signature to be committed in the prior round similar to how the random number is currently committed in the current scheme.

The witness signs the block and also submits the x-coordinate of the elliptic point of a new nonce (the r value) that will be used in the signature for their block in the next round. The signature of the block by the witness in the next round would only have the s value of the signature, not the r value which was already submitted in the previous round. That way no additional blockchain bloat is needed in each block header but the blockchain still has the same provably fair RNG we currently enjoy.

The additional challenge is getting into the code base and then deployed out into the network, which is similar to getting approval in the Apple app store...

I don't like the comparison much because it isn't similar to getting an app approved by Apple into the app store. We need to hard fork to incorporate the new features and that means all the nodes need to upgrade their code. Hard forks aren't supposed to be something we do very frequently because of the inconvenience it places on all full node operators. So I think a more fair comparison is that it is like convincing Apple to include your app as part of their next iOS release.

...with the end result of a highly optimized compiled version of a specific smart contract.  I really like this comparison and it makes it easier for people to conceptualize the different approaches.

In theory we could have fast native code running as sandboxed (using standard Linux process isolation techniques) modules that interact with the blockchain through well-defined APIs and are dynamically upgraded via the blockchain protocol.

I want to make sure we don't confuse two separate issues. Whether the smart contracts run natively, are interpreted, Just-in-Time compiled, Ahead-of-Time compiled at installation/upgrade time, etc. is all a separate issue from whether we allow the smart contract code to be dynamically upgraded (and added and removed) during blockchain operation as part of the protocol or if we require a hard fork for each change.

The latter question is the more important one for us to answer since it requires making trade-offs. I don't think we want anyone's code to just be able to run in the inner (single-threaded) processing loop that native operations run under. This would break our guarantees of 1 second block intervals and mess up the protocol. Whatever code that is dynamically upgradeable by any user and runs on the blockchain needs to be able to run asynchronously without holding back the processing of transactions holding core operations (it could hold back other transactions in the same class as it though). To allow concurrent processing threads to run, the blockchain would need to have some notion of compartmentalizing database state for different smart contract operations at the protocol level so that we avoid all the overhead that comes from trying to figure out whether we can run potentially serial operations in parallel (this overhead would instead effectively move to the clients by most likely requiring them to make multiple transactions to explicitly move information from one compartment to another).

If we can get confirmation from bm or someone else of how it actually works I can change the logic behind it.

Should be simple enough to test. Someone sell a small amount of BitUSD at a price of 230 BTS/BitUSD and see if it gets filled and causes the amount of the cover order at the 230.4598 BTS/BitUSD price to decrease by the corresponding amount. Obviously adjust the numbers to reflect whatever they happen to be at the present time (I haven't checked if they changed).

Okay, this is my second attempt at coming up with a blinded signature algorithm that (attempts to) solve what I consider two problems with Oleg Andreev's algorithm. The first is the fact that the nonce is determined at the time the public key is determined (which I discussed in my previous post). The second is the unsolicited fund problem (which means that the balance remains unprotected by two-factor authentication from the time the sender sends it until the time the receiver moves it into a new balance that is protected by the public key derived from the blinded signature algorithm).

I believe I have come up with a solution (although for all I know it might be flawed like my first attempt which allowed colluding attackers to gain access to the user's private key) that solves both of those problems while generating a standard Schnorr signature. I had to give up on ECDSA since I'm not sure if it is even possible to do a blinded signature algorithm that satisfies these two requirements. Schnorr signatures have a lot of advantages over ECDSA anyway, like making threshold signatures really easy.

Again I assume there are three parties: Alice, Bob and Carol. Carol is sending unsolicited funds to Alice and Bob is Alice's designated blind signer. This time Bob does not need to have a public key specific to each of his customers. (Not true. See edit.) I believe the protocol I lay out below allows Bob to protect his private key even though it is being used to service all customers (meaning his customers cannot trick him to generate and return values that allow them to recover his private key... I hope). Bob's blind-signing private key is b and his published blind-signing public key is B = b*G. Alice's blind-receiving private key is a and her published blind-receiving public key is A. (Note I use blind-signing and blind-receiving rather than just active as an added security precaution. If I am wrong and there is a way to determine Alice's or Bob's private key, at least the damage is contained only to balances designated for blind signing rather than everything. This of course assumes that the blind-signing/blind-receiving private keys are determined through hardened child derivation from the corresponding active private keys, rather than normal child derivation.)

When Carol wants to send funds to Alice all she needs is the share secret z derived from Diffie-Hellman key exchange, Alice's blind-receiving public key A (which is published in her account metadata), and the blind-signing public key B of Alice's blind signer (Carol looks up in Alice's account metadata that Alice's blind signer is Bob, and then looks up in Bob's account metadata that his blind-signing public key is B). Carol then computes f = HMAC256(z, SHA256("blind")), and then the public key T = A + B + f*G. She sends the funds to a balance that can be withdrawn using a Schnorr signature corresponding to public key T (the full public key T is included rather than the address since Schnorr signatures do not allow recovering the public key from the signature) and also includes in the transaction the one-time public key that Alice needs to derive the shared secret z. When Alice receives the transaction, she can compute the shared secret z, then f, and then T, and verify that the transaction is valid before accepting it as payment for goods and services.

Later, when Alice wants to actually withdraw the funds, she creates a withdraw transaction which has digest h. She then connects to Bob with a secure connection, authenticates herself to Bob, and then they go through the following procedure (all operations are modulo the group order):
  • Bob generates a random value r. Then, he computes P = (b + r)-1*G. Then, he sends (r, P) to Alice.
  • Alice computes u = HMAC256(a, SHA256(h || r || P || "one")), v = HMAC256(a, SHA256(h || r || P || "two")), Q = P + u*G - v*(B + r*G), e = SHA256(h || Q), and w = -(e + v). Then, she sends w to Bob.
  • Bob computes y = (b + r)*w + (b+r)-1. Then, he sends y to Alice.
  • Alice computes s = y + u - e*(a + f - r), and she verifies that SHA256(h || (s*G + e*T)) == e.
Then (s, e) is the Schnorr signature on digest h with public key T. The blockchain can verify the signature is valid by verifying that SHA256(h || (s*G + e*T)) == e.

Bob only has access to r, P, w, and y. Since v is a pseudo-random number that Bob does not know, he cannot relate w to e. If Bob suspects a particular spent balance belongs to Alice, he can compute F1 = s*G + e*T - P - (w+e)*(B + r*G) which should be u*G if it is in fact Alice's balance. He can also compute F2 = s*G - y*G + e*A - e*r*G which should be u*G - e*f*G. Therefore, even though Bob cannot know the pseudo-random number u, if e-1*(F1 - F2) ==  f*G, then Bob can know the balance does in fact belong to Alice. However, Bob also does not know f because he does not know the shared secret z. While Carol does know the shared secret z, if Bob and Carol were colluding, she could just trivially tell Bob that the balance does in fact belong to Alice. I don't believe there is any way for Bob alone to link the balance to Alice by following this protocol.

The remaining questions are: if Bob and Carol colluding together can generate a valid Schnorr signature on an arbitrary digest or even discover Alice's private key a; and, if Alice can trick Bob into revealing his private key b. While I don't have any proof that these two things are impossible, I haven't yet been able to figure out a way that it could be done. Of course, a review of the protocol is highly appreciated.

Edit: Once again a flaw. Though I still think users cannot trick Bob into revealing his key with the above protocol, it is still broken because users sharing the same blind signer essentially are not protected by two-factor authentication with respect to each other. Eve can legitimately authenticate with Bob and get him to blind sign a digest that allows her to steal Alice's balances if she also knows Alice's private keys. The whole point of this is to provide two-factor authentication so the above protocol is broken if they use a universal public key B (and Bob uses the corresponding universal private key b). Instead B should be specific to each customer where its private key b is for example determined using hardened child private key derivation with SHA256(A) as the index. Alice could have Bob generate that public key for her once and then she would post it on her public metadata. Unsolicited transactions would still work fine. I will have to update the details of this protocol more formally to reflect these changes, but I have other changes planned with this protocol such as:
  • Incorporating multiple blind signers (basically an n-of-n multisig) but with still only one final signature.

  • Blind threshold signatures (of the t-of-n variety where t and n are both integers) with of course again one final signature. (A combination of item 1 and item 2 should also be possible where there are m different ti-of-ni threshold public keys for i = 1, ..., m, and the requirement is that all m of those produced a valid partial threshold signature.)

  • Blind weighted signatures in which the sum of the prescribed weights of each key (these can also be t-of-n style threshold public keys à la item 2) in the set of signers needs exceed the prescribed threshold in order to be valid, but done in a way that doesn't reveal to the public or to the blind signers who the keys actually belong to and without revealing the weights nor threshold values, thus better protecting privacy (however it does necessarily reveal some structural information like the total number of keys in the set of possible signers and the indices of the signers in the set of possible signers that make up the subset of actual signers). This is done through the use of Pedersen commitments and range proofs from the blinded amount cryptography. Transaction size requirements are not trivial but are typically smaller than existing alternatives trying to do the same thing without blinding: one final signature on the overall transaction is necessary and only one range proof is necessary and can usually be very small since it only needs to hide the delta amount of (sum of weights of signers - threshold value) and even then may not be all that important to privacy, and roughly somewhere between (66+34*t) to (66+54*t) additional bytes are needed where t is the number of actual signers (which is quite good when you consider that a regular t-of-n multisig would have 20*n bytes for the n addresses and then t*64 bytes for the t signatures). The compactness comes from the fact that only one final signature is necessary and from the fact that the sender commits to the transaction withdraw condition the list of (public key, weight) commitments as a Merkle tree.

  • Allowing the blind signers to force certain assertions (like setting a maximum allowed dollar value of funds transferred in the transaction and/or that the difference between the expiration time and the timestamp of the TaPoS referenced block be less than some prescribed value) to exist in the transaction they are blind signing while still not knowing the exact transaction they are signing. This is incredibly useful to people using blind signatures whose clients might be compromised. The user can verify out-of-band (say through an SMS, or via the class of one-time code they used to authenticate with the blind signer) the assertions that the blind signer is applying to their signature. So, if using SMS, they will know something is wrong if the assertion class displayed in the SMS doesn't match what their client UI said it was telling the blind signer to apply and thus the user won't type in the one-time code. If they are using a one-time code generated on a separate device and sending it with their request to the blind signer, they can know that worst case the attacker can only do the damage allowed by that assertion class and not any more. This way a hacker can't just wait until the user enters the one-time code for a transaction that is meant to be of the <$50 class and use it to steal their entire balance which is worth much much more than $50. Keep in mind that although this is still blind signing, adding unique assertions on transactions can compromise privacy with respect to the blind signer. For this reason, it is best if people followed a policy that kept the number of unique assertion class variations to just a handful of popular ones and if the client waited before broadcasting the final signed transaction until a random number (selected uniformly from some client-prescribed interval) of transactions with the same assertion class were confirmed in the blockchain starting from the time when the last blind signer sent their partial signature to the user (these are statistics the wallet host can provide to the wallet client).
So I will eventually post an upgraded version of the protocol some time later with all of those changes included.

There is a potential flaw with this algorithm. At the moment that the user stores their balance on the blockchain with a particular blind public key T, they are also forced to commit to a particular nonce k = (c*p*a)-1. The final signature s(h) on any given hash h is s(h) = (c*p*a)*h + (c*p*b + c*q + d) = y1*h + y2, where y1 and y2 are values that neither the user nor the blind signer alone know but are nevertheless fixed given a fixed blind public key T. If the user wants to spend the balance, they craft a transaction with digest h1, go through the blind signature process and generate the signature s1 = s(h1) which they include with the signed transaction they broadcast to the network. So far no problem.

But what happens if for whatever reason that signed transaction is not included in the blockchain before the transaction expires? The user is then forced to craft a new transaction with a new expiration time, and thus necessarily a new digest h2, go through the blind signature process again and generate the signature s2 = s(h2) which they include with the new signed transaction they broadcast to the network. This is where we have a problem. Anyone with access to those two signed transactions can then calculate k through k = (s1 - s2)-1 * (h1 - h2), and with k known they can then calculate r = x-coordinate of the point (k*G), and x = r-1*(s1*k - h1)). The value x is the private key of the public key T (i.e. T = x*G). With x known, an attacker can then craft another transaction spending that balance to their own account and try to get that transaction into the blockchain before the user's second transaction. This is quite easy to do if many of the witnesses are colluding in the attack OR if the attacker controls all the nodes that the user's client happens to be connected to.

One quick fix to this problem is to not require withdraw operations signed by blinded signatures to be indistinguishable from regular signatures. We could decouple the blinded signature from the signature that signs the transaction (this is something that might be a problem for this algorithm on the Bitcoin network, but fortunately we have the flexibility to modify our blockchain protocol). The withdraw condition of the balance would no longer be that it requires the transaction to be signed by public key T. Instead it would require that the transaction include a special operation whose validity is determined by public key T and that the transaction be signed by public key Y, where Y = z*G and z is a hardened child private key determined using index Hash(T) (it is important for it to be hardened so that the public cannot check if this balance is associated with the user's account). This special operation would include a signature embedded inside of it and for the operation to be valid it would require the signature be a valid signature on the digest Hash(Y) using public key T.

So the way this would work is that when the user is storing the balance on the blockchain, their client first goes through the regular procedure to calculate T and then it would use Hash(T) to calculate z and thus Y. It would then create, sign, and broadcast the transaction that initially stores the balance on the blockchain using the values of the address of T and the address of Y in the transaction.

Later when the user wants to spend that balance, the user's client would again generate Y = z*G , go through the blind signature process using the digest Hash(Y), and keep the resulting unblinded signature s in memory (if necessary, say the client crashes and s is lost, the user can repeat the process, meaning re-authenticate with the blind signer, and recalculate s). The user can then generate as many transactions as they want (with unique nonces each time of course) by including the special operation (which contains s) in the transaction and signing it with private key z. Once the transaction is confirmed in the blockchain, the user's client can then delete s from memory.

It is important to understand that from the time that the user receives s and keeps it in memory until the time that the balance has been fully spent on the blockchain, the user is no longer protected with two-factor authentication. If their client gets compromised in that time in such a way that an attacker can get access to the client's memory, the attacker will be able to spend that balance without needing to authenticate to the blind signer at all. Fortunately, it is more difficult to compromise the memory of the client rather than just the user's private key and the window of attack opportunity should normally be very short. Alternatively, the attacker can also compromise the user within the attack window if they know the user's private key AND are able to get access to plain-text communication between user and blind signer such that they can grab (p*a*Hash(Y) + p*b + q) while it is in transit over the network from blinded signer to user (I am of course assuming the attacker with the user's private key is not in collusion with the blind signer, since in that case it is trivial to compromise the balance). For this reason, it is important that the session between the user's client and the blind signer be encrypted (i.e. use TLS), so that the attacker really does need to compromise the client's memory to succeed in the attack.

Adding stealth transfers on top of blinded amounts allows both the amount and the recipient to be hidden from the public (for asset transfers only)

So, you're saying that we will be at least as dark as DASH, Bytecoin/Monero, and Shadowcash?

Bytecoin/Monero and Shadowcash all use the CryptoNote mechanism I described above. So they protect sender/receiver metadata better than BitShares will but come with disadvantages I listed in my previous post.

DASH is frankly not very interesting. Their main feature are stealth transfers that BitShares already has (TITAN) and will reimplement in BitShares 2.0 but in a better way (stealth transfer with blinded amounts via Confidential Transactions). They also conveniently integrate a CoinJoin protocol into the network with their Masternodes (I briefly discussed Masternodes in a different context in this thread). I'm not sure if it makes sense to integrate the CoinJoin protocol so closely with the blockchain protocol or just have that be a separate service provided by wallet hosts, but if it does make sense and there aren't better ways of doing it, it is something that can easily also be implemented in BitShares. Plus thanks to blinded amounts, the CoinJoin protocol would be even more private.

Is there a difference between privacy use here vs zerocoin?  Is this implementation better for exchange and market type transactions and zerocoin is better for uniform type currency transacting?  I guess the root of my question is why are we going for this, rather than zerocoin?

Zerocoin hides sender/receiver but does not hide amounts. The ring signatures of CryptoNote also hide sender/receiver but not amounts. (Technically, when I say doesn't hide amounts, I mean that these work on fixed-denomination assets. You could have a collection of related assets of different denominations, e.g. a $1 bill, $5 bill, $10 bill, etc., and send an appropriate combination of them privately to the receiver to effectively hide the amount. There is then the added complication of converting one asset to a combination of other ones and vice versa  to implement "getting change".)

The ring signatures of CryptoNote grow in size proportional to the number of balances the user wants to hide in. (Technically, Chandran signatures can be used to have the signature grow with the square root of the number of balances. However, their applicability for cryptocurrency has been contested. And apparently they require a trusted setup, so that makes me immediately consider it a non-starter.) For that reason, users need to compromise privacy a little and choose a small set of balances to hide in for the sake of reducing transaction size. (This compromise is also beneficial in making it easier on lightweight clients. But they would still need to request from a full node the balances of a few candidate blocks, one of which holds the balance they want to spend, to then filter down to the handful of balances, one of which must include their spending balance, that they wish to generate the ring signature on.)

On the other hand, I believe Zerocoin's spend signatures (really just the serial number and the zero-knowledge proof) are fixed size regardless of the privacy level wanted. (Zerocoin uses a one-way accumulator that needs to be computed by all nodes in the network. This can be done incrementally by the nodes for each new stealth transfer transaction. However, to generate a signature, the spender needs access to the accumulator by the end of the block just prior to the block in which their spending balance exists and the commitments of all balances in blocks that come after the block just prior to the block containing the spending balance, which seems to me to be a major problem for lightweight clients.) Despite being fixed size, the zero-knowledge proofs of Zerocoin are pretty large and take a while to verify.

Besides not hiding the amounts, the CryptoNote and Zerocoin methods suffer from the fact that they make full blockchain pruning impossible. (Actually, I may be wrong about this. Blockchain pruning might be possible, I just haven't yet figured out the details of how it would work. In any case, I would imagine blockchain pruning would require some time limit for users to redeem/update their balances before they are lost forever.) The blockchain needs to store all serial numbers that have been used to redeem the tokens to prevent double-spends. So it grows in size without bound over time.

Zerocash hides both the sender/receiver and the amounts. It uses a special zero-knowledge proof called Succinct Non-interactive ARguments of Knowledge (zk-SNARK), which allows for a much smaller proof than Zerocoin. It would seem to be the ideal system, but the problem is that zk-SNARK are very new cryptography so there is some uncertainty regarding whether it is appropriate to trust it yet for this purpose, and more importantly it requires a trusted entity to setup the initial parameters needed to make the proofs work. If this entity cannot be trusted, they could produce free tokens out of thin air. I also don't know what limitations it poses on lightweight clients.

Confidential transactions allows the amount to be blinded but by itself not the sender/receiver. This blinding process is really efficient: it is easy to compute the blinded values and to verify that sums add up, and even the range proof construction/verification isn't too bad; since it doesn't hide metadata of sender and receiver, it is easy on the lightweight clients since they don't need any other information from the blockchain that isn't relevant to their balances/transactions; the cryptography is mostly straightforward and better understood than zk-SNARKs, and doesn't require any trusted setup; and even though the size of the range proofs are somewhat large, they aren't too bad (an order of magnitude better than size of Zerocoin's zero-knowledge proofs) and with this new Compact Confidential Transactions, the size of the range proofs become very small (approximately the same size of zk-SNARKs of Zerocash and smaller than a CryptoNote ring signature that hides within at least 8 balances). Adding stealth transfers on top of blinded amounts allows both the amount and the recipient to be hidden from the public (although for the recipient to remain hidden they need to not do things with the received balance that links it to their real account). Tumblers and CoinJoin (which have augmented privacy because of blinded amounts) can then provide users with the added privacy they need to move tokens from one account to another without linking the together.

Finally, I should mention that all of these techniques are to provide privacy for simple transfer operations. Market operations and smart contracts (generally) require knowing the plain-text amounts.

So this means that anyone can see that I sent or received a transaction, but not now much or what it was?
That's what I understood .. yep ..

Hmm, the original post seems to be deleted for some reason. But I just want to clarify that you can still tell what asset it was just not the amount. For example if account A sends 100 BTS to account B, the public will be able to tell that account A sent some unknown amount of BTS to some account (if it is a blinded but not stealth transacton then the public can also know with certainty that the receiving account is account B). On the other hand if account A sends 100 BitUSD to account B, the public will be able to tell that account A sent some unknown amount of BitUSD to some account.

Edit: You could in theory obfuscate the asset sent as well by simply sending a wide variety of assets with each transaction, where all but one are of a zero amount. But  first you would need to have plausibly received that asset as a blinded transaction to the account that will be doing the sending. Also, you need to make sure that the receiver merges in all the assets (including the zero amount ones) into their account to not leak information about which was the non-zero one. Also, the transaction size (and thus fees) scales with the number of assets you want to hide in. So because of that and the added complexity on both sender and receiver to avoid leaking information, I think it quickly become not worth the added privacy.

Bm is not a gui developer but has grown the gui team for 2.0 to a total of 5 or 6.   Even Nathan is doing gui work.  That leaves only 4 people doing backend work.   

Back seat managers think they can get more out of cass svk chronos and valentine James and  others don't know what they are talking about.   


Thanks everyone.

Pages: 1 2 3 [4] 5 6 7 8 9 10 11 ... 81