Bitcoin Forum
August 18, 2018, 09:51:46 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 [160] 161 162 163 164 165 166 »
  Print  
Author Topic: MasterCoin: New Protocol Layer Starting From “The Exodus Address”  (Read 447297 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.
Herp
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250


View Profile
March 18, 2014, 02:11:09 AM
 #3181

No talk of smart property? Guess you haven't been paying attention http://blog.mastercoin.org/2014/03/14/development-update-9-impending-dex-launch/#more-588 What?
You for real or joking? Are you guys part of some trio of jokers doing free advertising for Counterparty in this thread? Your statement sounds surreal at best.


███████████████████████████████████████
███████████████████████████████████████
█████████████████████████████
██████████████████████████
████████████████████████
███████████████████████
█████████████████▐████
███████████████████████
████████████████████████
██████████████████████████
█████████████████████████████
███████████████████████████████████████
███████████████████████████████████████
DECENT
FOUNDATION



██
██
██
██
██
██
██
██
██

██
██
██


[D]ecentralized application
[E]liminated third parties
[C]ontent distribution



██
██
██
██
██
██
██
██
██

██
██
██


[E]ncrypted & secure
[N]o borders
[T]imeless reputation



██
██
██
██
██
██
██
██
██

██
██
██



██
██
██
██
██
██
██
██
██

██
██
██

1534629106
Hero Member
*
Offline Offline

Posts: 1534629106

View Profile Personal Message (Offline)

Ignore
1534629106
Reply with quote  #2

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

Posts: 1534629106

View Profile Personal Message (Offline)

Ignore
1534629106
Reply with quote  #2

1534629106
Report to moderator
BldSwtTrs
Legendary
*
Offline Offline

Activity: 922
Merit: 1001


View Profile
March 18, 2014, 02:16:46 AM
 #3182

No talk of smart property? Guess you haven't been paying attention http://blog.mastercoin.org/2014/03/14/development-update-9-impending-dex-launch/#more-588 What?
You for real or joking? Are you guys part of some trio of jokers doing free advertising for Counterparty in this thread? Your statement sounds surreal at best.
Chill out. I am just asking questions. That implied I know I am ignorant on the subject and have stuff to learn.
JakeThePanda
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500



View Profile
March 18, 2014, 02:26:13 AM
 #3183

No talk of smart property? Guess you haven't been paying attention http://blog.mastercoin.org/2014/03/14/development-update-9-impending-dex-launch/#more-588 What?
You for real or joking? Are you guys part of some trio of jokers doing free advertising for Counterparty in this thread? Your statement sounds surreal at best.

Usually, when one is only left with insults, the argument is lost.  For the record, I own both MSC and XCP equally.
Herp
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250


View Profile
March 18, 2014, 02:32:59 AM
 #3184


Counterparty copied nothing from MSC ...

Nothing but pretty much cloned the whole thing. Only problem is they aren't going anywhere and people who invested in them hoping they've got Santa Claus by the feet will realize this soon enough. I'm sorry for you if you sold MSC to buy Counterparty. Big mistake.

Quote
Mastercoin is going to shit, and Ethereum + Open Transactions is gonna put the nail in the coffin. Believe it.
Worth reading about the many flaws Ethereum model has http://blog.mastercoin.org/2014/02/04/should-the-master-protocol-do-scripting/

Quote
After 7 months, they still are having issues parsing transactions and getting consensus. This is a huge issue in my opinion. Also Jr controlling 30% of the coins, doesn't help. Jr even cashed out his initial 1500btc investment. So he could give two shits if it fails or not. And no stable release of a wallet after 7 months.
MSC the decentralized exchange in most advanced stage. Nothing competition has comes close.
JR sold small stake of his position to join the project full time, so stop spreading lies and bullshit. He quit his real life job to put full focus on this project. http://blog.mastercoin.org/2014/01/24/j-r-coming-full-time/

Quote
The only real person which has vested interest in Mastercoin succeeding is David Johnston because his Bitangels company invested like $5 million worth of BTC into this project.
This is another fat lie. Ever heard of this guy? https://twitter.com/brockpierce http://en.wikipedia.org/wiki/Brock_Pierce



The Mastercoin 2014 Roadmap for those interested https://trello.com/b/DzHG5qJY/roadmap


███████████████████████████████████████
███████████████████████████████████████
█████████████████████████████
██████████████████████████
████████████████████████
███████████████████████
█████████████████▐████
███████████████████████
████████████████████████
██████████████████████████
█████████████████████████████
███████████████████████████████████████
███████████████████████████████████████
DECENT
FOUNDATION



██
██
██
██
██
██
██
██
██

██
██
██


[D]ecentralized application
[E]liminated third parties
[C]ontent distribution



██
██
██
██
██
██
██
██
██

██
██
██


[E]ncrypted & secure
[N]o borders
[T]imeless reputation



██
██
██
██
██
██
██
██
██

██
██
██



██
██
██
██
██
██
██
██
██

██
██
██

Patel
Legendary
*
Offline Offline

Activity: 1284
Merit: 1000



View Profile WWW
March 18, 2014, 02:36:39 AM
 #3185


Counterparty copied nothing from MSC ...

Nothing but pretty much cloned the whole thing. Only problem is they aren't going anywhere and people who invested in them hoping they've got Santa Claus by the feet will realize this soon enough. I'm sorry for you if you sold MSC to buy Counterparty. Big mistake.

Quote
Mastercoin is going to shit, and Ethereum + Open Transactions is gonna put the nail in the coffin. Believe it.
Worth reading about the many flaws Ethereum model has http://blog.mastercoin.org/2014/02/04/should-the-master-protocol-do-scripting/

Quote
After 7 months, they still are having issues parsing transactions and getting consensus. This is a huge issue in my opinion. Also Jr controlling 30% of the coins, doesn't help. Jr even cashed out his initial 1500btc investment. So he could give two shits if it fails or not. And no stable release of a wallet after 7 months.
MSC the decentralized exchange in most advanced stage. Nothing competition has comes close.
JR sold small stake of his position to join the project full time, so stop spreading lies and bullshit. He quit his real life job to put full focus on this project. http://blog.mastercoin.org/2014/01/24/j-r-coming-full-time/

Quote
The only real person which has vested interest in Mastercoin succeeding is David Johnston because his Bitangels company invested like $5 million worth of BTC into this project.
This is another fat lie. Ever heard of this guy? https://twitter.com/brockpierce http://en.wikipedia.org/wiki/Brock_Pierce



The Mastercoin 2014 Roadmap for those interested https://trello.com/b/DzHG5qJY/roadmap


Please explain how Counterparty copied Mastercoin. You keep saying that, but what did they copy exactly? Code? No, there was none written.

The ideas behind Mastercoin still have not been fully coded, and they have with XCP.

You can bash it all you want, but XCP is still ahead right now. Mastercoin lost its first mover advantage a while back. Ethereum is going to overtake Mastercoin soon. They have many well-known, competent, developers, you can't dismiss it because it has a few flaws while its still in conceptual phase.

I would like to hear your argument about how Mastercoin can be sustainable for more users, when there are 4 different implementations with different consensus most of the time. They should have designed something like mastercoind from the start, and everyone could use 1 specific reference.
dexX7
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile WWW
March 18, 2014, 02:48:12 AM
 #3186

Every MSC transactions sends a small amount of BTC directly to J.R. Counterparty does no such thing, proving that it's completely unnecessary.

I think this is a great misunderstanding. Initially there was a huge amount of Bitcoins raised and sent to the Exodus address to create something very innovative - the Master protocol. Those coins were and are used to pay for bounties and whatsoever and controlled by the Mastercoin Foundation - whose members are those with a high stake in this game (if I'm not mistaken). This means: coins in the Exodus wallet = funds for the project itself.

The output to the Exodus address is another thing: there are several ways to tag and identify a meta-transaction, for example transactions can be created with an additional output to a specific address (Master protocol) or one could encode some magic bytes (XCP) within the data payload. Or one may use OP_RETURN with some magic bytes etc. etc. ...

But there is actually another reason: DOS protection. DOS is not yet an issue and may not be in the short term, but for the same reason that there is a DEX fee (XCP and MSC both use one) or a Bitcoin transaction fee in general, this is a filter against spam.


Re MSC vs. XCP: both projects follow different approaches, for example:

Pre-funded by the community vs. ongoing funding by donations
Coins were bought by funding the project vs. proof-of-burn
Transaction marker is an output vs. marker is encoded within the data payload
An additional transaction processing fee is raised vs. no additional transaction processing fee
Many developers and different parsing engines vs. one implementation
Only sellers in the DEX orderbook vs. buyers and sellers
...

I wouldn't say one or the other is better or worse - each approach has benefits and downsides. In the end XCP is a MSC fork and because of this there are of course great similarities, but I hope over time more differences will emerge and I'm very curious where all this leads to. Wink

Herp
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250


View Profile
March 18, 2014, 02:49:26 AM
 #3187

@Patel

You twist and bend the facts to your liking. I've just knocked out every claim you've made in your previous post. You are clearly rooting for the wrong team here and this will become very obvious to you in Q2 and Q3 of this year.

The stuff Counterparty released is something Mastercoin could have released many months ago but didn't because would have been poor quality work. Mastercoin had a trial exchange in testing for months.

You ignore the very important cash position Mastercoin has and the plethora of smart apps that will make it into the Mastercoin ecosystem in Q2 2014. http://blog.mastercoin.org/2014/03/14/development-update-9-impending-dex-launch/

MSC can work on several projects at the same time by offering multiple bounties, in effect having a very large dev team. Counterparty stands no chance to compete. Check their bounty section on website. It's empty. They can't afford any.


███████████████████████████████████████
███████████████████████████████████████
█████████████████████████████
██████████████████████████
████████████████████████
███████████████████████
█████████████████▐████
███████████████████████
████████████████████████
██████████████████████████
█████████████████████████████
███████████████████████████████████████
███████████████████████████████████████
DECENT
FOUNDATION



██
██
██
██
██
██
██
██
██

██
██
██


[D]ecentralized application
[E]liminated third parties
[C]ontent distribution



██
██
██
██
██
██
██
██
██

██
██
██


[E]ncrypted & secure
[N]o borders
[T]imeless reputation



██
██
██
██
██
██
██
██
██

██
██
██



██
██
██
██
██
██
██
██
██

██
██
██

Patel
Legendary
*
Offline Offline

Activity: 1284
Merit: 1000



View Profile WWW
March 18, 2014, 02:54:26 AM
 #3188

I guess we'll see.

Its funny how Lets Talk Bitcoin gets paid by Mastercoin's PR department to do so many segments on Mastercoin, but they are themselves releasing LTBCoin on the Counterparty protocol. Or so I have heard.
LOL
Member
**
Offline Offline

Activity: 71
Merit: 10


View Profile
March 18, 2014, 03:02:23 AM
 #3189


Actually the multi sig output does include your public key, but in a compressed form, if I'm not mistaken?

See for example:

204e02988b1a7262d90168dfe4574a69b3ab6617dddfc3737e6a296ec4d17b8f:

Input:

Quote
30450221009040ffa1b6ad045d2e6392b53c13e2f10a1b3780a9d25605e20380631c8818b402203 8a03dea5ed01e5a27c27cacbcb2908861a8078293d10d7ed8d2704e95efda8801 04cb53028bef9d48860842d17e86174fd65c913494d148c335bb17a6551a4bcb14d56eccb4cd4ac184b60cd71d1cf83b70ddf5e23198325c6036e06033c5d1d594

Output:

Quote
OP_1 02cb53028bef9d48860842d17e86174fd65c913494d148c335bb17a6551a4bcb14 0225af43e566399b7429bb01463fb69666bb3b24609b6d736bb64327143d655805 OP_2 OP_CHECKMULTISIG

For the sake of clarification:

  • If the sending address has a compressed public key, will any mastercoin client broadcast a transaction with a multisig output that can be spent by the address with the corresponding uncompressed public key?
  • Do any bitcoin or mastercoin clients recognize a Class B transaction multisig output as one that can be spent? i.e. Do the outputs add to the displayed balance, and will the client spend that output?
  • The mastercoin spec says, "It is envisaged that in future Master Protocol clients will 'clean up' periodically by redeeming and consolidating unspent multisig outputs." If the sending address has an uncompressed public key, is it speculated that the mastercoin client will also 'clean up' multisig outputs sent to the address with the corresponding compressed public key and vice versa?
  • The mastercoin spec states that a Class B transaction must satisfy the following: "Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address." Does this imply that only addresses with compressed public keys can generate valid Class B transactions? A Class B transaction sent from an address with an uncompressed public key that has a multisig output to the associated compressed public key does not produce an output that can be spend by the senders address.
  • Is a Class B transaction valid if the multisig output is to an uncompressed public key?
  • Is a Class B transaction valid if the sending address has an uncompressed public key and the multisig output is the corresponding compressed public key? And vice versa?
  • Given that the multisig outputs are very small, is it generally understood and recognized that these outputs are not accounted for in (most??) clients, and will not be spent except by manually generating, signing and broadcasting the transaction?
  • With the understanding that Class A transactions have been depreciated because they produce unspendable outputs, is there a plan to educate and assist the mastercoin community in spending Class B multisig outputs that would have been unspendable if produced by a Class A transaction?
  • When mastercoin transitions to Class C transactions, using the script OP_RETURN for data storage, will there be an effort as a community to spend the multisig outputs from Class B transactions?

You'll have to forgive my questions. However it's not clear to me exactly what defines a valid Class B transaction given that my address has consensus across mastercoin implementations despite having broadcast Class B transactions that should not be valid according to the mastercoin specification.

I recognize that I may be very far out of the loop on this, however I feel that it's irresponsible to implement Class B transactions as a solution to the bloat caused by Class A transactions without an active effort to ensure that those multisig outputs are spent. The issue is exacerbated by the fact that the mastercoin clients are 1.) sending multisig outputs to a compressed public key while the sending address has an uncompressed public key, and 2.) sending multisig outputs to uncompressed public keys (which directly violates the mastercoin spec). I recognize that multisig outputs can be spent, but I don't think they will be spent unless people made aware of the problem, and encouraged to spend them.
Herp
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250


View Profile
March 18, 2014, 03:04:15 AM
 #3190

I guess we'll see.

Its funny how Lets Talk Bitcoin gets paid by Mastercoin's PR department to do so many segments on Mastercoin, but they are themselves releasing LTBCoin on the Counterparty protocol. Or so I have heard.

LTBCoin is probably only smart contract that brings bit of hope to Counterparty. I have, though, some reservations but I won't go into details. Suffice to say it might not end up on Counterparty entirely. Adam Levine is thinking of spreading it out over other 2.0s like Mastercoin (he said so in his last live video chat). I won't be surprised it won't make it on Counterparty at all, as Mastercoin's advantage becomes more obvious.

Mastercoin will have dozen of them in Q2-Q3 ranging from decentralized "dropbox" type app to 3rd layer coins. Adam Levine, LTB owner, is working with Mastercoin on GoxCoin. This will be one of the Mastercoin 3rd layer coins. http://www.humint.is/goxcoin/

Quote
David Johnston
Mastercoin Foundation

Adam B. Levine
Let's Talk Bitcoin!
/ Humint

Wendell Davis
Humint & Hive

Peter C. Earle
Humint & FINAGEM

Adam Levine doesn't get paid by Mastercoin PR department. You are probably confusing it with Next, which buys LTB ads on regular basis.


███████████████████████████████████████
███████████████████████████████████████
█████████████████████████████
██████████████████████████
████████████████████████
███████████████████████
█████████████████▐████
███████████████████████
████████████████████████
██████████████████████████
█████████████████████████████
███████████████████████████████████████
███████████████████████████████████████
DECENT
FOUNDATION



██
██
██
██
██
██
██
██
██

██
██
██


[D]ecentralized application
[E]liminated third parties
[C]ontent distribution



██
██
██
██
██
██
██
██
██

██
██
██


[E]ncrypted & secure
[N]o borders
[T]imeless reputation



██
██
██
██
██
██
██
██
██

██
██
██



██
██
██
██
██
██
██
██
██

██
██
██

romerun
Legendary
*
Offline Offline

Activity: 1078
Merit: 1001


Bitcoin is new, makes sense to hodl.


View Profile
March 18, 2014, 03:09:32 AM
 #3191

as a btc holder I'm glade XCP exists. Without direct competition, MSC team would even be relax and slower than they already are. NXT crap / Ether / Emunie / Skycoin and what not are eying add features that Bitcoin lacks.
zbx
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
March 18, 2014, 03:34:40 AM
 #3192

And what about smart contracts and smart properties?
Mastercoin guys spoke about theses a lot in the early days, but not anymore. Does that mean they have abandonned the idea?
I have not heard Counterparty guys speaking about smart contracts and smart properties, does that mean there is not plan to implement them even in the mid-long term?

'Smart property' isn't really something that Mastercoin, or Counterparty, has anything to do with directly. The Mastercoin Project just loves throwing around such buzzwords. 'Smart property' is hardware (like a car) that might itself, for instance, parse Bitcoin, or Mastercoin, or Counterparty transactions, and behave differently depending on what it sees (e.g. unlock itself only for someone with a particular private key). The only real prerequisite technology at the protocol level is virtual assets, which Counterparty has totally working and Mastercoin hasn't even begun to implement.

A 'smart contract' is a more general idea, and really applies to any contract enforced by a protocol. Bitcoin, Mastercoin and Counterparty all have these to varying degrees. Counterparty undeniably has the most sophisticated and diverse smart contracts at the moment, though. The only smart contracts implemented in Mastercoin that I know of are those of its mostly-still-in-the-planning-stages distributed exchange.
zbx
Member
**
Offline Offline

Activity: 64
Merit: 10


View Profile
March 18, 2014, 03:43:44 AM
 #3193

Every MSC transactions sends a small amount of BTC directly to J.R. Counterparty does no such thing, proving that it's completely unnecessary.
The output to the Exodus address is another thing: there are several ways to tag and identify a meta-transaction, for example transactions can be created with an additional output to a specific address (Master protocol) or one could encode some magic bytes (XCP) within the data payload. Or one may use OP_RETURN with some magic bytes etc. etc. ...

But there is actually another reason: DOS protection. DOS is not yet an issue and may not be in the short term, but for the same reason that there is a DEX fee (XCP and MSC both use one) or a Bitcoin transaction fee in general, this is a filter against spam.

Magic bytes in the payload is just simply a much better way of identifying transactions. It's cheaper, it's truly decentralised, and it doesn't send J.R. any of your money for bogus hand-wavy reasons like "DOS protection", which Bitcoin obviously handles itself through standard BTC TX fees.

What if someone steals the private key to the Exodus address from J.R.? What if he loses it? Why take the chance?
dexX7
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile WWW
March 18, 2014, 04:58:04 AM
 #3194

For the sake of clarification: (...)

Great you ask. This topic was recently discussed in the dev thread. I'll try to say something to each point:

Quote
If the sending address has a compressed public key, will any mastercoin client broadcast a transaction with a multisig output that can be spent by the address with the corresponding uncompressed public key?

Masterchain.info doesn't compress the key; the Masterchest wallet does currently compress the public key - with the intention of saving space and creating smaller transactions. Zathras (Masterchest creator) recently mentioned he may drop the compression, because this may confuse the user. What do you think about this?

Compressed or uncompressed - both share the same private key and are both redeemable by the owner. In neither of those cases any coins will be lost, but ...

Quote
Do any bitcoin or mastercoin clients recognize a Class B transaction multisig output as one that can be spent? i.e. Do the outputs add to the displayed balance, and will the client spend that output?

Bitcoin-Qt/bitcoind is not able to recognize multi signature inputs as spendable and to my best knowledge there is no (graphical) client available that is capable of doing so. This means those inputs are neither added to the balance or even shown at all. I'm not sure about the input selection of masterchain.info which uses libbitcoin as backend, but the Masterchest wallet currently relies on the input selection by bitcoind via RPC and thus does not spend those outputs. Spending those is nevertheless possible, if raw transactions are handcrafted and I'm very, very sure that the wallets will soon be able to do so. - It's not really dark magic, but rather low priority at the moment, I guess. This is also possible via RPC and all it needs is some logic to find those unspent outputs.

If you like, send me a PM with your address(es) or transactions and I'll fire up my custom dust collector that I'm using for the faucet (example transaction).

Quote
The mastercoin spec says, "It is envisaged that in future Master Protocol clients will 'clean up' periodically by redeeming and consolidating unspent multisig outputs." If the sending address has an uncompressed public key, is it speculated that the mastercoin client will also 'clean up' multisig outputs sent to the address with the corresponding compressed public key and vice versa?

As mentioned, compressed or uncompressed doesn't really matter - both should be redeemable. I think the way to go in the future is to have an intelligent input selection that redeems some of that dust whenever there is some space left to the next fee level (currently 0.0001 BTC per 1 KB, up rounded).

Quote
The mastercoin spec states that a Class B transaction must satisfy the following: "Has one or more 1-of-n OP_CHECKMULTISIG outputs each containing at least two compressed public keys, one of which must be the senders address." Does this imply that only addresses with compressed public keys can generate valid Class B transactions? A Class B transaction sent from an address with an uncompressed public key that has a multisig output to the associated compressed public key does not produce an output that can be spend by the senders address.
Is a Class B transaction valid if the multisig output is to an uncompressed public key?
Is a Class B transaction valid if the sending address has an uncompressed public key and the multisig output is the corresponding compressed public key? And vice versa?

All cases are considered as valid by the three implementations and it appears that the spec is currently worded too strict. Changes were proposed (also related) to cover those scenarios more accurately, but the final wording is not yet finalized. No historical transaction or balance will be affected due to this. Baseline: transactions should include the input public key - either compressed or uncompressed - for redemption purposes, but are not enforced to.

Quote
Given that the multisig outputs are very small, is it generally understood and recognized that these outputs are not accounted for in (most??) clients, and will not be spent except by manually generating, signing and broadcasting the transaction?

Correct.

Quote
With the understanding that Class A transactions have been depreciated because they produce unspendable outputs, is there a plan to educate and assist the mastercoin community in spending Class B multisig outputs that would have been unspendable if produced by a Class A transaction?

This will be addressed, that's for sure. At the same time I think this is something the user shouldn't care about, but rather a problem for the wallet to solve under the hood. What is your opinion about this? Would you prefer low-level control of inputs or maybe even a dedicated app to collect dust? Input on this is very welcome.

Quote
When mastercoin transitions to Class C transactions, using the script OP_RETURN for data storage, will there be an effort as a community to spend the multisig outputs from Class B transactions?

With Bitcoin 0.9 OP_RETURN transactions will be considered as standard transactions, but very recently the allowed payload size was reduced to 40 byte. If this is final, the size won't be enough for all Mastercoin transaction types and I tend to favor the data encoding within multi signature outputs. - They are widely accepted, redeemable, don't consume much more size and also very important in my opinion: very, very long payloads are possible.


Quote
You'll have to forgive my questions. However it's not clear to me exactly what defines a valid Class B transaction given that my address has consensus across mastercoin implementations despite having broadcast Class B transactions that should not be valid according to the mastercoin specification.

I recognize that I may be very far out of the loop on this, however I feel that it's irresponsible to implement Class B transactions as a solution to the bloat caused by Class A transactions without an active effort to ensure that those multisig outputs are spent. The issue is exacerbated by the fact that the mastercoin clients are 1.) sending multisig outputs to a compressed public key while the sending address has an uncompressed public key, and 2.) sending multisig outputs to uncompressed public keys (which directly violates the mastercoin spec). I recognize that multisig outputs can be spent, but I don't think they will be spent unless people made aware of the problem, and encouraged to spend them.

In general the spec is defined first and implementation comes next, but I noticed over the last weeks that this is more an iterative process. In some very rare cases like this one the implementations are ahead of the spec, because, as you mentioned, if there is no one who actually notices this and raises his voice, such "conflicts" appear which require additional adjustments.

(TL;TR:) There is no bloat and transactions are created in a way that dust outputs are spendable, but due to the general inability of Bitcoin clients to deal properly with multi signature outputs, the current Mastercoin wallets don't redeem them yet. This will change and thanks to posts like yours this may happen rather sooner than later. Smiley

---

Magic bytes in the payload is just simply a much better way of identifying transactions. It's cheaper, it's truly decentralised, and it doesn't send J.R. any of your money for bogus hand-wavy reasons like "DOS protection", which Bitcoin obviously handles itself through standard BTC TX fees.

What if someone steals the private key to the Exodus address from J.R.? What if he loses it? Why take the chance?

It doesn't matter, if someone has access to the Exodus address in the context of identifying transactions nor does the identification mechanism has any implications related to (de-) centralization.

Agreed, in terms of transaction costs the approach of magic bytes makes XCP transactions cheaper for the user. If it's much better? Well, I think that's rather a matter of personal opinion than something that can be generalized. All you can represent is your opinion and it seems I have a different one. This is probably the reason why you stick to XCP and I primarily prefer MSC. The trade off was already outlined: cheaper transactions vs. resilience and contributing to further improvements. And I'll bite: what happens, if a XCP bounty fund raiser loses the private key to the bounty wallet? Wink

I'm not 100 % sure what you are addressing right now - that there is an output to the Exodus address or that JR holds the keys to the coins that were raised to fund Mastercoin?

BitThink
Legendary
*
Offline Offline

Activity: 882
Merit: 1000



View Profile
March 18, 2014, 05:06:32 AM
 #3195

Nobody comments on why Tachikoma and his friend went to Etherium just a month after he agreed to work full time for Mastercoin? Nobody cares who is working on the reference implementation of mastercoind now? Why people keeps believing or wishing but never really ask these kind of important questions? Trying to prove mastercoin is better than counterpary, Etherium, or whatever else does not help anything. We, the investors of MSC, should keep asking questions to JR, Ron about the current status and the real reason why the 2/3 of full time developers (they spent so much time in hiring them in the first space) leave.

LOL
Member
**
Offline Offline

Activity: 71
Merit: 10


View Profile
March 18, 2014, 09:05:44 AM
 #3196

(TL;TR:) There is no bloat and transactions are created in a way that dust outputs are spendable, but due to the general inability of Bitcoin clients to deal properly with multi signature outputs, the current Mastercoin wallets don't redeem them yet. This will change and thanks to posts like yours this may happen rather sooner than later. Smiley

I appreciate the response.

Quote
Masterchain.info doesn't compress the key; the Masterchest wallet does currently compress the public key - with the intention of saving space and creating smaller transactions. Zathras (Masterchest creator) recently mentioned he may drop the compression, because this may confuse the user. What do you think about this?

The "to sender" multisig output should be defined as one of the following in the mastercoin specification:

  • Spendable by the address with a compressed public key and a private key in common with the sending address.
  • Spendable by the address with an uncompressed public key and a private key in common with the sending address.
  • Spendable by the sending address.
  • Spendable by the address with a public key opposite that of the sending address (i.e. if sending address is compressed, uncompressed; if uncompressed, compressed), and a private key in common with the sending address.

It doesn't matter which, however it needs to specified and implemented. If the specification happens to make sense, user confusion should be reduced to a minimum. My vote is "Spendable by the sending address." It's a more difficult implementation, but it makes sense.

Quote
Compressed or uncompressed - both share the same private key and are both redeemable by the owner. In neither of those cases any coins will be lost, but ...

Share a private key, yes, however do not have same WIF private key, public key, or address. If some mastercoin outputs are spendable by a compressed address, and other outputs are spendable by the corresponding uncompressed address, then both should be represented in the wallet and identified as such.

The implication of a client automatically receiving/signing transactions for both the compressed and uncompressed versions of the key pair is that the mastercoin 'unit of identification' is a private key, and thus two key pairs. This isn't compatible with any other client that I'm aware of, can be a privacy leak, and security risk if one of the WIF private keys is compromised.

Quote
As mentioned, compressed or uncompressed doesn't really matter - both should be redeemable. I think the way to go in the future is to have an intelligent input selection that redeems some of that dust whenever there is some space left to the next fee level (currently 0.0001 BTC per 1 KB, up rounded).

I agree with intelligent input selection, however I'd not be inclined to use a wallet that treats two key pairs interchangeably, especially if both pairs were not represented and identified as such.

Quote
This will be addressed, that's for sure. At the same time I think this is something the user shouldn't care about, but rather a problem for the wallet to solve under the hood. What is your opinion about this? Would you prefer low-level control of inputs or maybe even a dedicated app to collect dust? Input on this is very welcome.

I agree, should be solved under the hood - provided that only one key pair from a given private key is used (unless of course the user imports the key pair of the other format, in which case they should still be treated as separate "entities"). Dust is a pain to deal with. The more obstacle there is to spending it the less likely it is to be spent.

Quote
With Bitcoin 0.9 OP_RETURN transactions will be considered as standard transactions, but very recently the allowed payload size was reduced to 40 byte (https://github.com/bitcoin/bitcoin/pull/3737). If this is final, the size won't be enough for all Mastercoin transaction types and I tend to favor the data encoding within multi signature outputs. - They are widely accepted, redeemable, don't consume much more size and also very important in my opinion: very, very long payloads are possible.

The depreciation of Class A transactions eliminates unspendable outputs. The implementation of Class B transactions is only marginally better, IMO, because the incentive to make multisig outputs spendable is not worth the time involved - especially for those less bitcoin/mastercoin savvy. I see Class B transactions as a great transition to Class C transactions - but if Class B transactions are not depreciated, and multisig output dust is not properly handled, the implementation of Class B transactions does little to address the intent behind eliminating unspendable outputs. Sure, it technically does not create unspendable outputs, however it's a cop out to say that Class B transactions address the concern of blockchain bloat due data storage. Others may disagree, but as far as I'm concerned if outputs of a transaction are not recognized, cannot be spent, or are otherwise not used in transactions when reasonable, they will not be spent and are subject to loss due to perceived lack of value or understanding.


J.R can comment his perspective on this. Here is mine:

We have a bit of a mixup here. On the one hand, I do believe that the "High bar for usability" goal has not been met, and doubt it will be met this month.
On the other hand, we moved to paying out monthly bounties in February, and .

I hope it is clear that the DEx bounties paid in Feb, and the March monthly bounty, count towards the 300 BTC bounty (out of which 150 BTC has been previously paid).
So after March I don't think that a lot of money will remain in the original 300 BTC money pool (J.R needs to reply with some numbers).
I expect the bulk of the money remaining from the DEx to be divided in March's monthly payout.

Perhaps if there is only a tiny amount left after that, we will decide to increase March's payout and pay out the full remainder of the 300 BTC bounty this month, in order to avoid the accounting/judging headache. We will wait for J.R's number regarding February's payout (due any day now), and see what makes sense.


Yup. February numbers are nearly ready. They are my top priority once I catch up on urgent emails.

edit: I think we are close on usability. If we spend the next couple weeks fixing things that make the various wallets hard to use and trade with, I don't see any barrier to finishing the payout at the end of March.

I do not think that it is by any means reasonable to think that a client is close to a "high bar for usability" if it doesn't recognize the outputs of a transaction it created, signed and broadcast, cannot spend unspent outputs which it is (cryptographically) capable, and creates multisig outputs that cannot be spent by a key pair in the wallet - let alone the fact that there are only native Windows clients, and those with other OSes must manually handle WIF private keys in order to use the web wallet.

I've been pretty jazzed about mastercoin, however recently it seems esoteric, loose, and out of touch with the user. I bought at exodus last year, I was one of the first to attempt decentralized trades back in mid November, and I was one of the first to succeed on the 15th. Yes, it's groundbreaking, and yes, trades can be made. But mastercoin doesn't have a specification that describes current implementation, the clients privilege Windows users, and the depth of understanding in bitcoin required to spend Class B outputs (i.e. not bloat the blockchain) is a great bar to entry.
Herp
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250


View Profile
March 18, 2014, 10:15:40 AM
 #3197

Nobody comments on why Tachikoma and his friend went to Etherium just a month after he agreed to work full time for Mastercoin? Nobody cares who is working on the reference implementation of mastercoind now? Why people keeps believing or wishing but never really ask these kind of important questions? Trying to prove mastercoin is better than counterpary, Etherium, or whatever else does not help anything. We, the investors of MSC, should keep asking questions to JR, Ron about the current status and the real reason why the 2/3 of full time developers (they spent so much time in hiring them in the first space) leave.



It's dynamic new area and expect movements and shifts to occur, especially as everyone wants a bigger slice of the pie. Greed is a big component here.

Keep in mind that Charles Hoskinson from Ethereum was sacked by Protoshares due to some kind of disagreement and decided to start Ethereum. We don't know the details and what happened exactly. This is what he told me in a pm January 3rd before actually announcing Ethereum: According to his own words, Invictus fired him. So Ethereum project came to life after Charles got the boot from Invictus.

Ethereum got some initial hype and press time due to their hyped presence at the Miami convention and might have drew in few people. Suffice to say Vitalik tried to have his way with Mastercoin, by creating a scripting language but that proposition carried way too much risk to be considered. There is a reason why Bitcoin doesn't do script. This is one of the areas where Charles didn't see eye to eye with Protoshares team. Invictus (Protoshares) saw the downsides of a scripting language, which can be huge and can delay a successful implementation by years, yes YEARs. Why do you think Ethereum is set to launch Q4 only if all goes well? That's a big if. Ethereum wants to be some kind of Java and Java developers to this date keep patching it up to fix many security issues. Sure, might work with random stuff apps but it's a major pain when there are financial assets and sensitive data involved. Everyone should read this article http://blog.mastercoin.org/2014/02/04/should-the-master-protocol-do-scripting/

Tachikoma was working on Linux wallet. Not the most high priority item at this point.  


███████████████████████████████████████
███████████████████████████████████████
█████████████████████████████
██████████████████████████
████████████████████████
███████████████████████
█████████████████▐████
███████████████████████
████████████████████████
██████████████████████████
█████████████████████████████
███████████████████████████████████████
███████████████████████████████████████
DECENT
FOUNDATION



██
██
██
██
██
██
██
██
██

██
██
██


[D]ecentralized application
[E]liminated third parties
[C]ontent distribution



██
██
██
██
██
██
██
██
██

██
██
██


[E]ncrypted & secure
[N]o borders
[T]imeless reputation



██
██
██
██
██
██
██
██
██

██
██
██



██
██
██
██
██
██
██
██
██

██
██
██

marcelus
Sr. Member
****
Offline Offline

Activity: 297
Merit: 250


View Profile
March 18, 2014, 10:27:09 AM
 #3198

And what about smart contracts and smart properties?
Mastercoin guys spoke about theses a lot in the early days, but not anymore. Does that mean they have abandonned the idea?
I have not heard Counterparty guys speaking about smart contracts and smart properties, does that mean there is not plan to implement them even in the mid-long term?

'Smart property' isn't really something that Mastercoin, or Counterparty, has anything to do with directly. The Mastercoin Project just loves throwing around such buzzwords. 'Smart property' is hardware (like a car) that might itself, for instance, parse Bitcoin, or Mastercoin, or Counterparty transactions, and behave differently depending on what it sees (e.g. unlock itself only for someone with a particular private key). The only real prerequisite technology at the protocol level is virtual assets, which Counterparty has totally working and Mastercoin hasn't even begun to implement.

A 'smart contract' is a more general idea, and really applies to any contract enforced by a protocol. Bitcoin, Mastercoin and Counterparty all have these to varying degrees. Counterparty undeniably has the most sophisticated and diverse smart contracts at the moment, though. The only smart contracts implemented in Mastercoin that I know of are those of its mostly-still-in-the-planning-stages distributed exchange.

You're using Mike Hearn's narrow definition of smart property. It has become a far more general term that encompasses deeds, titles and shares.
dexX7
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile WWW
March 18, 2014, 12:47:45 PM
 #3199

The "to sender" multisig output should be defined as one of the following ...

This is how I'd formalize a class B transaction:

  • has an pay-to-pubkeyhash-output to the Exodus address.
     
  • has an "input reference" which is a public key within the input script sig whereby multiple inputs are allowed, if they all originate from the same public key. This allows parsing on an atomic level. The spec further allows to add different inputs and choses the one with the highest summed value. This comes for the cost of the need of fetching all input transactions in the worst case, but allows more freedom on the other hand.
     
  • has valid Mastercoin transaction data encoded with the "input reference" within multi signature output(s). As far as I know the current implementations parse and identify data-packages in the following way: [don't care] [data package #1] (optional: data package #2).

    I'd generalize the choice of data-packages to something like "treat several outputs as a stream of potential data-packages and chain the longest sequences of MSC data-packages within transaction's output with ascending sequence numbers, starting from 01" (see an example here). No generalization is needed, if the data-package length is less than 61 byte which is currently the case for all accepted MSC transactions.
     
  • has an "reference output" where the transaction requires such reference which is a pay-to-pubkeyhash-output not to the Exodus address, a data package or any form of the "input reference".
     
  • all output values are >= dust threshold.
     

My wording is probably fishy.. Grin but let me summarize how I think about this: as long as there is no ambigiousness (which shouldn't be the case) this explicitly allows to not include any form of sender's public key. This is of course not desired in most cases due to potential redemption, but I think the lack of the sender's public key shouldn't render the transaction as invalid to allow all forms of compression, faulty public keys and odd cases where the multi sig output may be redeemable by the user, but not by the "input reference" - without any further need of verification or checks. Keeping it a) as simple as possible while b) being as open and general as possible is what I would aim for to not create artificial limitations that may be hindering in the future.

Share a private key, yes, however do not have same WIF private key, public key, or address. If some mastercoin outputs are spendable by a compressed address, and other outputs are spendable by the corresponding uncompressed address, then both should be represented in the wallet and identified as such.

The implication of a client automatically receiving/signing transactions for both the compressed and uncompressed versions of the key pair is that the mastercoin 'unit of identification' is a private key, and thus two key pairs. This isn't compatible with any other client that I'm aware of, can be a privacy leak, and security risk if one of the WIF private keys is compromised.

I agree with intelligent input selection, however I'd not be inclined to use a wallet that treats two key pairs interchangeably, especially if both pairs were not represented and identified as such.

Agreed. Forced compression does probably more harm than good.

I see Class B transactions as a great transition to Class C transactions - but if Class B transactions are not depreciated, and multisig output dust is not properly handled, the implementation of Class B transactions does little to address the intent behind eliminating unspendable outputs. Sure, it technically does not create unspendable outputs, however it's a cop out to say that Class B transactions address the concern of blockchain bloat due data storage. Others may disagree, but as far as I'm concerned if outputs of a transaction are not recognized, cannot be spent, or are otherwise not used in transactions when reasonable, they will not be spent and are subject to loss due to perceived lack of value or understanding.

Well, I'd say those are two different issues. One is the actual encoding and the other one is the redemption of multi signature outputs. I agree that OP_RETURN data-packages would be nicer, but I currently don't see how 40 bytes could be enough to store the data.

I've been pretty jazzed about mastercoin, however recently it seems esoteric, loose, and out of touch with the user. I bought at exodus last year, I was one of the first to attempt decentralized trades back in mid November, and I was one of the first to succeed on the 15th. Yes, it's groundbreaking, and yes, trades can be made. But mastercoin doesn't have a specification that describes current implementation, the clients privilege Windows users, and the depth of understanding in bitcoin required to spend Class B outputs (i.e. not bloat the blockchain) is a great bar to entry.

Good thing then that you raised this point. I think this kind of feedback is crucial and should be very welcomed.

This all is pretty technical, so I suggest to continue in the dev thread maybe? Smiley

donut
Sr. Member
****
Offline Offline

Activity: 245
Merit: 250


View Profile
March 18, 2014, 01:22:45 PM
 #3200

And what about smart contracts and smart properties?
Mastercoin guys spoke about theses a lot in the early days, but not anymore. Does that mean they have abandonned the idea?
I have not heard Counterparty guys speaking about smart contracts and smart properties, does that mean there is not plan to implement them even in the mid-long term?

'Smart property' isn't really something that Mastercoin, or Counterparty, has anything to do with directly. The Mastercoin Project just loves throwing around such buzzwords. 'Smart property' is hardware (like a car) that might itself, for instance, parse Bitcoin, or Mastercoin, or Counterparty transactions, and behave differently depending on what it sees (e.g. unlock itself only for someone with a particular private key). The only real prerequisite technology at the protocol level is virtual assets, which Counterparty has totally working and Mastercoin hasn't even begun to implement.

A 'smart contract' is a more general idea, and really applies to any contract enforced by a protocol. Bitcoin, Mastercoin and Counterparty all have these to varying degrees. Counterparty undeniably has the most sophisticated and diverse smart contracts at the moment, though. The only smart contracts implemented in Mastercoin that I know of are those of its mostly-still-in-the-planning-stages distributed exchange.

You're using Mike Hearn's narrow definition of smart property. It has become a far more general term that encompasses deeds, titles and shares.

In that case "smart property" is a misnomer, as that implies that the property itself is somehow "smart", like "smartphone".

"Digital proof of ownership", perhaps.
Pages: « 1 ... 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 [160] 161 162 163 164 165 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!