Multiple sends

[gidgreen]

This is a suggestion about how to allow multiple currency-send operations to take place within a single MasterCoin transaction, and allow the currency to be sent to any transaction output specified by index, rather than only to the "reference address".

The goal here is to enable multiple currency send operations to take place within a single MasterCoin transaction. From the commentary on the proposed change:

"One common use case is to send units of several different currencies simultaneously to the same address. Another common use case is to distribute funds to multiple recipients from a single input."

My underlying thinking is that as the volume of transactions on the bitcoin network grows, the day may soon come when transactions need to have significant fees attached in order to complete for inclusion in the blockchain. So it makes sense to look for ways to enable multiple related operations to be performed in a single transaction, rather than lots of individual ones. That will be cheaper for the user.

Gideon

[gidgreen]

BTW, sorry for the mess of associated commits and reverts.

[dacoinminster]

This is very interesting - I've been thinking that we needed to do some kind of multi-send, but hadn't got down to the nitty-gritty yet.

A few important notes:

• This can't be an expansion of simple-send. We need a new transaction for this, probably called "multi-send". Savings wallets and rate-limited wallets can only use simple-send, and they depend on it not changing. I'm hoping to make that more clear in PR Added smart property fundraisers, improvements to other future features #52
• If we DID change a transaction such as this which is already being used, we'd need to increment the version number on it
• The new multi-send transaction will need to go further down in the document to the "future" section.
• Do we really need the "which index" field? Shouldn't the first output go to index Added reserve clause to Selling Order description #1, and the second output go to index Initial proposal for verification API #2?
• I think we may need a "number of outputs" field.
  • Have you read appendix A? Class A transactions can't do this kind of multi-send at all, which is fine, since those are aimed at users which are only using a bitcoin wallet. Class B transactions probably need to change how they are encoded in order to support more than one reference address, so Appendix A would need to reflect that set of changes for class B transactions as part of this pull request.

I'm not sure how fundamentally the definition for class B transactions will need to change to support something like this. I'd be interested in Zathras' take on how this could be done, when he gets a chance. He's the one who wrote that appendix.

[dacoinminster]

P.S. Since you are clearly thinking about the spec, you might enjoy looking at PR #52, which is a fairly major set of changes currently under review, mostly around smart property.

[ripper234]

I haven't read through the details, but I like the idea, and it's been going through my mind for a while as well. Would love to see this integrated.

[gidgreen]

Thanks.

J.R. - the reason for the 'which index' field is that we want to allow this kind of multi-send to be used in several ways. Sometimes it will be to distribute assets to each output in turn (in which case 'which index' is indeed superfluous) but sometimes it could be to distribute different assets to the same output, and we need a way to tell the difference.

While we're discussing this have you guys thought more about the sort of information that should go into a smart property creation transactions? I think that a name string won't be enough to capture many of things that will be required to make a smart property meaningful, e.g.:

• Proof of the identity of the issuer
• The contract that defines the smart property
• A method for the issuer to communicate with holders
• Information about how the property quantity should be visually represented in wallets

I have a detailed idea about how to do all of this in my proposal for bitcoin colors, but before submitting some gigantic pull request, I want to know if it's of general interest.

Gideon

[dacoinminster]

Hey Gideon,

We are definitely on the same page about Smart Property. We decided to add a URL field so people can link to their website with whatever info on it they want (and possibly someday we will define an XML file which can be downloaded from the URL automatically with such info as might be displayed by the UI when viewing a smart property). I just added that to PR #52 yesterday :)

Can I induce you to get in touch with me by email (jr dot willett at gmail dot com) to set up a skype call about any other ideas you may have, and to what extent you want to get involved with the project? I'd also like to get you on our developer mailing list if you are willing.

Regarding this pull request, I think if we move it to the "future" section, add a "number of outputs" parameter above the outputs, and get Zathras' input on how the definition of class B transactions may need to change, we could be in business :)

[dacoinminster]

I emailed Zathras about this PR, but it may be a few days or even weeks before he is able to take a look. He's very busy finishing up his old day job, then getting out his wallet for beta, then working on the distributed exchange, and every minute of his time is precious. :)

[gidgreen]

J.R. - thanks for your response.

Just to be upfront with anyone else who is interested, I would like to explain my motivation here, which will also clarify the extent to which I'm interested in getting involved in the MasterCoin project and its specification process. I will also email you separately to set up a direct Skype call.

So I am building a startup to implement a number of protocols on top of bitcoin, the first protocol of which is my own take on how to transact in other financial assets over the bitcoin network. In spirit it's a bit like the colored coins proposal and project that has been around for quite a while, but with quite a few technical differences which I believe are crucial for scalability and usability (and which they don't seem interested in incorporating - which is their right of course).

Following a long and fruitful (at least for me!) chat with David Johnston at Inside Bitcoins Berlin, I am trying to see if it will be possible to maximize the amount of common ground between my proposal and MasterCoin. This will obviously be to the benefit of my venture, since MasterCoin has a large and vibrant developer community. To the extent that my suggestions are good ones (as judged by the MSC community) this might also benefit MasterCoin by making it a better product.

My main focus is on the products I want to build, and I am ambivalent about the protocol that they end up using, so long as it fulfils a long list of technical requirements that my products will need. Because of these requirements I don't think it will be possible for me to use MasterCoin in full because of two fundamental design issues: (a) balance-per-address vs balance-per-transaction-output and (b) the bitcoin/bytecount cost of requiring every MasterCoin transaction to send some bitcoin to the exodus address.

Nonetheless as I mentioned I would like to find as much common ground as possible, to make life easy for wallet developers to support both protocols, and for the purely selfish purpose of giving me a smooth transition to using MasterCoin if my protocol gains no traction and MasterCoin becomes a popular standard. One area I think with a lot of potential for agreement is the technical definition of how currency/property issues are represented, both within the blockchain, and on the web page that is referenced in the genesis/creation transaction. I would love of course for MasterCoin to adopt every other aspect of my proposal (!) but recognize that it has a different set of priorities.

So that's the background - a mixture of cooperation and competition if you like. If you are comfortable working together in this context, then great, and I would love to be involved in the MasterCoin spec. And if not, I completely understand, and I will stop bombarding you with PRs :)

Gideon

[CraigSellars]

Gideon,

Your interest is extremely welcome. We’re very interested in developing a firm set of requirements to what financial products will need to be properly represented on the blockchain, and are very much interested in your input.

We would like to see the Master Protocol enable people and groups like yours to develop new financial instruments that aren’t tied to the legacy financial system, and we look forward to collaborating with you and others like you who wish to fulfill that vision.

Craig

On Feb 21, 2014, at 3:02 PM, Gideon Greenspan [email protected] wrote:

J.R. - thanks for your response.

Just to be upfront with anyone else who is interested, I would like to explain my motivation here, which will also clarify the extent to which I'm interested in getting involved in the MasterCoin project and its specification process. I will also email you separately to set up a direct Skype call.

So I am building a startup to implement a number of protocols on top of bitcoin, the first protocol of which is my own take on how to transact in other financial assets over the bitcoin network. In spirit it's a bit like the colored coins proposal and project that has been around for quite a while, but with quite a few technical differences which I believe are crucial for scalability and usability (and which they don't seem interested in incorporating - which is their right of course).

Following a long and fruitful (at least for me!) chat with David Johnston at Inside Bitcoins Berlin, I am trying to see if it will be possible to maximize the amount of common ground between my proposal and MasterCoin. This will obviously be to the benefit of my venture, since MasterCoin has a large and vibrant developer community. To the extent that my suggestions are good ones (as judged by the MSC community) this might also benefit MasterCoin by making it a better product.

My main focus is on the products I want to build, and I am ambivalent about the protocol that they end up using, so long as it fulfils a long list of technical requirements that my products will need. Because of these requirements I don't think it will be possible for me to use MasterCoin in full because of two fundamental design issues: (a) balance-per-address vs balance-per-transaction-output and (b) the bitcoin/bytecount cost of requiring every MasterCoin transaction to send some bitcoin to the exodus address.

Nonetheless as I mentioned I would like to find as much common ground as possible, to make life easy for wallet developers to support both protocols, and for the purely selfish purpose of giving me a smooth transition to using MasterCoin if my protocol gains no traction and MasterCoin becomes a popular standard. One area I think with a lot of potential for agreement is the technical definition of how currency/property issues are represented, both within the blockchain, and on the web page that is referenced in the genesis/creation transaction. I would love of course for MasterCoin to adopt every other aspect of my proposal (!) but recognize that it has a different set of priorities.

So that's the background - a mixture of cooperation and competition if you like. If you are comfortable working together in this context, then great, and I would love to be involved in the MasterCoin spec. And if not, I completely understand, and I will stop bombarding you with PRs :)

Gideon

—
Reply to this email directly or view it on GitHub.

[dacoinminster]

Thanks for the email. I look forward to talking to you soon.

We're happy when people contribute to our protocol, whatever their motivations :)

[dexX7]

Hi @gidgreen, I'm following your proposal about the asset specification with much interest and I see you are trying to find a way to create multisends. I would love to hear your input about #62 (Complete seperation of data layer by removing "reference address") which I submitted to address multisends, too. The essential part: chain multiple transactions within one by using a seperator or similar.

[gidgreen]

@dexX7 - thanks for your note. I can see the benefit of what you're suggesting, but I'm afraid I can't comment much more intelligently than that. Sorry :)

[dacoinminster]

Note: the goal would be to allow multiple inputs and multiple outputs (see issue #77)

This may also involve encoding addresses as data (see issue #62)

[dacoinminster]

This pull request has conflicts, but may be a useful example for whatever we do end up putting into a new pull request, so I'm keeping it open, but as an issue.

[dexX7]

Hi,

in an attempt to clean up the current specification, I'm going to close old and outstanding pull requests. Please note, it's tagged as "old idea", so the work is not wasted and we can potentially review it at some point later.

Please feel free to resubmit it as new pull request, if you still think it's a good idea.