Bitcoin Forum
May 21, 2018, 09:22:33 PM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 [74] 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 ... 166 »
  Print  
Author Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address”  (Read 446750 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
dacoinminster
Legendary
*
Offline Offline

Activity: 1232
Merit: 1002


Rational Exuberance


View Profile WWW
October 24, 2013, 06:18:24 PM
 #1461

The MasterCoin Foundation just paid for our silver membership with the Bitcoin Foundation: http://blockchain.info/tx/71557a268cc1e1914a2fa5d64a49e631018689323f3d81004e5017d1a35cdb22

This expenditure was approved by the board in our recent meeting.

1526937753
Hero Member
*
Offline Offline

Posts: 1526937753

View Profile Personal Message (Offline)

Ignore
1526937753
Reply with quote  #2

1526937753
Report to moderator
1526937753
Hero Member
*
Offline Offline

Posts: 1526937753

View Profile Personal Message (Offline)

Ignore
1526937753
Reply with quote  #2

1526937753
Report to moderator
1526937753
Hero Member
*
Offline Offline

Posts: 1526937753

View Profile Personal Message (Offline)

Ignore
1526937753
Reply with quote  #2

1526937753
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1526937753
Hero Member
*
Offline Offline

Posts: 1526937753

View Profile Personal Message (Offline)

Ignore
1526937753
Reply with quote  #2

1526937753
Report to moderator
maxmint
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
October 24, 2013, 09:01:40 PM
 #1462

This transaction does not appear on Masterchest:
7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Mastercoin-explorer marks it as valid:
http://mastercoin-explorer.com/transactions/7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Is there something wrong with the transaction? Or is Masterchest delayed?

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
abuelau
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


www.coinschedule.com


View Profile
October 24, 2013, 09:53:39 PM
 #1463

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/13gWMV4iiydqRbX1ac6wFqQhK3D58QJihd

So 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!  Shocked

Know what's happening in cryptoworld: www.coinschedule.com
zathras
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
October 24, 2013, 10:59:37 PM
 #1464

This transaction does not appear on Masterchest:
7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Mastercoin-explorer marks it as valid:
http://mastercoin-explorer.com/transactions/7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Is there something wrong with the transaction? Or is Masterchest delayed?

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! Smiley


Smart Property & Distributed Exchange: Master Protocol for Bitcoin
zathras
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
October 24, 2013, 11:01:04 PM
 #1465

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/13gWMV4iiydqRbX1ac6wFqQhK3D58QJihd

So 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!  Shocked

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.

Smart Property & Distributed Exchange: Master Protocol for Bitcoin
ASICSRUS
Member
**
Offline Offline

Activity: 70
Merit: 10


Expert Computer Geek


View Profile
October 25, 2013, 12:06:42 AM
 #1466

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?  Cool ~ looking good!

✰ If You Risk Nothing, You Risk Everything | PrimeDice.com | The New Way To Roll | *Thread*

<3<3:::LOVE^YOUR^NEIGHBOR!!!:::|+i|_33+(((PLEASE)))====>Donate if you like me!~> 157YEcD4WQ9UbhZ7NSC2FpuaYfxHe3JgF2
maxmint
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
October 25, 2013, 06:41:36 AM
 #1467

This transaction does not appear on Masterchest:
7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Mastercoin-explorer marks it as valid:
http://mastercoin-explorer.com/transactions/7aa618833779c5eab099785279f4602c804d4a26382947dbccd23e1bb51e9243

Is there something wrong with the transaction? Or is Masterchest delayed?

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! Smiley



I see, thanks for the detailed explanation! Looking forward to your code change implementation.

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
jiefangqian
Full Member
***
Offline Offline

Activity: 235
Merit: 100



View Profile
October 25, 2013, 08:40:33 AM
 #1468

我发起了一个微博投票【mastercoin中文名投票】,地址 http://t.cn/zRigfVb

XBC:B7jR5zX8pBpyjyrcMMiYCQyLVLC6YZjFYh
maxmint
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500



View Profile
October 25, 2013, 08:44:27 AM
 #1469

我发起了一个微博投票【mastercoin中文名投票】,地址 http://t.cn/zRigfVb

Pseudo translation:
Quote
I launched a Mastercoin poll.

Translated link: http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fvote.weibo.com%2Fvid%3D2481174&act=url

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
jiefangqian
Full Member
***
Offline Offline

Activity: 235
Merit: 100



View Profile
October 25, 2013, 09:16:44 AM
 #1470

Thanks,very much!

XBC:B7jR5zX8pBpyjyrcMMiYCQyLVLC6YZjFYh
prophetx
Legendary
*
Offline Offline

Activity: 1400
Merit: 1000


he who has the gold makes the rules


View Profile WWW
October 25, 2013, 11:31:20 AM
 #1471

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=290

thanks in advance


Quote
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.

WINGS Beta is live - list your ICO for only 5000 WINGS at https://wings.ai - over $650 Million raised by ICOs with WINGS
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 25, 2013, 11:47:09 AM
 #1472

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.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
StarenseN
Legendary
*
Offline Offline

Activity: 1568
Merit: 1002



View Profile
October 25, 2013, 11:54:36 AM
 #1473

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 Cheesy)

Does it affects the transactions already been done (compatibility) ? Will we need a new way/tool to create MSC transactions ?
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 25, 2013, 12:09:00 PM
 #1474

Only Class A transactions can be created with a normal Bitcoin client for now. Class B/C will require new applications to support them.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
ASICSRUS
Member
**
Offline Offline

Activity: 70
Merit: 10


Expert Computer Geek


View Profile
October 25, 2013, 01:14:19 PM
 #1475

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.

if and when MSC is considered a parasite to the blockchain the whole MSC protocol can be easily "pruned" per Gavin!   Cheesy

✰ If You Risk Nothing, You Risk Everything | PrimeDice.com | The New Way To Roll | *Thread*

<3<3:::LOVE^YOUR^NEIGHBOR!!!:::|+i|_33+(((PLEASE)))====>Donate if you like me!~> 157YEcD4WQ9UbhZ7NSC2FpuaYfxHe3JgF2
murraypaul
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


View Profile
October 25, 2013, 01:31:20 PM
 #1476

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.

if and when MSC is considered a parasite to the blockchain the whole MSC protocol can be easily "pruned" per Gavin!   Cheesy

And the project can pay to host its own full archive node to make sure all transactions are kept.

BTC: 16TgAGdiTSsTWSsBDphebNJCFr1NT78xFW
SRC: scefi1XMhq91n3oF5FrE3HqddVvvCZP9KB
ASICSRUS
Member
**
Offline Offline

Activity: 70
Merit: 10


Expert Computer Geek


View Profile
October 25, 2013, 01:53:48 PM
 #1477

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.

if and when MSC is considered a parasite to the blockchain the whole MSC protocol can be easily "pruned" per Gavin!   Cheesy

And the project can pay to host its own full archive node to make sure all transactions are kept.

is that what the Bitcoin foundation membership payoff was intended to do?  Roll Eyes

✰ If You Risk Nothing, You Risk Everything | PrimeDice.com | The New Way To Roll | *Thread*

<3<3:::LOVE^YOUR^NEIGHBOR!!!:::|+i|_33+(((PLEASE)))====>Donate if you like me!~> 157YEcD4WQ9UbhZ7NSC2FpuaYfxHe3JgF2
synechist
Legendary
*
Offline Offline

Activity: 1134
Merit: 1000


To commodify ethicality is to ethicise the market


View Profile WWW
October 25, 2013, 02:51:02 PM
 #1478

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.


Hi Tachikoma

Thanks for that summary (and apologies if the following question has been covered elsewhere).

Will these new classes of transactions remove the necessity of using sendmany to make a payment?

The reason I'm asking is that I bought Mastercoins early on using a Coinbase wallet, and because Coinbase doesn't support sendmany and doesn't allow access to your private keys, they're stuck there.

Co-Founder, the Blocknet
Tachikoma
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1000



View Profile WWW
October 25, 2013, 03:25:59 PM
 #1479

You will have to get access to your private key in order for any of the other methods to work for you.

Electrum: the convenience of a web wallet, without the risks | Bytesized Seedboxes BTC/LTC supported
synechist
Legendary
*
Offline Offline

Activity: 1134
Merit: 1000


To commodify ethicality is to ethicise the market


View Profile WWW
October 25, 2013, 04:17:13 PM
 #1480

You will have to get access to your private key in order for any of the other methods to work for you.


Ok, from Coinbase's perspective, they'd have to implement these transaction classes for users, because they don't give users private keys.

I'll relay this to Olaf from Coinbase, who's been sympathetic, though unfortunately unable to get me out of this mess.

I think we should start a thread to address this issue. It would warn people about it, and help others who, like me, are victims of the decision to only support sendmany transactions - which was not made known until after the window period to initially buy Mastercoins came to an end.

To have supported this project and subsequently found that the Mastercoins I bought are locked ad infinitum is a horrible thing. Something should be done about it.

Co-Founder, the Blocknet
Pages: « 1 ... 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 [74] 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 ... 166 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!