This approach allows ME to have someone else sign SOMETHING without them being able to prove they were the one who signed it which could be useful for multi-sig / two-factor on confidential transactions.

Ah, got it. The tricky thing is that the only person who is able to derive this one-time public key is the one who can generate a, b, c, d, P, and Q (Alice in the example). But I would think for private multisig to be useful the sender of the funds needs to be able to independently specify the public key that is allowed to withdraw the funds using only public information about the receiver. So that means unsolicited funds could not be sent to Alice with this kind of blinded withdraw condition. It would require Alice to provide the sender with the one-time public key that Alice generates in order for the sender to send Alice the funds.

As an aside, for this to be really useful, it would be nice it the scheme could be augmented into a blinded threshold signature scheme (to generalize from a blinded 2-of-2 multisig to a blinded M-of-N multisig). In fact, I would be concerned with being dependent on another party to be able to access my funds. But at least that part can be solved through a convention of everyone using a 1-of-2 multisig where the 2 keys are different one-time public keys: one between ME and the regular blinded signer, and one between ME and my cold storage key acting as the blinded signer.

You just need to cut and paste the text and use the [ quote ] [ /quote ] tags. The opening tag takes link, topic, and date parameters.

Yeah, that's the hack I have to do sometimes. But it's really annoying if you use a lot of markup. For example, I would have to re-implement things like lists, links, and emphasis. It would be really convenient if I could just get the original markup of any post regardless of whether it is in a locked thread or not.

Could we modify SMF (or is there an existing way) to get the markup of a post (the stuff you see when you Quote it) even if it is in a locked thread? Sometimes I find I want to reference a part of an old post but I can't (without trying to recreate the markup) because the thread has since been locked.

This could also then make it possible to write a bot to backup all of a user's posts which is something I am interested in (anyone know of an existing bot compatible with SMF that would do that?).

I think in addition to the (relatively small) fixed registration fee for witnesses, a witness should be required to deposit funds (of some fixed amount specified by the network) into a surety bond for them to be considered a valid candidate. These funds can be withdraw if the witness decides to retire (perhaps temporarily) but there would be a 2-week delay in that process (the retirement, meaning no more block production, would be immediate or at least would occur by the next maintenance perod, but the fund withdrawal would be delayed). A registered witness without a bond is not a valid candidate witness. People can still vote for those witnesses, but no matter how high their approval gets they will never become an active witness if they don't have a sufficient bond posted.

In addition to voting for a witness, stakeholders should optionally be able to vote to ban a particular witness. If the amount of stake voting to ban a particular witness exceeds some threshold, e.g. the median approval votes for active witnesses, the blockchain will ban that witness. Banning means that the blockchain takes away the funds in the surety bond from the witness and prevents that witness account from ever becoming a candidate witness again (obviously the person behind that account can always register a new witness account).

With this change there would be a financial incentive to not misbehave (for example by double signing blocks) even for witnesses who don't care about ever being a block producer again. It would also provide a mechanism for witnesses to legitimately retire without having to ask stakeholders to vote them out or compromise block production.


A more advanced alternative to banning witnesses would be to allow anyone to provide proof of a double sign and have the network do the banning automatically if a valid proof was provided (and also reward the proof provider from some fraction of the surety bond). A hybrid approach might also be desirable. For example, if the ban votes for a witness exceed some low threshold, then a double sign proof is enough to get the witness banned. If the ban votes exceed some higher threshold, the witness is banned without any crypographic proof required. This modification requires ensuring that the block signing protocol is designed in a way that small double signing proofs can be submitted and validated (I'm not sure if the current protocol is designed to support that).

If there was an easy way to structure information exchange to avoid front-running that would be great. But, I'm not sure if it can be done simply and without other tradeoffs.

The new approach is so much better than BitShares <1.0 where the network itself pesimistically front-runs all order matching.

I agree with this.

I still think that adding the encryption on limit orders so that we can at least ensure all risk-free front running is limited to only the witnesses is an important improvement with little downside. And remember even that would be optional for users. So those users who don't want the slightly larger transaction size to enable that, since they aren't concerned or care about someone front running their order, don't need to take advantage of that extra protection.

One of the first things I think we should start with is asking all the 100% paid delegates to declare whether they are the ones actually running their nodes, and if so, are they still interested in running a witness node in BitShares 2.0 (at witness pay levels of course). Then we should go through all the other delegates in the top 101 and try to identify the bitsharestalk forum user who controls that node. If this person has publicly revealed their identity, then that makes things easier. Otherwise, we should try to determine how confident we are that more than one of those identified forum users are not controlled by the same person. This is of course impossible to do accurately, but we can get some sense of it by looking at the reputation and activity level of those users on the forum (at this stage few people would be willing to put in the time and effort required to make multiple accounts they control all appear to be active and individual people with their own unique thoughts and ideas). This process excludes otherwise viable candidates for witnesses who happen to not be very active on the forum, but in that case I think they either need to start getting active and/or reveal their identity if they really want to become a witness.

He proposes the solution BitShares uses (paying trusted block builders who must maintain a good reputation) but doesn't attribute it to BitShares.

The way it works in BitShares still has flaws. For one, the important market information (such as amounts and limit price) are not encrypted. Anyone in the network passing your transaction around can see it and attempt to front run you (although it is more difficult to do that reliably than as a block producer). The fix to that is simple. You encrypt those sensitive values with a random key and include the hash of that random key as part of the signed transaction. The transaction included in the block is only valid if it has the necessary signatures and the random key that hashes to the included hash value (which thus allows anyone to decrypt the sensitive values). The random value would also be encrypted for any of the witnesses who are expected to include it into their blocks (one or more) and attached along with the signed transaction as part of the transaction bundle that is passed around in the p2p network. This means that those selected witnesses act as the trusted arbiter for that limit order, and thus they are the only ones who could front run if they choose to.

Now we can argue that we trust these witnesses because we voted them in and their future income depends on their reputation. The problem is that only works if they can get caught. Getting caught is easy with double signing blocks. It is not easy with front running. If we only select a small number of witnesses (say 2 consecutive witnesses) to share the random key with for each limit order, and because the witness order is shuffled each round, one may think that allows the opportunity for statistical analysis to determine if a particular witness is front running. The problem is that there is no way to distinguish between that and someone who is just trying to frame that particular witness to get them voted out. So we couldn't rely on statistical analysis to keep witnesses honest under this particular anti-front-running strategy.

However, I discuss ways that we could do better than that in the post that I linked to.

This feature (https://github.com/cryptonomex/graphene/wiki/design-issues#voting) would help with that a lot in BitShares 2.0. If that isn't supported (and I don't know why it shouldn't be since it is a relatively simple tweak), it can be approximated (at least for voting with BTS stake) using a zero pay worker proposal.

As for voting in the current BitShares 0.x system on the upgrade to 2.0, wouldn't it be easier to just have all the current delegates (and delegate candidates) publicly announce their position (for upgrade or against upgrade) and let the stakeholders vote them in and out appropriately over the next month? That way if the stakeholders are against the upgrade (which I don't think anyone believes is true), BitShares 0.x will have the right block producers in place to avoid the node upgrade that would cease block production by a certain date. I'm a fan of letting the elected representatives just do the right thing but allow the stakeholders who actually care to veto their decisions (and quickly vote them out) if they disagree. For example, I think the 2 week delay on delegate actions in BitShares 2.0 strikes a great balance between progress and stakeholder control when considering the reality of voter apathy.

Edit: Then again, this is a huge change. And in BitShares 2.0 any hard forking change should require active stakeholder approval. So I guess what you are proposing is the same thing. Plus, it is a easy thing to do, so why not. Let's see how long it will take to get upgrade-to-bts-2 voted up.