MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 111.

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: zathras on October 01, 2013, 04:01:10 AM

Quote from: Tachikoma on October 01, 2013, 03:45:10 AM

I think you almost have it but it seems you might be using the wrong input n; I think your vout should be 0 not 1; but I might be mistaken there.

Good eye Tachikoma, vout should be 0 not 1 yep. Thanks.

Quote from: Tachikoma on October 01, 2013, 03:45:10 AM

Which Ruby version are you using currently? The script somehow thinks the builder is not included; while it certainly should be.

Code:

ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux]

Also if it helps - Ruby was installed with rvm, mastercoin-ruby installed with gem install. I'm really green on Ruby though so it could be environment related.

Hmm that should work! What actually might work better is installing the actual wallet app I made; it dumps the transaction I create in a format that bitcoind's decoderawtransaction can decode. That way you can compare the transactions in the same format (Bitcoin ruby dumps it in a different ruby format). Check the log file in ~/.mastercoin-wallet/debug.log and look for the hex string there after the json dump. You might want to comment out the line that actually relays the transaction if you don't want to actually send anything yet.

HammerFist

newbie

Activity: 42

Merit: 0

Quote from: murraypaul on October 01, 2013, 03:31:18 AM

there is no good reason to be using the Bitcoin blockchain.
The reason to use the Bitcoin blockchain is to freeload on the existing network

Obviously, the network is well established. This is a very good reason to use bitcoin. 'freeload' is a dumb word. Everyone who uses bitcoin for whatever their own purpose may be 'freeloads' the same as Mastercoin. Mastercoin pays the same transaction fees all others pay. If the load is overly burdensome, raise the fees. Mastercoin hasn't asked for a discount on fees. Mastercoin loves the bitcoin protocol. Master is a protocol layer on top of the bitcoin protocol. It relies fully on the bitcoin rules.

People against Master haven't put forth any legitimate reasons why it should be stopped. Bloat is agnostic and comes the same equally with every transaction whether Mastercoin or not. Bloat problems existed before Mastercoin. If there were no mastercoin and bitcoin became wildly popular - we'd still have a bloat problem. Mastercoin is merely the first system to come which will put a serious load on the chain. Many other uses of bitcoin could have cause an equal load. Mastercoin didn't invent the bloat problem - stop saying the solution to bloat is to exclude Mastercoin. Bitcoin foundation will find a great solution to bloat and that won't include exclusion of great systems which load the chain more than Satoshi imagined in the beginning.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: Tachikoma on October 01, 2013, 03:45:10 AM

I think you almost have it but it seems you might be using the wrong input n; I think your vout should be 0 not 1; but I might be mistaken there.

Good eye Tachikoma, vout should be 0 not 1 yep. Thanks.

Quote from: Tachikoma on October 01, 2013, 03:45:10 AM

Which Ruby version are you using currently? The script somehow thinks the builder is not included; while it certainly should be.

Code:

ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-linux]

Also if it helps - Ruby was installed with rvm, mastercoin-ruby installed with gem install. I'm really green on Ruby though so it could be environment related.

Tachikoma

hero member

Activity: 938

Merit: 1000

Quote from: zathras on October 01, 2013, 02:00:58 AM

Too... many... hours... Time to take a break...

Pleased to say I've got it sorted though - couldn't find good doco anywhere so went with reverse engineering - I now have a (what I believe to be) working method to put together multisig transaction hex from scratch... I'll do some testing and broadcast one or two after some rest

Code:

0100000001a1a7ca5f86c8c5c1bdc367570b8714a75e4800cc97de5a0f47abb208a7eabd7f0100000000ffffffff03204e0000000000001976a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac204e0000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac204e000000000000475121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a000000000000000000000000000000052ae00000000

Code:

{
    "txid" : "8734f635c103ab1362a6466c4bc4a1d206426da1abfe603e8a6985df7b197bae",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "7fbdeaa708b2ab470f5ade97cc00485ea714870b5767c3bdc1c5c8865fcaa7a1",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "",
                "hex" : ""
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.00020000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8"
                ]
            }
        },
        {
            "value" : 0.00020000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
                ]
            }
        },
        {
            "value" : 0.00020000,
            "n" : 2,
            "scriptPubKey" : {
                "asm" : "1 021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf575 020100000000000000020000000007f819a0000000000000000000000000000000 2 OP_CHECKMULTISIG",
                "hex" : "5121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a000000000000000000000000000000052ae",
                "reqSigs" : 1,
                "type" : "multisig",
                "addresses" : [
                    "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
                    "1Nb68WTMCNXQ6LbJEyJEGft3ztWwSFcWLE"
                ]
            }
        }
    ]
}

I think you almost have it but it seems you might be using the wrong input n; I think your vout should be 0 not 1; but I might be mistaken there.

Which Ruby version are you using currently? The script somehow thinks the builder is not included; while it certainly should be.

murraypaul

sr. member

Activity: 476

Merit: 250

The issue is that there is no good reason to be using the Bitcoin blockchain. All the issues that being encountered with how to encode transactions are completely unnecessary, and would be avoided, if this was an altcoin instead. Then you could design a network that exactly matched what you were trying to do, rather than the nasty hacks you are having to use instead.
The reason to use the Bitcoin blockchain is to freeload on the existing network, and avoid having to build your own infrastructure.
That is a purely pragmatic decision, and is leading to bad design.

HammerFist

newbie

Activity: 42

Merit: 0

Quote from: dacoinminster on September 30, 2013, 08:23:07 PM

I don't consider this high priority, as it seems pretty likely that reteP would recommend changes we are unwilling to make (like getting rid of MasterCoins or moving to an alt chain).

Awesome. Just because Peter is intelligent and knows bitcoin well, don't follow him into the naysayer's world. TJ Watson http://en.wikipedia.org/wiki/Thomas_J._Watson, president of IBM at the time and very well versed in computers said: "I think there is a world market for maybe five computers" - in 1943. In the early days, those near the top are largely limited by engineering constraints. When free thinkers ignore some engineering difficulties to permit a grander view - huge things can be done. We'll figure out the bloat problem - lets carry on with the big project. Willet is correct in dismissing Peter the know-it-all naysayer. Press on brave soldiers.

zathras

sr. member

Activity: 266

Merit: 250

Too... many... hours... Time to take a break...

Pleased to say I've got it sorted though - couldn't find good doco anywhere so went with reverse engineering - I now have a (what I believe to be) working method to put together multisig transaction hex from scratch... I'll do some testing and broadcast one or two after some rest

Code:

0100000001a1a7ca5f86c8c5c1bdc367570b8714a75e4800cc97de5a0f47abb208a7eabd7f0100000000ffffffff03204e0000000000001976a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac204e0000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac204e000000000000475121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a000000000000000000000000000000052ae00000000

Code:

{
   "txid" : "8734f635c103ab1362a6466c4bc4a1d206426da1abfe603e8a6985df7b197bae",
   "version" : 1,
   "locktime" : 0,
   "vin" : [
   {
   "txid" : "7fbdeaa708b2ab470f5ade97cc00485ea714870b5767c3bdc1c5c8865fcaa7a1",
   "vout" : 1,
   "scriptSig" : {
   "asm" : "",
   "hex" : ""
   },
   "sequence" : 4294967295
   }
   ],
   "vout" : [
   {
   "value" : 0.00020000,
   "n" : 0,
   "scriptPubKey" : {
   "asm" : "OP_DUP OP_HASH160 dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e OP_EQUALVERIFY OP_CHECKSIG",
   "hex" : "76a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac",
   "reqSigs" : 1,
   "type" : "pubkeyhash",
   "addresses" : [
   "1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8"
   ]
   }
   },
   {
   "value" : 0.00020000,
   "n" : 1,
   "scriptPubKey" : {
   "asm" : "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
   "hex" : "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
   "reqSigs" : 1,
   "type" : "pubkeyhash",
   "addresses" : [
   "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
   ]
   }
   },
   {
   "value" : 0.00020000,
   "n" : 2,
   "scriptPubKey" : {
   "asm" : "1 021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf575 020100000000000000020000000007f819a0000000000000000000000000000000 2 OP_CHECKMULTISIG",
   "hex" : "5121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a000000000000000000000000000000052ae",
   "reqSigs" : 1,
   "type" : "multisig",
   "addresses" : [
   "13Zh6iGo3uRdL3ACgrj4mMkNtRF9Yoj4MR",
   "1Nb68WTMCNXQ6LbJEyJEGft3ztWwSFcWLE"
   ]
   }
   }
   ]
}

jim618

legendary

Activity: 1708

Merit: 1066

Quote from: wizzardTim on September 30, 2013, 01:15:53 PM

Quote from: Tachikoma on September 30, 2013, 01:02:25 PM

If MultiBit can do 'sendmany' transactions then yes; you can use MultiBit to senyd Mastercoin transactions uses the old style transactions; although I would not suggest you do this.

I doubt it can do that.. so now that I can't use Multibit or qt(due to space restriction) you suggest me to wait for a light-wallet client to be developed?

MultiBit does not give the user the ability to do sendmany so if that is required to send MasterCoin it would not work.

It is a general issue with overlay networks in the blockchain. For instance at the Amsterdam conference one proposal for encoding colored coins was to use the order of the transaction inputs. This is 'squeezing in a sidechannel'. A client may very well create new legal transactions and transmit them that, because it does not understand the side channel, scrambles the data.

zathras

sr. member

Activity: 266

Merit: 250

Quote from: zathras on September 30, 2013, 07:37:23 PM

Update. My implementation has support for decoding multisig transactions but the way I was coming at encoding was - well let's not beat around the bush - completely wrong I'm disappointed to say.

I've gone back to basics and at least now understand where I had misunderstood things. The problem now is that it looks like bitcoind doesn't have sufficient functionality within the rawtransactions API to help me build the transaction. createrawtransaction only takes an array of addresses & values for the outputs so I believe the only thing I'm left with is building the transaction hex completely from scratch - I've burned more hours than I care to admit attempting to figure this out but I'm not making much progress.

I've gone through Tachikoma's source in an attempt to translate logic but that calls on bitcoin-ruby to build the transaction and looking through that (my ruby is non-existent) was making my eyes go square.

In a nutshell let's keep simple - note the below example vout - anyone know of a way this can be constructed using the bitcoind/qt API?

Quote

{
   "value" : 0.00012000,
   "n" : 3,
   "scriptPubKey" : {
   "asm" : "1 03e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee 020100000000000000020000000007f819a0000000000000000 2 OP_CHECKMULTISIG",
   "hex" : "512103e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee210201000 00000000000020000000007f819a000000000000000052ae",
   "reqSigs" : 1,
   "type" : "multisig",
   "addresses" : [
   "1HyC1C8oRzoEqnwZnoLRwMXUE2p1y3nsh9",
   "1Nb68WTMCNXQ6LbJEyJEGft3ztWwSFcWLE"
   ]
   }
   }

Again forgive the newbieness of the question if it comes across that way, I'm learning much of this from scratch.

Thanks!

I thought I should add some further info on my attempts to just create the raw transaction hex from scratch and see if I can get some help there (as I'm fairly confident it can't be done with the bitcoind/qt API and thus I doubt I'll get much of a response to that part).

I just can't seem to get my head around how to build it as a multisig transaction.

If we take the following transaction I've manually constructed for example:

Code:

0100000001a1a7ca5f86c8c5c1bdc367570b8714a75e4800cc97de5a0f47abb208a7eabd7f0100000000ffffffff03204e0000000000001976a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac204e0000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac204e00000000000049010121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a00000000000000000000000000000000102ae00000000

This decodes to:

Code:

{
   "txid" : "869f499746deb77019df8b9aedbaaa0fbdfb1317e0d5387c412fe3160bb89b81",
   "version" : 1,
   "locktime" : 0,
   "vin" : [
   {
   "txid" : "7fbdeaa708b2ab470f5ade97cc00485ea714870b5767c3bdc1c5c8865fcaa7a1",
   "vout" : 1,
   "scriptSig" : {
   "asm" : "",
   "hex" : ""
   },
   "sequence" : 4294967295
   }
   ],
   "vout" : [
   {
   "value" : 0.00020000,
   "n" : 0,
   "scriptPubKey" : {
   "asm" : "OP_DUP OP_HASH160 dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e OP_EQUALVERIFY OP_CHECKSIG",
   "hex" : "76a914dd84a40b985e9cb1d6cff0a3ba810fb4bf74e23e88ac",
   "reqSigs" : 1,
   "type" : "pubkeyhash",
   "addresses" : [
   "1MCHESTptvd2LnNp7wmr2sGTpRomteAkq8"
   ]
   }
   },
   {
   "value" : 0.00020000,
   "n" : 1,
   "scriptPubKey" : {
   "asm" : "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
   "hex" : "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
   "reqSigs" : 1,
   "type" : "pubkeyhash",
   "addresses" : [
   "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
   ]
   }
   },
   {
   "value" : 0.00020000,
   "n" : 2,
   "scriptPubKey" : {
   "asm" : "1 021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf575 020100000000000000020000000007f819a0000000000000000000000000000000 2 OP_CHECKMULTISIG",
   "hex" : "010121021bfc32c40f01efd61535cae8b297257e536b140ee6c727f576698e70d24cf57521020100000000000000020000000007f819a00000000000000000000000000000000102ae",
   "type" : "nonstandard"
   }
   }
   ]
}

As you can see the last vout is a nonstandard tx type (not "multisig") and has no reqSigs value. I've obviously made a mess of building the transaction hex for the multisig part (vin & the other basic vouts are easy). Would anyone care to help out and let me know where I've gone wrong?

Thanks again

EDIT: Tachikoma I can't seem to get your code running to compare our transaction hex before signing:

Code:

Getting private key and public key for Mastercoin address
Getting raw transaction data
Found raw transaction; unpacking into tx
Setting fees
Total amount available from input: 0.06968
Paying 0.0001 network fees
Taking 0.00024 out of total for each mastercoin output
Sending 0.06934 back to mastercoin address
Using public key for data: 02010000000000000002000000003b9aca00000000000000000000000000000000
./wallet.rb:90:in `build_transaction': undefined method `build_tx' for # (NoMethodError)
   from /home/user/.rvm/gems/ruby-2.0.0-p247/gems/thor-0.18.1/lib/thor/command.rb:27:in `run'
   from /home/user/.rvm/gems/ruby-2.0.0-p247/gems/thor-0.18.1/lib/thor/invocation.rb:120:in `invoke_command'
   from /home/user/.rvm/gems/ruby-2.0.0-p247/gems/thor-0.18.1/lib/thor.rb:363:in `dispatch'
   from /home/user/.rvm/gems/ruby-2.0.0-p247/gems/thor-0.18.1/lib/thor/base.rb:439:in `start'
   from ./wallet.rb:169:in `

'

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: ?? on ??

Quote from: StarenseN on September 26, 2013, 04:25:32 AM

Quote from: ?? on ??

I'd just like to bring attention to Retep's proposition at this link and Cunicula's valuable comment regarding derivatives/smart property, in case anyone didn't catch it.

https://bitcointalksearch.org/topic/offer-mastercoin-analysis-and-transaction-specification-design-299679

I really think these things need serious consideration and I'm a bit concerned with the dismissive attitude they have received. The consensus on Retep's ability and knowledge regarding Bitcoin is that of high regard from what I can tell. This seems like a potentially invaluable resource. The white paper is a good outline, but this could provide a more solid framework to build on, giving focus and direction and accelerating development. I'm sure the content of the reports can be optimized so it's effectively aligned with the projects goals, as decided by the board and community. It's at least worth negotiating, even if you don't go down that road in the end.

Regarding Cunicula's comment, is there a plan to consult someone with an economics background to be sure you're building a viable system for the smart property/derivatives? J.R., you said one of the great features of the planned smart property implementation is it's simplicity. Are you professionally qualified to claim viability of the planned design in these type of systems and markets? A well working system is as simple or complicated as it needs to be. To move forward rigidly with your plan, viability be damned because you want a "simple" design, seems like a setup for failure. I realize these aren't absolute priorities at the moment. But they will be in the (near) future and it just feels a bit flying-by-the-seat-of-your-pants with the talk about some of this.

You've laid out the basics with the white paper. Personally, I'd expect team building (probably more ad-hoc than structured for the moment, I know) so the goals for the respective parts of the project can be met effectively by those with the most suitable skills and knowledge. The coding contest and everyone doing the work they are is a great start. These considerations could be an important addition.

About that, can the board officially prononce a statement about the retep offer?

J.R. When you have a few minutes, would you care to comment on any of this? It would be appreciated.

One of my board members said he was going to reach out to reteP to get some more info, but I haven't heard anything since then. I don't consider this high priority, as it seems pretty likely that reteP would recommend changes we are unwilling to make (like getting rid of MasterCoins or moving to an alt chain).

zathras

sr. member

Activity: 266

Merit: 250

Update. My implementation has support for decoding multisig transactions but the way I was coming at encoding was - well let's not beat around the bush - completely wrong I'm disappointed to say.

I've gone back to basics and at least now understand where I had misunderstood things. The problem now is that it looks like bitcoind doesn't have sufficient functionality within the rawtransactions API to help me build the transaction. createrawtransaction only takes an array of addresses & values for the outputs so I believe the only thing I'm left with is building the transaction hex completely from scratch - I've burned more hours than I care to admit attempting to figure this out but I'm not making much progress.

I've gone through Tachikoma's source in an attempt to translate logic but that calls on bitcoin-ruby to build the transaction and looking through that (my ruby is non-existent) was making my eyes go square.

In a nutshell let's keep simple - note the below example vout - anyone know of a way this can be constructed using the bitcoind/qt API?

Quote

{
   "value" : 0.00012000,
   "n" : 3,
   "scriptPubKey" : {
   "asm" : "1 03e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee 020100000000000000020000000007f819a0000000000000000
2 OP_CHECKMULTISIG",
   "hex" : "512103e6da9c60084b43d28266243c636bcdaf4d8f17b5954e078d2dece7d4659e0dee210201000 00000000000020000000007f819a0000000000000
00052ae",
   "reqSigs" : 1,
   "type" : "multisig",
   "addresses" : [
   "1HyC1C8oRzoEqnwZnoLRwMXUE2p1y3nsh9",
   "1Nb68WTMCNXQ6LbJEyJEGft3ztWwSFcWLE"
   ]
   }
   }

Again forgive the newbieness of the question if it comes across that way, I'm learning much of this from scratch.

Thanks!

bybitcoin

hero member

Activity: 672

Merit: 500

Also for ensuring that in the off-chain network a transaction is requested by the real private key owner of that address sending the tx, though the cryptographic providence being described in off-chain methodology using SHA256 digests is enough and working, but for the sake of more transparency and security, it is possible to add the feature of having the private-key owner send to the destination address a below 54.3 micro-bitcoins transaction on the bitcoin blockchain too, to confirm his off-chain action. This micro tx sending attempt could be seen in the main bitcoin blockchain by the potential mastercoin client and be interpreted as the second confirmation that the real owner is sending the tx off-chain too. And while it works as two factor authentication, due to "dust transaction policy" the tx will be rejected and will not add anything to the bitcoin blockchain size that cause a problem.
The benefit of this scheme is that since the merkle tree, of accounts in off-cahin network, could be sent to the exudus address periodically, it is always possible to turn back to the classical-initial way of handling tx on the main bitcoin blockchain, in the case if the bitcoin devs. decide to change that dust policy or any other sensitive specs that cause our scheme become not effective.
And finally I should mention that I have been thinking on Jr.Willet's paper and my resolution for the UTXO bloat problem, during the last 15 days, just because of my love and support for this great project, and therefore I declare here that I have not any insistence about using my solution instead of any other available ones!

bybitcoin

hero member

Activity: 672

Merit: 500

What interesting people we have here in btt community Wink

bybitcoin

hero member

Activity: 672

Merit: 500

In the passage I addressed in the previous post, if we replace the side or service in debt with the tx receiver in our context and the lender with tx sender, my first post scheme can be implemented using a similar merkele-tree of accounts using modular numbers instead of tx bytes codes explained in dacoinminster's spec paper, that handles all transactions (except buying mastercoin with bitcoin) off the bitcoin blockchain.
This will apparently resolve the blockchain bloat problem effectively.
PS: also as an additional security-protection layer, it can be settled for this off-chain merkele-tree os to send a message including the list of all accounts (> 0) balances as an on-blockchain message to the exudus address every 24 hour(or any other period) once. But this one can be neglected if looks bloating the blockchain size as well (which seems not)

bybitcoin

hero member

Activity: 672

Merit: 500

Quote from: Tachikoma on September 30, 2013, 12:50:45 PM

Forgive my ignorance but could you explain what 'off blockchain script-messaging' is in this context?

The idea is better explained when we use the off-chain transaction methodology (with embedded modular numbers instead of Jr.Willet's bytes code as transactions messages, which I can explain and formulate later on) using merkele-sum trees of accounts. Here I include a passage from https://en.bitcoin.it/wiki/Off-Chain_Transactions
Auditing
In addition to hacks, currently no trusted third party payment systems in Bitcoin provide any way for users to determine if the services actually hold the Bitcoins they claim to hold. Conventionally banks and payment processors are audited regularly by third-parties - because Bitcoin is based on cryptography auditing can be done in a cryptographically provable way.
Gregory Maxwell has proposed[3] to use merkle-sum trees of accounts to audit funds held by third parties. Each account with the service is assigned a number, such as a SHA256 digest, and those digests are formed into a merkle tree. Additionally for every node in the tree the sum of the account balances on both leaves is computed, and that sum becomes part of the data hashed by the parent node. The tip of the tree is then the sum of all balances for all accounts.
The service proves they control the Bitcoins they claim to by signing statements with the private keys capable of spending transaction outputs present on the blockchain, and in addition regularly sign statements attesting what is the current tip of the account merkle-sum tree.
Clients check that their account is included in that tree by regularly demanding proof, in the form of a merkle path, that their account leads to the claimed tip. Any discrepancy is evidence of fraud on by the service, or at least poor record-keeping.

dacoinminster

legendary

Activity: 1260

Merit: 1031

Rational Exuberance

Quote from: Tachikoma on September 30, 2013, 01:17:54 PM

If you are feeling adventurous you can try out my wallet implementation; but you will need to be comfortable around a terminal for now.

Yes, we need more testers!

There's also blockchain.info - a lot of people seem to be using that. It can do sendmany, and I understand it can be fairly secure if used correctly.

Tachikoma

hero member

Activity: 938

Merit: 1000

If you are feeling adventurous you can try out my wallet implementation; but you will need to be comfortable around a terminal for now.

wizzardTim

legendary

Activity: 1708

Merit: 1000

Reality is stranger than fiction

Quote from: Tachikoma on September 30, 2013, 01:02:25 PM

If MultiBit can do 'sendmany' transactions then yes; you can use MultiBit to send Mastercoin transactions uses the old style transactions; although I would not suggest you do this.

I doubt it can do that.. so now that I can't use Multibit or qt(due to space restriction) you suggest me to wait for a light-wallet client to be developed?

Tachikoma

hero member

Activity: 938

Merit: 1000

If MultiBit can do 'sendmany' transactions then yes; you can use MultiBit to send Mastercoin transactions uses the old style transactions; although I would not suggest you do this.

wizzardTim

legendary

Activity: 1708

Merit: 1000

Reality is stranger than fiction

One newbie question: Can I send and recieve Mastercoin to/from a MultiBit BTC Wallet? Or only from a qt wallet with the full blockchain downloaded?

I'm asking because I ran out of disk space and cannot longer use the qt wallet (I would be grateful to anyone who tells me how I can use the qt-wallet to a different drive than c:/).

Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address” - page 111. (Read 448462 times)