Quote from: dexX7 on March 18, 2014, 04:58:04 AM

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

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.

Quote from: dacoinminster on March 17, 2014, 03:55:23 PM

Quote from: ripper234 on March 17, 2014, 01:57:14 PM

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.