StarenseN
Legendary
Offline
Activity: 2478
Merit: 1362
|
|
October 24, 2013, 01:10:37 PM |
|
Awesome, love the insight. Agenda and the decisions don't match up though, kinda hard to match them right now. The Agenda is a partial list of the stuff we brought into the discussion (not everybody prepared it on the doc, and some things arose mid-discussion). I'll help with the matching: Agenda:1. We decided that the meetings are public. 2. We haven't decided on that, waiting to hear a marketing plan from Social Circle. 3. No actions items here, I just updated updated the board about our blog. We do also plan to review our Twitter & Facebook channels (David opened these a while back), I hope in the next few days. 4. Regarding Roadmap - Willett is currently managing the project, and doing a great job at it. I suggested we pour some content to our Trello and think about the long term direction, but Willett is just too occupied to do it right now, and I don't believe it's productive to "try and twist his arm about it". We might formulate a roadmap in the future, but right now the focus as I see it is on completing features, not long-term planning. 5. It was decided that bounties are paid in whatever currency the developers/bounty collectors wish. 6. I updated the board briefly about the Nxt alt currency - no action items here. Hope that helps. Ron Thanks for the update. I'm following this closely.
|
|
|
|
prophetx
Legendary
Offline
Activity: 1666
Merit: 1010
he who has the gold makes the rules
|
|
October 24, 2013, 05:05:54 PM |
|
hey Gals and Guys, I am writing the 2nd weekly newsletter tonight and if you have any suggestions to include anything from the previous week please let me know. For your reference the blog is here: http://blog.mastercoin.org/
|
|
|
|
|
|
vokain
Legendary
Offline
Activity: 1834
Merit: 1019
|
|
October 24, 2013, 05:51:47 PM |
|
hey Gals and Guys, I am writing the 2nd weekly newsletter tonight and if you have any suggestions to include anything from the previous week please let me know. For your reference the blog is here: http://blog.mastercoin.org/incredible piece prophetx! and an incredible week to all those involved
|
|
|
|
dacoinminster (OP)
Legendary
Offline
Activity: 1260
Merit: 1031
Rational Exuberance
|
|
October 24, 2013, 05:55:28 PM |
|
|
|
|
|
|
|
abuelau
|
|
October 24, 2013, 09:53:39 PM |
|
I have a probably stupid question and it has probably been answered before but I don't feel like digging 75 pages of this thread, so can someone please help me: I bought 1 mastercoin last week and sent it to a bitcoin address that already had some BTC. This is the TX: http://mastercoin-explorer.com/addresses/13gWMV4iiydqRbX1ac6wFqQhK3D58QJihdSo what happens now if I spent all the BTC in that address? Am I also going to be spending my mastercoin? Or can I spend all bitcoins and then load 0.00006 again whenever I want to send mastercoins somewhere else? I'm confused!
|
|
|
|
zathras
|
|
October 24, 2013, 10:59:37 PM |
|
Not a delay, masterchest has thrown this transaction out the same as the other one due to sequence numbers forming a perfect sequence: 15NoSD4F1ULYHGW3TK6nBN9ZC1RjkAj3cF has a sequence number of 49 15NoSD4F1ULYHGW3TKBrJy7eJq5nRSLfaH has a sequence number of 48 15HnZysUgaEGG4oz4eEmTozi3m4kxhZu15 has a sequence number of 47 The transaction is still valid though (Tachikoma & I spent some time fleshing out the semantics of what is and what isn't a valid transaction) - I'll have a code change up to masterchest.info over the weekend that will again allow perfect sequence numbers if the change address can be identified by the output amounts (this is how it originally was before output amounts started differing with multisig). I have an amendment currently being finalized and once all the other guys (Tachikoma, Grazcoin, Bitoy etc) are happy with it we'll ask JR to accept it which should help to really lock in these transaction processing rules. Thanks!
|
|
|
|
zathras
|
|
October 24, 2013, 11:01:04 PM |
|
I have a probably stupid question and it has probably been answered before but I don't feel like digging 75 pages of this thread, so can someone please help me: I bought 1 mastercoin last week and sent it to a bitcoin address that already had some BTC. This is the TX: http://mastercoin-explorer.com/addresses/13gWMV4iiydqRbX1ac6wFqQhK3D58QJihdSo what happens now if I spent all the BTC in that address? Am I also going to be spending my mastercoin? Or can I spend all bitcoins and then load 0.00006 again whenever I want to send mastercoins somewhere else? I'm confused! You can safely send BTC from your Mastercoin address, that's not a problem. You just need to ensure you have sufficient funds to cover the fees at said address at the time you wish to send Mastercoins from it.
|
|
|
|
ASICSRUS
Member
Offline
Activity: 70
Merit: 10
Expert Computer Geek
|
|
October 25, 2013, 12:06:42 AM |
|
hey Gals and Guys, I am writing the 2nd weekly newsletter tonight and if you have any suggestions to include anything from the previous week please let me know. For your reference the blog is here: http://blog.mastercoin.org/Communications Officer? ~ looking good!
|
|
|
|
maxmint
|
|
October 25, 2013, 06:41:36 AM |
|
Not a delay, masterchest has thrown this transaction out the same as the other one due to sequence numbers forming a perfect sequence: 15NoSD4F1ULYHGW3TK6nBN9ZC1RjkAj3cF has a sequence number of 49 15NoSD4F1ULYHGW3TKBrJy7eJq5nRSLfaH has a sequence number of 48 15HnZysUgaEGG4oz4eEmTozi3m4kxhZu15 has a sequence number of 47 The transaction is still valid though (Tachikoma & I spent some time fleshing out the semantics of what is and what isn't a valid transaction) - I'll have a code change up to masterchest.info over the weekend that will again allow perfect sequence numbers if the change address can be identified by the output amounts (this is how it originally was before output amounts started differing with multisig). I have an amendment currently being finalized and once all the other guys (Tachikoma, Grazcoin, Bitoy etc) are happy with it we'll ask JR to accept it which should help to really lock in these transaction processing rules. Thanks! I see, thanks for the detailed explanation! Looking forward to your code change implementation.
|
|
|
|
|
maxmint
|
|
October 25, 2013, 08:44:27 AM |
|
|
|
|
|
jiefangqian
|
|
October 25, 2013, 09:16:44 AM |
|
Thanks,very much!
|
XBC:B7jR5zX8pBpyjyrcMMiYCQyLVLC6YZjFYh
|
|
|
prophetx
Legendary
Offline
Activity: 1666
Merit: 1010
he who has the gold makes the rules
|
|
October 25, 2013, 11:31:20 AM |
|
could one of you guys comment on what this means for MSC? in layman's terms. i would like to add it to the newsletter for this week as it seems relevant and validates the MSC concept. just 2 or 3 sentences would be sufficient. https://bitcoinfoundation.org/blog/?p=290thanks in advance So, with some reluctance, I recently merged pull request #2738 : “Relay OP_RETURN data TxOut as standard transaction type.”
The idea is to give people a way to do what they clearly want to do (associate extra data with a transaction that is secured by the blockchain), but do it in a responsible way that strikes a balance between “you can put whatever you want into the blockchain” and “you will have to be tricky and inefficient to get your data in the blockchain.”
Pull request #2738 lets developers associate up to 80 bytes of arbitrary data with their transactions by adding an extra “immediately prune-able” zero-valued output.
Why 80 bytes? Because we imagine that most uses will be to hash some larger data (perhaps a contract of some sort) and then embed the hash plus maybe a little bit of metadata into the output. But it is not large enough to do something silly like embed images or tweets.
Why allow any bytes at all? Because we can’t stop people from adding one or more ordinary-looking-but-unspendable outputs to their transactions to embed arbitrary data in the blockchain.
What do I mean by “immediately prune-able?” The form of the up-to-80-byte transaction output (“OP_RETURN <data>”) is such that it can never be used as an input for another transaction– so it can theoretically be forgotten by everybody except for machines that want to keep a full record of every single transaction (“archive nodes”). That is a big improvement over the various hacks people are using today to associate data with their transactions, and will be more important in the future when we implement code that saves disk space by keeping only unspent transaction outputs and not every old block.
The core code has no easy way of creating these new transaction outputs– you have to create them yourself using the raw transactions API. And there are no plans to display the data in Bitcoin-Qt, so you don’t have to worry about somebody sending you a few millibits and attaching a short-but-annoying message to the transaction.
|
|
|
|
Tachikoma
|
|
October 25, 2013, 11:47:09 AM |
|
Basically it gives us an other way to encode Mastercoin data into the blockchain.
J.R.'s original approach was hiding the data in an Bitcoin address. The big downside to this method is that these addresses can never be spend since no private key exists. When using this method you are basically polluting the blockchain with data that can never be removed. (We call these transactions Class A)
The next solution we came up with was using multi-sig transactions. By supplying an public key that can be used when you want to spend the output we can now make sure every output we create is spendable. This stops the pollution problem. (We call these transactions Class B)
What I understand from OP_RETURN is that you can basically add 80bytes of arbitrary data to each transaction. This would give us a perfect way to encode our data in the most harmless way since these outputs are 'Provably Prune-able' and can safely be ignored when parsing the blockchain. (These transactions will most likely be Class C transactions)
I hope this explains it. If anybody spots an error let me know.
|
|
|
|
StarenseN
Legendary
Offline
Activity: 2478
Merit: 1362
|
|
October 25, 2013, 11:54:36 AM |
|
Basically it gives us an other way to encode Mastercoin data into the blockchain.
J.R.'s original approach was hiding the data in an Bitcoin address. The big downside to this method is that these addresses can never be spend since no private key exists. When using this method you are basically polluting the blockchain with data that can never be removed. (We call these transactions Class A)
The next solution we came up with was using multi-sig transactions. By supplying an public key that can be used when you want to spend the output we can now make sure every output we create is spendable. This stops the pollution problem. (We call these transactions Class B)
What I understand from OP_RETURN is that you can basically add 80bytes of arbitrary data to each transaction. This would give us a perfect way to encode our data in the most harmless way since these outputs are 'Provably Prune-able' and can safely be ignored when parsing the blockchain. (These transactions will most likely be Class C transactions)
I hope this explains it. If anybody spots an error let me know.
Thanks for these explanations (finally I understand something here ) Does it affects the transactions already been done (compatibility) ? Will we need a new way/tool to create MSC transactions ?
|
|
|
|
Tachikoma
|
|
October 25, 2013, 12:09:00 PM |
|
Only Class A transactions can be created with a normal Bitcoin client for now. Class B/C will require new applications to support them.
|
|
|
|
|