Should we migrate to an output model rather than a address model? #189
Comments
|
Stop emailing!
|
|
@Ether00r I'm not emailing, I'm opening issues on github ... you're welcome to unsubscribe if the traffic is too much. |
|
Well to be honest I have been a bit active on the email front in the last few days, but this particular issue is just an issue on github, not an email ... My job is 90% composed of emailing ... that's just what I do... Anyway, back to the topic at hand (if you want to continue, let's take this offline so as not to bother everybody else who subscribes to this issue). |
|
outputs based is basically colored coins, right? I don't know of any way to implement MSC features that way. |
|
LOL said:
|
|
The model of token transfer that I've been exploring is based around the concept of an output representing an arbitrary quantity of tokens that is implicitly spent in the transaction in which that output is spent. By defining a default/change output for the coins to be returned to, it can be guaranteed that even if the transaction is invalidated the tokens are returned to the sender (though not with the necessity that this is the same address). A data output would be the means by which the sender specifies the quantity of tokens sent between, for example, 2 different outputs. This is one of the simplest types of transactions that explicitly states intent. The methods of considering a transaction properly formed can be drastically simplified from the current implementations due to the ease and clarity by which inputs "enter" a transaction and outputs "exit" a transaction. The models nature allows it to use more abstract definitions in specification without the implication of vague interpretation when implemented. I'm curious to hear anybody's thoughts whether this could affect the ability to establish or maintain consensus? I think that by considering a script type interpretation of the data output, the flexibility employed by Mastercoin could be maintained, and can potentially reduce the size of data outputs by creative utilization of input index numbers and output index numbers. There is further exploration to be done on this subject. The paper I wrote outlines a method by which a transaction that requires multiple data outputs can be "staged", at which point in time can be checked in a manner which essentially asks "if this were confirmed right now, would it be considered valid?" A staged transaction has the benefit of inherently ordering relevant packets and can establish a mechanism by which OP_RETURN outputs can effectively be implemented, without significant disadvantage in terms of the effect of quantity of bytes of storage per transaction. I outlined a method of "executing" a staged transaction with what I call a terminal transaction, which provided it satisfies the requirements of the staged transaction that it executes, can pave the road for some pretty interesting possibilities. Primarily what comes to mind is atmonic trades between various assets. Oh, this model also removes the ambiguity between a valid transaction and its double spend. This would go a very long way in terms of answering questions like, "By what technical mechanisms are Master Protocol transactions secured?" Also, it supports the the best Bitcoin practice of not reusing addresses. Anyway, there it is. I pitched it. This outlines a protocol I envision that doesn't intend to make sacrifices. |
|
My brain is not functioning well right now (it's too damn late and I need sleep!), but this sounds like a good idea. I'm going to wait for the brilliant minds we have on the team to actually vet it. FYI I've been contemplating an output model for a long time, it was just never very high on my list of priorities. I'm glad we're pushing this discussion. If we can leverage this to get:
This would be simply AMAZING. @petertodd, thoughts? |
|
Short version of my opinion about this issue:
Edit: for the reference: |
There is nothing about an output model that would inherently restrict the implementation of any specific Master Protocol function. A topic that hasn't been discussed rigorously is by what guidelines the content of the data output can affect the movement of tokens. I personally believe the best practice in this respect would be to use guidelines that work cohesively with the underlying Bitcoin protocol. That is, establish a model by which tokens act similarly to Bitcoin, and thus can inherit certain properties of Bitcoin transactions. There's valid analysis to be done on the requirements of implementation for each one of these features. It's entirely possible that the functionality of each could be achieved, though by taking a different form. Regardless, liberties taken with the functions that can be achieved with the data output are not limited to that which is compatible with a specific output model. What I mean to say is that, properly defined rules can allow the result of a data output to affect working balances in the system without requiring that the mechanism by which the balances are affected be directly compatible with the output model. It's an interesting topic. The takeaway is that it would be valuable to have an understanding of how the guidelines of the data output affect or compromise a specific output model.
My concern with this type of hybrid model is that it may exacerbate the issues with the current state of the Master Protocol and various implementations, rather than serve as a method to evaluate an output model, or as a mechanism by which the Master Protocol can transition to an output model. Primarily, this is in terms of the complication to the specification that would define how this could function, and consequently the complication in implementation. Further, defining a method by which a token in an address can transition to representation via output implies a protocol layer on top of Mastercoin. This protocol layer would inherit the qualities of Master Protocol instead of Bitcoin, and thus would not be a net gain. |
The current transaction types, a potential "switch between balance/output" transaction and output bound transactions are all on the Mastercoin protocol layer. Only because output bound transactions share some properties of Bitcoin transactions, namely balances are attached to outputs instead of addresses, does not imply they are pure Bitcoin transactions. The concept of color/tokens or transferred token amounts are already part of a layer on top. A hybrid model requires a correct view of world based on (traditional) Mastercoin transactions as well as output bound transactions whereby a pure output bound model only requires a correct view based on a chain of outputs. Nevertheless there are benefits by adding output bound transfers, even without the (huge) gain of simpler verification in an output bound only model, e.g. the transfer of tokens from and to multisig/script outputs and thanks to the properties of an output bound model a trade between MSC and BTC without the need of an "accept offer" transaction. Contracts in the context of escrow and time locked transactions would also be possible. So you could say: the output bound model doesn't gain anything by allowing (traditional) MSC transactions, but MSC clearly does. I suggested a hybid model, because the only alternative is to redesign everything from the ground up. Even though I'd love to change some parts of the current stucture and I'm generally in favor of an output bound model, it still needs to be evaluated, if similar functionality is even possible. That aside, there are upcoming crowdsales. A whole different, but probably even more important topic that needs to be discussed is the one of forks based on protocol updates. Would be nice, to address this, too, if it comes to a redesign from the ground up. |
|
Astute analysis.
I actually brought that up here #196, though with a focus on ameliorating the stress on developers. The topic is relevant to this issue as far as an output model may make a solution to this problem more reasonable. I believe it may given this simplification in the verification process, and thus simplification in transaction/function definitions. |
|
Ah I see. I mentioned it, because this likely benefits from a redesign, too. On the other hand: if we find a solid solution for the fork problem, the verification complexity might not be as bad at it looks like due to the many changes and compromisses made to be somewhat in line with the history. But each topic in the right thread. I'd like to add that I'd still love to adopt #62 which seems to go in the opposite direction of this proposal. This does not mean, something similar may be constructed in an output bound model though. |
|
I've put together a document that intends to answer this question, as well as proposes a "how." https://docs.google.com/document/d/1CkLNkKTkH1BnmfE--9rZv16rkgZo_2nUy_thDvNcMtg/edit?usp=sharing @dexX7 The solution I've proposed is a new transaction type which converts address model coins to output model coins. Though this isn't the hybrid approach that we've previously discussed, it is similar. Skip to the section labeled "Solution" to get to the meat of it. My goal here is to get some momentum behind the idea, which will hopefully culminate in a pull request for the new transaction type and a plan for modifying the latest ChromaWallet SPV thin client to support output model Mastercoin transactions. I've gotten a bit of feedback from @petertodd, following:
Though I agree with @petertodd first paragraph, I don't believe that the consensus state of Mastercoin is expensive to change - at least not in the same way as the consensus state of bitcoin. Quick recap of reasons to transition to output model:
|
|
Half of those points are moot, but I like you keep pushing. It's still not clear to me how some Mastercoin specific features may be done in an output based approach (remember the crowd sale discussion for example..). I'd already be very happy, if there were an option to move tokens to outputs and back; historical transactions and validation are not interesting and both protocols follow some rules, but the killer features such as atomic trades or payment channels are. |
Following is a method of conducting a crowdsale that is fully compatible with the output model. Is it the best option? I don't know. But one major advantage that it has over the current system is that it resolves the problems related to payment coming in after the deadline, early cancellation, etc. by requiring a signature from both the buyer and the seller.
Buyer then provides inputs necessary to satisfy the outputs, signs and broadcasts. By the seller signing with SIGHASH_ALL | SIGHASH_ANYONECANPAY additional inputs can be added, however the outputs must remain unchanged. |
So think of it this way, a consensus system algorithm is basically a function f(s_{i-1},b_i) -> s_i that takes the block b_i, a previous state s_{i-1}, and produces the next state, s_i. There will be a bottom state ⊥ that corresponds to the "genesis" of the system, and finally a reversal function f' for rollbacks during reorgs. When we say the consensus state is expensive to change, we say that because the blockchain itself is expensive to change due to the proof-of-work; the function applied to that blockchain is assumed to be fixed. I think that's where your misunderstanding lies: you're assuming the function f is somehow easier to change in Mastercoin than it is in Bitcoin. Socially speaking, maybe that's kinda true, but in terms of the math involved that's outside of our definitions. Besides, you could just as easilly - in principle - define a new function f2 for Bitcoin that interprets the blockchain data completely differently... in fact we might even call it Mastercoin! It has happened in the past too, e.g. Namecoin where they fixed a bug by simply ignoring a big chunk of the consensus. |
|
So, the other way of talking about reversibilty - which I think you're paper is describing - is that in address-based systems if you have multiple transactions that affect the same address they are valid if mined into the blockchain in multiple orders, and the effect of those diferent possible orders on the consensus state is different. We could formalize that by saying that given a set of transactions T={t_0, ..., t_n} referring to txouts X={x_0, ..., x_m} in a txout-based system if all transaction in the set are mined, the resulting effect on the consensus state with respect to the transaction outputs contained in that set is the same. (note how malleability only serves to prevent the full set T from being mined) The reason why this is true is that transaction outputs have exactly two possible states, spent and unspent, so there are no degrees of freedom in how the transactions are applied. Why are there no degrees of freedom? Because n < m, and the mapping of transactions to outputs is 1:k! In a balance based system the transaction set T={t_0, ..., t_n} affects some set of addresses A={a_0, ..., a_m}. It is possible to m > n, the mapping of transactions to addresses is underconstrained, and we get degrees of freedom. Thus there are multiple valid orders that the transactions can be applied in, resulting in multiple possible states. Finally of course, if you constrain your address-based system so that each address is used exactly once you're left with a txout system all over again... |
|
Does this matter in practical terms? Yes and no. I just finished most of the Counterparty audit, and something that stuck out to me is how easy it is for small consensus failures to go un-noticed in an address-based system. Counterparty is very "forgiving" in how, for instance, a debit from one balance will succeed even if the debited balance is less than the amount being debited. There are lots of possible ways in which a series of transactions can partially fail and still result in the same consensus state, so even comparing balances against different implementations won't catch these errors. You don't get that problem in txout-based systems because the transaction either succeeds or fails. That said, because we can assume large reorganizations just don't happen, all that balance-based has done is forced us to wait longer to be sure that the state is recorded properly; this isn't a dealbreaker. Still, it is ugly. One advantage of balance-based systems is they are more efficient to encode as an embedded consensus system. We will have smaller transactions on average, and lower fees, if you can spend the result of multiple credits in one go. Equally highly efficient dividend payments only really work in an address-based system. You sacrifice privacy, consistency, and scalability by using this model, but transaction fees are less. Finally, I'm not convinced you really want the complexity of both models in one system. The main advantage of txout-based schemes is the consistency and scalability, and unless you ditch balances entirely, you don't get the benefits. |
I think it is. Not necessarily due to the longer waiting time, but rather based on the lack of atomic interaction. |
Considering the ease with which function f is changed outside of our definitions means that the point I was trying to make in the paper was not driven home. As current Master Protocol implementations are depreciated and Mastercore takes the stage this point may become less poignant, regardless, it has historically been unclear what the function f is. Ideally the specification would be able to define the function f. However, one would not be able to parse the blockchain using the specification and come into consensus with the current accepted state. This said, https://masterchain.info/general/MSC-difference.txt the various implementations are still not in consensus. So, when I say the following,
it has much more to do with the inability to know what the function f is at an arbitrary block height, and the requirement that users trust the reference implementation (or fork the project and abandon the bitcoins sent to the Exodus address last July), rather than an assumption that some Bitcoin transactions at block depth of x are more secure than other transactions at block depth of x. The irony about the situation is that we don't need to know what the function f is in order to trust Bitcoin transactions - but we readily have access to it, whereas we do need to know what the function f is in order to trust Mastercoin transactions and we do not have access to it. I've heard people toss around the phrase "the code is the specification." Which is all good and fine for Bitcoin, but the implication of this for Mastercoin is, IMO, centralization, the inability to independently audit an implementation versus the spec, and finally an increased challenge for the Master Protocol to outlive the lifespan of the Mastercoin project. |
Indeed. Gregory Maxwell had a good idea for this stuff recently: ship the core consensus code as a pre-compiled binary compiled for the same VM/scripting-language that your transaction scripts use. We're kinda far away from creating such a system, though some work is being done on it. re: centralization, the Bitcoin model - by having a few miners define what has happened - just makes the centralization risk be mining instead of the specification of the protocol. That's IMO a worse situation to be in - at least people can choose to ignore the Mastercoin project very easily if they "go evil". Ignoring miners holding centralized power isn't so easy. In practice I agree that Mastercoin has had some pretty ugly problems with lack of consensus, but that's a fixable engineering failure, not an inherent problem of the idea. |
Absolutely agreed. We're talking about a few different things here:
While these items are definitely relevant, they don't answer the question, "Should we migrate to an output model rather than a address model?" One of the interesting things about the development of the Master Protocol is that nobody (definitively) knows when funding will be exhausted, if development will continue after that date, if the protocol will outlive the project, and most important to many people, how this will all affect the valuation of Mastercoins. When I answer, "yes, the Master Protocol should migrate to an output model," I'm saying that a careful and delicate transition to the output model would better benefit the project than staying on the current development path. Due to the nature of the project, a stall in the development of a functional product not only diminishes the potential of the project, but threatens any edge that the project has over its competition. My argument is that the development of a protocol layer in which tokens are not bound to transaction outputs is not feasible given the constraints of the Mastercoin project. The development and implementation of a protocol is not a laughable task. Any way that the Master Protocol can take advantage of or leverage the underlying Bitcoin layer will be worth the time spent if it gives us more confidence that the Master Protocol will outlive the Mastercoin project - that is, that we can count on the protocol without the funded maintenance of the reference client. Given the "black box" problem we have with consensus, it's not reasonable to expect that the open source community will pick up the slack when funding runs dry. IMO, the transition to an output model enables the clear definition of the function f within the constraints of the project. This is without mentioning the functional advantages that the output model can provide over an address model. Needless to say, these are numerous. With that taken into consideration, it's logical that the transition to an output model, when properly executed, would be beneficial to the Mastercoin project and the longevity of the Master Protocol. |
|
To switch directions, I've added an appendix F to a branch of the Mastercoin specification, found here: https://github.com/LOLLOLOOLOL/spec/tree/addAppendixF#appendix-f---details-on-the-proposal-to-transition-to-an-output-model While the section and content is clearly incomplete it should be a good start towards the documentation that is necessary if the Mastercoin Foundation does indeed choose to migrate to an output model. The most notable item included is a method I've come up with to utilize multisig transactions to enable atomic trades between two different Master Protocol tokens. Also included is a note on how to conduct crowdsales in which the issuer can accept any Master Protocol token via a multisig atomic swap. While I may be most thrilled about the atomic swaps, others may be interested in the section I've included that explores the utility of Mastercoin in an output model Master Protocol. It's an interesting problem to explore - how Mastercoins can be leveraged to make the protocol better, rather than a token that could potentially damage the utility of the protocol. It's my plan to create a pull request to merge appendix F with the specification when the section is more complete - so if anyone has feedback, suggestions, additions, criticism, corrections, or an idea of where the content may better belong, I'd welcome it. :) Of course, any other contribution is also welcome. |
|
I don't see the point of switching, sorry LOL: I see you put a lot of effort into the proposals. The original question from Ron was: SPV client. Balance vs Output model:
|
|
@m21 Thanks for the input. The transition to an output model is not a trivial task, but I think that the advantages are worth it. I responded to some of the items below, most of which have a larger impact on usability and appealing features than anything else.
Yes! A thin (SPV) client, following is a link to where I proposed a roadmap and timeline: https://groups.google.com/a/mastercoin.org/forum/#!topic/dev/ev0QWGREwRM
Are you using a Chromebook? :) It would be pretty neat to run the reference client on both PC and phone, however I have concerns about maintaining the entire Blockchain on a mobile device. Bitcoin is costly in terms of storage, and bandwidth, both of which are not universally abundant for phones. Usability also takes a major hit if entire blocks must synced before using the client.
Absolutely does - with notable regard to atomic trades and micropayment channels. It should also be said that Master Protocol clients cannot check the mempool for pending Master Protocol transactions. Granted it is poor practice to accept 0 confirmation payments, regardless, it is valuable to see an incoming transaction and be able to spend an unconfirmed UTXO with the understanding that that transaction will only confirm if the prior does as well.
The difference is that the balance model requires (at minimum) 3 confirmations + depth, whereas an atomic trade requires 0 confirmations + depth.
This is possible and the functionality is already implemented in ChromaWallet. Let me reiterate that a DEx MSC buy (of the current model) requires 3 Master Protocol transactions. Not only does this require 3 confirmations, at a minimum, but but is also significantly more expensive (in bitcoins) than atomic swaps. Atomic swaps can be performed instantly via a single transaction that doesn't (necessarily) require expensive data outputs.
Address reuse is typically talked about concerning privacy, however there is a security component as well. Either way, a trustless Mastercoin tumbler isn't possible a la CoinJoin. |
|
Hi @LOLLOLOOLOL
|
|
@m21 My stance on the output model is that it will be beneficial for the Mastercoin project and create a more usable product. We all know that the balance model can work - it's evidenced by Mastercore. However, I'm not of the opinion that it can't be improved upon. It's not a matter of problematic implementation or UI, it's only a matter of the protocol specification. I'm trying to get a feel for your dismissal of the proposal, but I'm not sure what that is besides the amount of time and effort that the transition would take. I'd welcome your opinion on why the transition is a bad idea, or why you think the current model is better for the project. If any of my points are unclear, let me know so I can work on them - I'd rather rework them than see my effort lost. :)
|
|
@m21: regarding 6 confirmations. Think of it this way: I want to trade my Bitcoin for your Mastercoins, but I don't trust you and you don't trust me. The atomic trades allows to do a trustless trade in one step where on party can scam the other. It's fine to wait for confirmations afterwards (e.g. for the case of a global reorganisation), but it's no longer required to wait during the trade itself. But what's probably even more important are actions derived from this mechanism. There are quite sophisticated mechanisms that allow cross-chain trading for example or what's also extremely beneficial in my opinion: a DEx with a Bitcoin buying side. Another favorite of mine: micro-channel payments. Without going into details: this is a concept which allows instant trading (exaggeration: "thousands of trades in 10 miniutes") off the blockchain. https://bitcoin.org/en/developer-guide#micropayment-channel Accessing the mempool is worthless, because there is no indication of any order of how unconfirmed transactions end up in the block in the end. So even if you think the unconfirmed payment in your mempool is valid, Malloy can still double-spent his Mastercoins somewhere else. Just to be clear: I'm not advising to turn Mastercoin into colored coins, but I'm highly in favor of leveraging both approaches together. |
|
Interesting discussion. I would like to bring this up again in the future, @dexX7 . |
|
An output based approach seems to be superior, especially if no global consensus is involved, but on the other hand, we are basically able to create any feature one can think of, and send-to-owners is just one example. What I'd really like to see are atomic BTC/token swaps (see OmniLayer/omnicore#11). I've made some progress recently, and once OmniLayer/omnicore#74 + OmniLayer/omnicore#77 are in, the way is basically paved for almost-trustless swaps. Given that balances are currently not bound to outputs, but addresses, there has to be some other mechanism to lock and bind tokens. This could be done via a third party, which acts as secondary signer/gate keeper/output locker. A seller and the third party/oracle/server would create a 2-of-2 address in cooperation, and then define a "locked" output. The output to be locked would be the one of a simple send to the 2-of-2 address ("the funding transaction"). The server's role is simple: on request, it should provide a signature for any transaction spending the "locked" output, while ignoring requests, which attempt to spend other outputs. The seller could announce the funding transaction, and request a signature from the server for a refund transaction, even before actually broadcasting the funding transaction. From this point on the scheme is similar to a pure colored coins approach, whereby the "locked" output could be considered as colored output. The server can't steal coins or tokens, and due to the already signed refund transaction, there is also no risk, if the server simply vanishes. Right now I can think of two bad situations:
I've tested this, and the BTC/token swap locally with manually created transactions, and at this point I'm mostly wondering, how the process and the interaction could be wrapped into something more user friendly, which doesn't involve a rather long sequence of RPC commands. In the future there might be a mechanism on a protocol level to bind tokens to outputs, which would remove the need for a third party to simulate the locking/binding. |
|
@dexX7 @zathras-crypto @CraigSellars I think it's time to start talking about this again... |
|
We can have this as another RPC call or two to form transactions on a UXTO basis, and then, these can be better collateral for smart contracts. Talking with Sean about Trezor integration via OmniJ, and the apps we can do with OmniJ, I think it makes sense to try the address/privkey triggered approach to smart contracts discussed in the other issue, based on this tx format. People will be able to control keys and say 4 validators in a Credits app or 3 trustees in a simpler, legally contracted, not-so-decentralized app could hold keys and have professional security in the hard wallet. This also buys us speed in doing SPV wallets and trading interfaces that are higher frequency. That frequency of the Dex experience is another metric where we need a competitive edge. |
|
I suppose I'd favor Addresses. |
Currently the Master Protocol uses an address model - balances and operation are always tied to addresses, not specific outputs like Bitcoin.
As far as I understand, the outputs model has some advantages:
@dacoinminster - what were the considerations that guided you to use an address model rather than outputs? Are there any downsides to using outputs?
I realize that migrating the Master Protocol to use outputs may be a very large undertaking ... but it's possible that it's worth it in the long run. This issue is created to discuss this and understand the pros/cons/timing of such a migration, assuming it's possible.
The text was updated successfully, but these errors were encountered: