I was thinking about all this a bit more. Some of this was suggested earlier: 1. Snapshots After a specification change, a time span, a number of transactions or whatsoever the current state of the Mastercoin ecosystem should be stored in an agreed upon format. This should include all balances and may include open orders, if a snapshots is going to allow to restore a state. The correctness of a snapshot must be confirmed by several parties and finally sealed by some higher authority. The data provided by a sealed snapshot shall never be challenged and has the highest power of ruling. No user shall ever fear that a change affect the past. (note: this is always high priority and nothing new!) 2. Checkpoints Snapshots should be explicitly used to verify an application. 3. Reference documentation The specification is great, but I'm not yet sure how it could be used as some kind of reference for different versions of specific transaction types and similar. Commit numbers may be used, but I think in the best case there were some additional isolated and very short formal definitions which precisely define the different transactions at a given version and the changes made to previous ones. If I'd like to lookup something of the past, I'd probably need to invest some time for extracting all details from different places. Pseudo code or isolated reference implementation snippets may be used. Use-case and goal: "I want to lookup the policies applied prior snapshot 123.. ah, input is defined as.., only Exodus output allowed, otherwise invalid, 1-of-3 multisig, second and third multisig output is encoded data, ...". Some more lower priority stuff: 4. Define how changes are pushed Process.md describes the process of making changes to the Mastercoin specification. This document may be expanded to a more detailed "step-by-step" process guide similar to Bitcoin's release-process.md but related to sealing snapshots and pushing updates. 5. Test cases With clear implementation guidelines it may be easier to run wide scale tests. I'm not sure, if this is done at the moment, but I'm thinking about things like "scan the chain for all transactions with unordered data-packages to get an overview about what the implications were, if an order would be enforced". (I'm not good at making up examples - ) Rephrased: if a change is pushed, evaluate all consequences. Run different settings, create test-snapshots etc. 6. Transaction archival Instead of storing only a current state, historical transactions may be stored and sealed similar to snapshots, e.g.: [{
"basetx": "98419d8b3056ce50aa63d1f464555e038ae517996ac6ec13bfd8c26689f5bece",
"input": "1NqkqJkGCA7HJkBQqJrRvJCDCLAnQndw7",
"reference": "1MaStErt4XsYHPwfrN9TpgdURLhHTdMenH",
"datahex": "0000000000000001000000012a05f200"
}, {
"basetx": "cc70f686b1402d092da400f817133b07d774b3d9791564dc6efee8dbd0a54a1d",
"input": "1Foh78nqSDzrAncvTCCqtFSzz143CsGdcz",
"datahex": "00010014000000010000000023c346000000000005e69ec0020000000000003a9801"
}] |
|
|
|
|
Looks good so far, the processing was indeed much much faster. And the progress bars are awesome!
What still remains is the problem with "," and "." interpretation of balances within the balance overview which shows super high amounts.
And I tested something else what normally shouldn't happen, but this may be handled nevertheless:
I'm using different wallets and I used the MSC wallet with Masterchest, then deleted all Masterchest folders, downloaded the new GitHub version, but changed the wallet.dat inbetween. After starting the new version for some reasons the addresses from the MSC wallet were still shown under addresses, but if I try to send coins, it only shows those from the new wallet. I'm actually a bit surprised, because I deleted also the wallet.sdf etc.
|
|
|
|
What about a bounty to find the first asset listed in MSC ?
Broadcasting an asset create transaction (or any other one that is not yet "official") is something that can be handcrafted within minutes. The blueprint is there. Introducing new features into the wild is still more time consuming - and I think we should figure out why in greater detail. This begins by finalizing the specification and ends with a broad implementation on all wallets and transaction explorers to maintain consensus. It's all about not rushing things which may lead to race conditions, altered states (= balances) and minimizing further changes to the transaction type in a short timeframe right after, to name a few reasons. |
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1MESSAGE TO ALL CIPHERMINE-PT SHAREHOLDERS:CipherMine's exchange: CipherTrade.com opened it's doors to beta users and is available under: https://beta.ciphertrade.com/Trading of CIPHERMINE and CIPHERBOND shares is scheduled to start on Friday 28th March 2014. Within the next days I will release a request form to facilitate the redemption of CIPHERMINE-PT shares to CIPHERMINE shares on CipherTrade.com. The delay is caused because CipherTrade.com does not support confirmed share transfers at the very moment. You will be asked to provide the registration data of your BTC-TC account that was associated with CIPHERMINE-PT shares. This step is necessary to map your redemption request to an user in the shareholder database. Please make sure you are able to provide the following data to redeem your shares: - The e-mail address that you used on BTC-TC - The Bitcoin or Litecoin address associated with your CM-PT shares - The number of CM-PT shares you are holding - The signature to a message with the content "CipherMine" signed by your BTC or LTC address associated with CM-PT shares For instructions about message signing take a look at: https://bitcointalk.org/index.php?topic=283947.msg3233637#msg3233637You will need to be registred on CipherTrade.com before you are able to finalize the redemption process. To register on CipherTrade.com please visit: https://beta.ciphertrade.com/Please note: I'm unable to deal with any problems related CipherTrade.com or the registration process. If you face any problems, please submit your feedback in the CipherTrade thread on litecointalk.org: https://litecointalk.org/index.php?topic=7176.225After you successfully registred on CipherTrade.com, you may finalize the request and submit your e-mail address used for the registration on CipherTrade.com. Share redemption requests will be verified manually and you should receive your CIPHERMINE shares on CipherTrade.com within approximetaly 24 hours. A copy of this message was sent to the e-mail addresses provided by BTC-TC and associated to CIPHERMINE-PT shares from the e-mail account dexx at bitwatch dot co. This message is signed with my GPG key: http://bitcoin-otc.com/viewgpg.php?nick=dexX7 (fingerprint: 0xF43718054C3E7C5CFB33E8257675E31CF5719832) Another notice will be posted here on bitcointalk.org as well as forwarded via e-mail after the redemption process actually started. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQIcBAEBAgAGBQJTKzJHAAoJEHZ14xz1cZgyuAcQAKSwdFzfrnpBdsSux+b4Nfbl
4sxnrQfojOh9+Ws4wCpegyh7DSJ+e23AnprDrKCa5FWHx5WjW0mAb9wHUZhSBYrI
Rp5KWCCczsA5J2eFg95R8GRPE+VbmsmySaE8ZhxW26iKUAUGraxIOlzTH7CTdVpR
BsB4nLEYK3M7f4l/nqbh1hOn/tFS8MSTEon+Dhybqe1npcQYYsdCXVzakOyDhku4
vUy1mndAQ+0WmR+XidxuGMwBpokttbBtr07Vc6vWckNx9zdbejQv0ABQfcR2dySb
kVf86OP1qE0MPLDDrDqMyH9ITYcsYe/a0qZ8pXrhDzVkhQBkYhz6TKisoxbYS+rH
O0blTshOxYipH+e66tM9V6jocEFEzivXKhWXVCpmuVqKip8lRAMgBcMx6tVAYu43
FPRce6jgPdME1DzAzkWexj0iYCagZPVrqqaggkQ21ra07SNsaKsYpiD86j2MAld4
bew+eEoTgCklmBLy+ryy2eObCjZbZqGhFrVdy1pgg6IN///UDehWL7Y97DSO/8A0
Gd1yYdgsMlYO+ix/gAcLtBGHcCJxEdN46ukeePJ+7ADWW3MmOOOw0qrC9MIFWh/v
/c8s3CLzrwSrw7QG2AmTtYTEzBz2969kmiAo/WFu63ygxfP3u6HS4vEkfIJ9JOfK
jtadfRhU6+M9BzY1mV2a
=POEZ
-----END PGP SIGNATURE-----
|
|
|
|
Hey. I'm trying to do a simple send but am getting this error: no pubkey on blockchain. use wallet or supply Public Key from brainwallet.org
How do I rectify this?
It is a verified address I have the private key to with Msc in it.
Thanks
If you are using Bitcoin-Qt please go to "Help" - "Debug window" - "Console". Enter: "validateaddress 1youraddress" Replace "1youraddress" with the address you try to send from, don't use quotation marks. A result like this should appear: {
"isvalid" : true,
"address" : "1JmgN44N6R6RSjL5s1SUzSWGaRHU1hoi2Y",
"ismine" : true,
"isscript" : false,
"pubkey" : "02331c01471cb1f4a2d11a8746be840b10f36d27951b5355171d95100a2646a026",
"iscompressed" : true,
"account" : "Sender1"
}
Copy the "pubkey" value into the "Sender address or public key" field on masterchain.info. Clicking the "Verify" button should result in a green "OK" right of the button. If this is the case, you are good to go. If you are using another Bitcoin application, please tell and I'll try to walk you through. Edit: in 0.9 it looks like this:   |
|
|
|
As far as I know, 80 to 40 does not change much. Previously we divide data into segments of 80 bytes, now 40 bytes. Just the number of outputs doubled. What's the big deal? Only one OP-RETURN is allowed in one transaction?
Only one allowed. |
|
|
|
If this data is representative, 2:1 shouldnt be a problem. "00000000000000000000000" alone saves a lot of space
"20434e545250525459" appears three times, so just using those two as special words in a simple huffman tree you can squeeze this down a lot.
I have no idea what data is in the OP_RETURN, but I am assuming there are things that are globally common, like "0000..", maybe there are other globally common things. Put all those into a dictionary and based on the relative frequency assign a variable length bit pattern to the dictionary words. I see. 0x20434e545250525459 ("CNTRPRTY") is actually used to flag outputs as XCP data. There is no room for simple substitution, I think - "0000.." won't alway be "0000..", but the idea about compression is very interesting nevertheless. |
|
|
|
Could the info needed be compressed to fit into 40 bytes?
What sort of entropy does the typical XCP OP_RETURN data have?
Depending on the data, it might be possible to create a small customized compress/decompress function
If someone can post an example it would help me analyze this a bit more
Edit: due to the importance of this I think it would even make sense to create a custom "dictionary" of common bit patterns (hopefully there are some) in the desired OP_RETURN data. This would have to be put into the counterpartyd, but doing stuff like this might be what is needed to get 2:1 compression, then again maybe standard compression will just work, but I think some sort of custom code would have a good chance. It all depends on the type of data.
James
What do you mean by "dictionaries for common bit patterns"? To my knowledge XCP transactions use some bits to flag a data package as XCP package and some to define the transaction type, but the rest is acutal transaction field data without OP codes or whatsoever. 1c434e54525052545900000000000000000000000100000045d964b80000000000
20434e5452505254590000001e5329a91040952f00000000000000000033474f4c
20442f55534420505249434520736f757263653a207777772e7175616e646c2e63
106f6d204c6f6e646f6e20466978696e6700000000000000000000000000000000
20434e5452505254590000002800035325c3780000000002faf0800000000002fa
12f08040ae140000000000000013b0000000640000000000000000000000000000
20434e5452505254590000000a00000000000000000000000005f5e10000000000
160000000100000002540be400012c000000000000000000000000000000000000
|
|
|
|
... Say the protocol would adapt a more strict output policy (e.g. only a valid pub key of the sender + data-packages are allowed), how would you deal with historical transactions that may be affected by such a change? |
|
|
|
|
80 bytes would be better than 40 bytes, but is this amount sufficient to support all XCP transaction types?
|
|
|
|
with KNC announcement of SCRYPT ASICS and friedcat not seeing them be a worthwhile investment. with the prices of other alts and interest in scrypt asics - does asicminer not find it a good market to explore as well. with a well made scryptasic this year (possible solo mining) it could give friedcat and AM further revenue, stronger foothold in cryptocurrency, diversification and many other benefits. someone should talk to him about exploring this option again.
I rather prefer to see them crushing their competition with what they do now: push innovation (things like immersion cooling) and superior architecture. Bitcoin mining will always be about being one step ahead and that's what is giving us an edge and a leading role in the future. |
|
|
|
@dexX7 : info in docs match with this? Rated Voltage: 0.72V, recommended voltage range is 0.55V-1V
Power Consumption: 0.2J/GHash low voltage, 0.35J/GHash rated voltage Well, that's what there is related to this:  Rest is about the protocol. Here is the PLL part: PLL document:
bs decides the operating mode. When bs=0, the range of core clock frequency is
200MHz-400MHz. When bs=1, the range of core clock frequency is 375MHz-750MHz.
PD will turn to 0 whenever reset or soft_reset is triggered. The user should set PD to 1 to start
the PLL again. When configuring the PLL without reset or soft_reset, the user should first set
PD to 0 along with modifying other register bits, then set PD to 1. There is a time period of
0.2ms after PD turns to 1 and before PLL resumes working properly.
The core clock frequency is calculated as follows:
CLK_CORE=CLK_OSC*(F6:F0+1)/2.
For example, in default setting, F6:F0 =0100111(39). If the frequency of the oscillator is 20MHz,
then the frequency of the core is 20*(39+1)/2=400MHz. At least the voltage is confirmed as it seems. And this even looks like an over-delievery!  |
|
|
|
friedcat deleted this post, what does that mean? Since bitcointalk is not supporting 2FA, i hope his account isn't hacked ... this leak really looks very very detailed and professional to be a fake. IDK what is the purpose for deleting this, but hey ... we're in Bitcoinland, not everything make sense  Well, at least I can asure you that the user friedcat posted it and I actually found the post after reading about it on IRC. The spec matches by the way with the data provided in this thread, as far as I can see: https://bitcointalk.org/index.php?topic=438359.msg4816701#msg4816701 Does Google Docs leak identities? |
|
|
|
Hm. Maybe I'm doing it wrong? All multi signature outputs I tested - redeemed or not redeemed - return null. I connected to electrum.no-ip.org:50001. >> getutxoaddress("186b4abdca8cf3edcaee8b56c28be9bb481ea1d7ed62903595661118d6d548b3", 0) <--- unspent
{
"address": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
}
>> getutxoaddress("186b4abdca8cf3edcaee8b56c28be9bb481ea1d7ed62903595661118d6d548b3", 1) <--- !! unspent !!
{
"address": null
}
>> getutxoaddress("186b4abdca8cf3edcaee8b56c28be9bb481ea1d7ed62903595661118d6d548b3", 2) <--- unspent
{
"address": "11NiSNoGYomEA3ZHEN4R9ne4kwDjECsAy"
}
>> getutxoaddress("d5112c3bbc63d644f4c162704032f358cb9ba767f7e50ff818ff961a0053fe96", 0) <--- spent
{
"address": null
}
>> getutxoaddress("d5112c3bbc63d644f4c162704032f358cb9ba767f7e50ff818ff961a0053fe96", 1) <--- unspent
{
"address": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
}
>> getutxoaddress("d5112c3bbc63d644f4c162704032f358cb9ba767f7e50ff818ff961a0053fe96", 2) <--- spent
{
"address": null
}
>> getutxoaddress("d5112c3bbc63d644f4c162704032f358cb9ba767f7e50ff818ff961a0053fe96", 3) <--- spent
{
"address": null
}
>> getutxoaddress("e70f06b3ec3401f354c1397986c627a09f928bb7f05872bf7d14d28571fa736b", 0) <--- spent
{
"address": null
}
>> getutxoaddress("e70f06b3ec3401f354c1397986c627a09f928bb7f05872bf7d14d28571fa736b", 1) <--- unspent
{
"address": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
}
>> getutxoaddress("e70f06b3ec3401f354c1397986c627a09f928bb7f05872bf7d14d28571fa736b", 2) <--- spent
{
"address": null
}
>> getutxoaddress("e70f06b3ec3401f354c1397986c627a09f928bb7f05872bf7d14d28571fa736b", 3) <--- !! unspent !!
{
"address": null
}
|
|
|
|
The new commands are: 1. getaddressbalance <address> 2. getaddressunspent <address> 3. getutxoaddress <txid> <pos> Just to be sure: getutxoaddress does not work with multi signature outputs, right? |
|
|
|
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.. 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? |
|
|
|
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: 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 ... 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). 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). 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. 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. 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. 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. 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. --- 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? 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? |
|
|
|
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. |
|
|
|
|
Show Posts
