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 ... 81
Will the BitShares community please learn the lessons that Steemit had to learn the hard way?

Regular users cannot be trusted to generate high-entropy passwords suitable for the Account Model.

I submitted an issue on GitHub regarding this.

General Discussion / Re: Bitshares 3.0 - It Is Time
« on: June 27, 2016, 08:23:41 pm »
but disdain for idea #1 should not be a reason to write off the other ideas.

Absolutely. Bootstrapping liquidity is very important. And for the DEX to actually be decentralized, we really need something better than OPEN.X assets which have all the counterparty risk that centralized exchanges have. Multisig sidechains are one way of solving that. Can you explain what the  SuperNext and B&C Exchange model for solving the counterparty risk problem is?

General Discussion / Re: Bitshares 3.0 - It Is Time
« on: June 27, 2016, 06:33:50 pm »
The only difference for steem that justifies the small additional pow is to capture a large initial community. Steem depends on its community way more than BitSahres. The target audience for BitShares are TRADERS ..

Also the PoW implementation in Steem doesn't even gain any of the pros of PoW that CoinHoarder is concerned about. It is entirely a marketing gimmick so that irrational PoW zealots [1] don't automatically dismiss it because it isn't PoW.

[1] CoinHoarder, I am not calling you that, since you seem to have weighed the pros and cons and analyzed it critically (you just seem to have different values than me on what is important for you to come up with a different conclusion). But the vast majority of cryptocurrency PoW enthusiasts don't have the skills to actually analyze consensus mechanism critically and they just follow the herd blindly.

General Discussion / Re: Bitshares 3.0 - It Is Time
« on: June 27, 2016, 06:17:46 pm »
All consensus mechanisms have both, pros and cons. You guys are focusing on dPoS's pros, meanwhile forgetting the cons of dPoS and the pros of PoW.

The main issue with dPoS (and all other forms of PoS) is that an attack  can be maintained indefinitely at no to little cost once 51% is reached. The same cannot be said for PoW, because of the costs of electricity to maintain an attack.

I know the pros and cons. I have carefully weighed the pros and cons. And the optimal solution to me is crystal clear.

There are plenty of PoW coins out there for people if they personally believe PoW wins over DPoS in the pro/con analysis. I would hate to see BitShares lose one of its defining features that makes it so great in my opinion. The good thing is I am pretty sure this community overwhelmingly sees it the same way.

General Discussion / Re: Bitshares 3.0 - It Is Time
« on: June 27, 2016, 05:44:15 pm »
Maybe you all have spent too much time sequestered in this community to realize this, but dPoW is a big reason why a lot of cryptocurrency users have written off Bitshares.

I realize it, but they are wrong. If they are ignorant about the benefits of DPoS over PoW, then we can try to educate them. But if they refuse to listen to reason (which so far seems to be the case), then that's unfortunate. We have created the internal combustion engine, and you are asking us to go back to horse and buggy because that is what some of the people in the cryptocurrency crowd are comfortable with. I refuse.

My hope is some of them wake up after fully realizing that even Ethereum is switching from PoW to PoS and that it isn't going to be some security disaster.

After extensive debate about BSIP 0016, it is now scheduled to go into effect on June 21. Some have argued that this breaches the implicit contract that smart coins are convertible to 100% of their BTS value. In this post, I argue that this change does not breach the contract.

The question comes down to this: what is the contract around BitCNY? I believe it is a social contract: a contract for stable value. This is why Bytemaster designed the forced-settlement parameter to be adjustable by the committee. It could have been hard-coded, which would be a technical contract for 100% BTS convertibility, but I think that would leave SmartCoin pegs more brittle, subject to greater volatility.

If the peg breaks out to the upside, the forced-settlement parameter can be lowered, to incentivize traders to bring it back down. If the price pushes below the peg, the parameter can be brought up to 100% to instantly correct it.

It should be noted that, similar to how other markets work, sometimes the expectation and potential of these changes is enough to affect the market. For example, traders are more likely to sell their BitCNY at 105% of the price feed, instead of letting the price creep even higher, when they know that the committee will step in to bring the peg back to sanity in the case of a runaway peg.

If the SmartCoin peg were a technical contract for 100% convertibility, it would have been designed as such, without making parameters changeable by committee. Instead, the committee does have this power, making it a social contract to track a price feed. This social contract will be maintained by BSIP 0016.


Yes, this is my understanding as well, which I described previously in this post. This is why I don't believe the proposal violates the intent behind the BitCNY smartcoin.

There is however a dispute in the community regarding this manner. So how does a decentralized blockchain settle the dispute? As I described in this post sharing my thoughts on the The DAO hack and Ethereum's hard forking choice, there needs to be some arbitration process by a decentralized group that people entering into the contract agreed to. Well BitShares 2.0 has that via our on-blockchain governance features. (Technically all blockchains have it ultimately through users choosing which fork they wish to adopt, but it is more convenient to formalize the consensus process with governance mechanisms on the blockchain itself.) The community has gone through the proper process, and it seems the result is clear: it appears that BSIP 16 is going to pass.

Now this doesn't mean that I necessarily think the proposal is a good idea or that it will actually help the peg. But I just wanted to point out that I do not personally believe this change violates the intent of the smartcoin smart contract, and that the community has gone through the proper human-based decentralized arbitration process using our governance features (by voting on the 0-pay worker to support the change and not voting out the committee members who approve the proposal) to settle the dispute regarding whether the smartcoin intent is violated by this proposal.

[member=18133]arhag[/member] Would Stealth benefit from the use of Schnorr Signatures in any way?
Anyone think this route would be better than going with CN, CT, CCT, ZKT, etc?

A Schnorr signature by itself doesn't get you any privacy benefits that a ring signature (or Zerocash's complicated zkSNARKs) would give you. It is just another way to do signatures as an alternative to the ECDSA that is currently used in BitShares (and Bitcoin and most other altcoins). Now I do think a Schnorr signature is better (for example it very nicely allows for arbitrarily large efficient threshold signatures). And I would very much love to see BitShares eventually use EdDSA. But that is sort of unrelated to the topic at hand.

Did you say you had a cryptography guy helping you with this process? Because if you want to build something that goes beyond simply implementing a GUI for the existing blinded transfer feature, then that is really important.

I agree with your first commend on steemit, but I can't open the second one.

The second link is the same link as the "differentiated" link in the first post. Let me try reposting the raw link (I really hate this forum's buggy @ mention implementation  >:():[member=120]xeroc[/member]/improvment-bitshares-workers-proposal-thedao#[member=18133]arhag[/member]/re-xeroc-improvment-bitshares-workers-proposal-thedao-20160520t015315090z

Actually, many of the items in your list I think would be addressed in BitShares simply by providing voting rights to only vested BTS (which is what the link above discusses mostly). But it is a huge (social) change, because it requires printing BTS to pay interest to vested BTS.

Let's admit it, DPoS isn't ideal to fund development. At least not as good as Dash's masternodes

How is Dash's governance and proposal funding system better? I'm actually curious, because I haven't had time to look into it yet. On a very quick inspection I didn't see anything novel or that stood out to me (when I compare to what BitShares already has). Keep in mind, I am talking technicals here. Maybe Dash stakeholders are blessed without an anti-dilution camp holding them hostage. But that has nothing to do with the technology.

That doesn't mean BitShares governance systems are great. I have issues with it which I have talked about here and here. And I have some additional ideas (in drafts or even still in my head) for how I would like to see the worker system change to provide greater certainty to those getting paid who got elected. It's not great to get your worker elected only to worry everyday whether your worker is being paid or not because of vote fluctuations.

But the bigger issue is, could we get stakeholder consensus to implement such a large change. Probably not.  :(

I am probably not going to ultimately use RingCT. I think we can combine CN and CCT (one timers and compact conf tx (h/t Blockstream)), radically reducing the space that is needed and then dump proof of square this way. We are still working this out, but this just might be the ticket.

What is CN?

One time rings which mix the senders identities for untraceability

Are you talking about the linkable ring signatures used in CryptoNote, which are based on the "Traceable ring signature" by Fujisaki and Suzuki?

Apparently according to this Monero paper (warning PDF), the LWW ring signatures (Linkable Spontaneous Anonymous Group (LSAG) signatures by Liu, Wei, and Wong) are more space efficient than the FS ring signatures.

And I believe Compact Confidential Transactions were broken.

Right now I think that is just hearsay by btctalk "Poloniex Matthew" (a btctalk newbie)

After looking into it more carefully, it seems it was broken last year but was fixed. Here is a better link explaining the original problem. Gregory Maxwell reported on June 24, 2015 that Andrew Poelstra was able to break the cryptosystem. A day later, Mixles (Denis Lukianov), the creator of CCT, commented that he updated the paper to fix the issue but because of it the proof was slightly less compact (but still much better than CT). The thread is really long and detailed so I just skimmed it, but it seems some other minor issues came up and were addressed, and then there was a bigger issue and it seems that was eventually addressed. However, of the four variants of CCT available as of that last update, 1 and 2 are non-starters because they require trust, 3 seems to not be interesting for our purposes either, and 4, which is the interesting one to consider, now has much larger proofs that are close to but I suppose still half the size of a CT proof that hides all 64-bits of the amount (but if only hiding 32 bits of the balance with CT is enough from a privacy perspective, then there doesn't seem to currently be any significant proof size advantage).

Given all of the above, I feel more comfortable sticking with regular CT for now. Especially considering that LSAG signatures have been adapted to work with CT by Monero devs (see the Monero paper I linked above) and an implementation for it already exists.


I'd like to see the discussion separate the affordability/priority issues from the underlying best approach.

If Ken has a whale sponsor with deep, um, blubber, what is the best thing to build for the ecosystem?
Please read my post above, my concern is not just affordability. Assuming one approach is the "best" is itself an error, IMO.


We need both simple blinded transfers (with no hiding of metadata) and also a great stealth system (there is a lot of room for debate about which stealth design is superior). The two different approaches come with their own trade-offs in user-experience and costs (to the user).

Simple blinded transfers should be the priority and come first. If there really are whales willing to throw lots of money at the problem, then both solution can proceed in parallel. But building a GUI for simple blinded transfers is a much easier problem, so I expect it to be completed first.

General Discussion / Re: At least BTS outlasted NuShares
« on: June 09, 2016, 05:30:05 pm »
it will fail in the sense that you can only redeem your SBD at 0.1% a day or some other non viable amount.

We have different definitions of failure. Let's say a huge BitUSD holder force settled into BTS and then dumped it all in a low liquidity BTC/BTS market. How much (in dollar value of BTC) would they receive compared to the nominal dollar value of their original BitUSD holdings? Obviously, when liquidity is low you can't just exit quickly. So you convert and then sell small portions at a time to maximize the value you are able to convert to fiat starting from your smartcoins.

Now, because such a huge lump sum will be rewarded on July 4th, I do think there will likely be some craziness in the markets on July 11th. But going forward, the rate of daily SD issuance will be far more sane.

I prefer not to store data on our blockchain, hence my IPFS preference.

For the small amount of data we are talking about in my design (likely less than 100 bytes added to the blockchain each time you change your account keys, which is not very frequent), I highly prefer the blockchain. There is no current mechanism to incentivize many people (for sufficient decentralization) to store IPFS blocks long-term. For something as critical as access to my account and all my funds, I don't trust its availability enough as it stands.

I am probably not going to ultimately use RingCT. I think we can combine CN and CCT (one timers and compact conf tx (h/t Blockstream)), radically reducing the space that is needed and then dump proof of square this way. We are still working this out, but this just might be the ticket.

What is CN? And I believe Compact Confidential Transactions were broken.
Have you looked at Zerocash ( Hiding who you are, where you are connected etc might be a lot easier if we can somehow use their method for the mixing stage.

From my limited understanding of Zerocash (zk-SNARKs wtf?) it doesn't have very good performance, and does it still require a trusted setup? If so, that is a non-starter to me.

General Discussion / Re: At least BTS outlasted NuShares
« on: June 09, 2016, 04:21:27 pm »
I hope the steem guys learn something from this...
Is that comparison fair?

Afaik SteemUSD are always liquid and still pay you interest ..

It is fair to make the comparison in the same way it is fair to make the comparison to BitShares smartcoins. But I think the critical difference is that there are hard-coded safeguards in Steem to prevent users from making reckless decisions that lead to a dangerous debt-to-equity ratio. As far as I am aware, there is no limit to how many NuBits can be printed other than self-enforced community policy. In Steem, hard-coded features continually drive the debt-to-equity ratio towards a very conservative equilibrium value of approximately 2%. And conversions only work in one direction: the blockchain can convert SD to STEEM for you, but it will not convert STEEM to SD at a user's request.

So this comes with the disadvantage that there may potentially be a much smaller supply of SD than the demand for it. If this is still true despite dropping interest rates to 0%, then SD will have a large premium over the dollar. This is nothing new to the BitShares community. Even with the shorting-to-existence ability, BitUSD has experienced premiums over the USD as well. But with stronger limits to the supply of SD, I wonder how it will manifest in SD's ability to maintain the peg.

Anyway, that and the fact that it would force all token holders effectively into a short position, is why I am against using the Steem Dollar mechanism for BitShares smartcoins (at least as the primary mechanism for the peg, I think it is fine as a last resort insurance mechanism similar to what MakerDao is doing with the Dai, but again not via printing BTS but instead with some other token whose holders have chosen to take on that risk).

[member=30868]kenCode[/member], I agree with [member=11]dannotestein[/member] that if you are going to be working on privacy features the first thing to work on is the GUI implementation for blinded transfers (not other stealth features). This should also include changes to the GUI to automatically backup the old memo key onto the blockchain (not IPFS, don't worry it's not a lot of data to backup) any time the memo key is changed. It should be backed up in a way such that the new memo key can retrieve the old memo key (at least the last known one at the time of the change), so some with the latest memo key can follow the chain of backups on the blockchain and recover all memo keys that had been active for the account. It should also be possible to retrieve the latest memo key using the current owner key (at least for scenarios where there is a single owner key that can have owner authority) so that someone can recover full access to their account using just the owner key (or actually brain key).

I think spending resources on some stealth that goes beyond simple blinded transfers may be a misallocation of resources (depending on what the particular design of stealth you implement is).

I need to continue thinking about and working on my ideas for the stealth design and I will post a write up when I can. But I will give a basic overview. First, it requires Monero's RingCT cryptography by Shen Noether. This cryptography allows linkable ring signatures that work with blinded values (Pedersen commitments). But instead of using this cryptography to just pay a stealth balance to a recipient directly, the cryptography is used only for decentralized on-blockchain coin-mixing. The main reason is to reduce the risk of lost funds due to no recent backup. In my system, the amount and sender are hidden, but the recipient is not. This means there is no out-of-band communication necessary for someone to know they have received funds. They also don't need to do any backups after receiving funds to be able to get access to their received funds from only a brain key. The amount is hidden in the same manner that Confidential Transactions already do. The sender is hidden by making the payment from an active stealth balance that has not already been used to pay any other recipient. A new stealth balance can be created from an old stealth balance using the decentralized on-blockchain coin mixing process. Holding multiple active stealth balances at a time allows a sender to, with high likelihood, have enough funds available to send without needing to wait for the coin-mixing process. The nature of the coin mixing process means that someone can follow the chain of coin mixing steps in an efficient way and retrieve all of their active stealth balances starting from a root set originating from their public account (i.e bandwidth-efficient restore from only a brain key for a light client is possible even if the user has active stealth balances), and yet the public cannot do the same thus keeping the identity of the owner of each stealth balance private.

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