Optionally restrict a token to a set of addresses

[dacoinminster]

Numerous projects want this feature to try to comply with KYC/AML laws. This is my first cut at creating a list of addresses, and referring to the list when creating a property such that the property is restricted to being used only by addresses on the list.

[dexX7]

Very interesting. A sort of similar topic made me wonder some time ago, when it was asked for to restrict send-to-owners to a set of receivers which are not all holders of a property (to exclude cold storage depots with many tokens).

My initial idea was to tag entities eligible as owner with whitelist tokens and to use an inter-currency send-to-owners. Basically tagging receivers with token A and then sending token B to all holders of A.

Maybe something similar could be done here: there could be a new token class that can be transfered only once (from issuer to user) that marks an address as "whitelisted" or "blacklisted" for a specific other thing in the ecosystem, e.g. only those who hold a "whitelisted for usd-tokens"-token may interact with usd-tokens. There should further be an option for an issuer to revoke such a token.

This is just an idea without digging deep into the topic.

[marv-engine]

See my related proposals in issue #152 from several months ago.

[dacoinminster]

I've made some further changes after talking to Zathras about this at length. He prefers explicit lists to implicit lists, and he's convinced me that is best.

Plus some of the changes here (to encode multiple bitcoin addresses) can be extended to a send-to-many tx.

[dexX7]

Remove space.

[dacoinminster]

Reverted whitespace-only changes. Thanks

On Wed, Nov 5, 2014 at 4:19 PM, dexX7 notifications@github.com wrote:

In README.md:

Transactions to Limit Funds (Theft Prevention)

-The Master Protocol defines some transactions which effectively lock funds from being spent quickly, making theft of a "savings" wallet much more difficult, even if that wallet is online.
+The Master Protocol defines some transactions which effectively lock funds from being spent quickly, making theft of a "savings" wallet much more difficult, even if that wallet is online.

Remove space.

—
Reply to this email directly or view it on GitHub
https://github.com/mastercoin-MSC/spec/pull/287/files#r19917798.

[dexX7]

The language is a bit flawed: a public key hash has a length 20 bytes and used in most standard transaction. Base58 encoding, checksums, versions and so on are "on top". This sounds as if you start from 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM to get to 00010966776006953d5567439e5e39f86a0d273bee, but it's actually the other way around. What is "hash step of creating a bitcoin address"?

This helps and is a good overview of the steps involved:
https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

Edit: by the way: gratulations for spotting the need of a version byte. I overlooked this. :)

[dexX7]

Plus some of the changes here (to encode multiple bitcoin addresses) can be extended to a send-to-many tx.

I have proposed a way to do multi-sends and much more a longer time ago and I still stick to it as elegant solution for many use cases. No argument against it or any flaw was brought forward until now and the feedback was rather limited. But not only once the demand for multi-sends and proposals to do so popped up.

Please consider and take a look at #62. The idea: add virtualization of "reference addresses" (= turn them into a field like you proposed) and allow encoding of (several) transactions into one Bitcoin transaction by chaining Mastercoin transaction data.

[dacoinminster]

That's the link I was looking at when I wrote this PR :)

"RipeMD-160 hash" is step 3, and the address can be derived from it.
Zathras pointed out we can't chuck the version if we want to support P2SH.

On Wed, Nov 5, 2014 at 4:41 PM, dexX7 notifications@github.com wrote:

Plus some of the changes here (to encode multiple bitcoin addresses) can
be extended to a send-to-many tx.

I have proposed a way to do multi-sends and much more a longer time ago
and I still stick to it as elegant solution for many use-cases. No argument
against it or any flaw was brought forward until now and the feedback was
rather limited. But not only once the demand for multi-sends and proposals
to do so popped up.

Please take a look at and cconsider #62
#62. The idea: add
virtualization of "reference addresses" (= turn them into a field like you
proposed) and allow encoding of (several) transactions into one Bitcoin
transaction by chaining Mastercoin transaction data.

—
Reply to this email directly or view it on GitHub
#287 (comment).

[dexX7]

Yeah, it's no argument against the essence of that field, I just think it needs rewording. And sorry for just criticizing, but not delivering an improvement.

[dacoinminster]

I think we've had enough feedback to merge.

I would like to get rid of reference addresses at some point, probably in a more sweeping change which also axes the exodus tag.

Welcome further pull requests to improve wording :)