The license WU issues to agents doesn't cover the exchange of virtual currency.  Sure if WU licensed you to exchange virtual currency as their agent then yes you would be "good to go'.  Their license does not however (I and legal counsel have seen a copy).  The federal law is clear on agents engaged in activity outside that which is licensed by the parent MSB.


The license WU provides agents is very specific.  It clearly defines what business activity is covered and what steps needs to be taken.  It isn't some blanket do whatever you want license.  Any MSB activity outside the license from WU would be no different than if you had no WU license at all. Still it is easy to confirm this yourself.  Call up WU agent number and advise them you would like to become an agent and as a WU agent exchange virtual currency for real currency.  Post back with what you find out.

Someday however WU "may" get into the business of buying and selling virtual currency and if/when they do the agents license would cover that as well.

Yes but it is important to consider the impact that will have on other nodes. The current protocol only supports relaying "full blocks" so if your node only contained pruned blocks then you would not be able to support the bootstrapping of other nodes.  In essence you would no longer be a full node.  You would internally have the security of a full node however you would appear more like an SPV (lite) node to other nodes on the network.

What is needed is a more robust set of internode messages so that nodes can request and relay pruned blocks.  Also this has less of an impact than you might imagine.  Today your node doesn't really "use" blocks beyond building the UTXO.   Your node stores them for archival purposes (and to bootstrap other nodes) but the blocks are only used to build and update the UTXO.  All validation of new txns and blocks is done against the UTXO.  The UTXO is much smaller than the blockchain (0.4 GB vs 20 GB) and it is the more critical resource. Pruning blocks won't change the performance, size, or resource requirements of the UTXO.

No because your licensed with WU is only for licensed activity and that doesn't include the exchange of virtual currency.   FinCEN isn't saying that Bitcoin exchangers might ALSO be using money transmission they are saying that the very act of exchanging virtual currency for real currency is money transmission.  Even a face to face transaction involving the exchange of virtual currency is considered money transmission under federal law.

If your agent agreement doesn't cover the exchange of virtual currency (which it doesn't) and you engage in it then you are engaging in activity outside the scope of your agreement.

As for your claim that anything involving virtual currencies is money transmission that is completely false.  All the information is publicly available so why not .... READ IT.
http://www.fincen.gov/statutes_regs/guidance/html/FIN-2013-G001.html

That is an interesting idea to use the blockchain for revocation.  unspent = valid, spent = revoked.   Even if private key is compromised the attacker can't prevent the original owner from revoking the cert (unless original owner loses access).  The amount of the output can also scale to the security level desired.   If the "bond" amount is larger than the expected return from misusing the cert the attacker is likely to just claim the bond and thus revoke the cert.

One thing I would consider adding is an optional mechanism to allow the bond to expire.  This is pretty common in PKI and allows a way to expire certs for which control of the key has been lost.

I think you have to consider what is your intention for using R30?  As a general purpose non-cryptographic hash?  As a general purpose cryptographic hash?  Or as a PoW function?

Irreducibility of computation isn't really that important for the first two categories but is (in theory) pretty important for a PoW.  Say someone found a way to produce SHA-256 hashes 10,000x faster for a given amount of die space.  It wouldn't do anything to compromise the security of SHA-2 as a cryptographic hash but it would allow one to exploit the bitcoin network for cheap.

This is why I indicated using something like:

Where:
H= a secure cryptographic hashing function (i.e. SHA-2)
Blockheader = arbitrary length blockheader (excluding the nonce)
Nonce = 64 bit (don't make Satoshi's mistake of using a nonce "too small")

You can't adjust difficulty based on blocks alone.   Ok 2016 blocks have been completed does difficulty go up or down?  You need a second factor and that factor is time.  So Bitcoin is dependent on real world timekeeping however Bitcoin does a few things to minimize the influence of time on the security of the network.

The problem with that is an attacker (even one with 51% of hashrate) currently has limited capabilities.  They can't give themselves coins, or steal coins.   With a "super block" an attacker could simply rewrite history.   Nodes which didn't validate the entire chain would be unable to tell the truth from fiction.  If nodes need to download the entire chain anyways to validate the super block then you haven't gained anything.

The reality is most users will not be running full nodes.

That is how it works but it is implemented correctly.  nlocktime transactions which are not standard until the lock time is reached.  This is intentional because if it wasn't true one could spam the network at no cost by generating millions or billions of nlocktime transactions.   However this doesn't prevent you from giving the nlocktime transaction directly to the recipient out of band.

No. No more than dollars under your mattress you don't use for 5 years belongs to NY.  Abandoned property deals with THIRD PARTY accounts.   So under the BitLicense if you had an account with an exchange and you didn't login for 5 years the EXCHANGE would turn the account over to the state.

Here is a good native multisig (vout:2) to use in your example instead of a fake one 14015bd586c0c7a28979ca294b114441f23bfc97be17cd6077b9e12e2709fec3:2.
https://blockchain.info/tx/14015bd586c0c7a28979ca294b114441f23bfc97be17cd6077b9e12e2709fec3

It uses an uncompressed pubkey (which would use the 0x05 prefix in the compact PubKey format).

Nice diagrams. I love it when a plan comes together.

One recommendation would be to remove the section_ids (as the records are self describing) and instead add a value (in bytes) to the header with the offset to the first record of each type.

For example in your sample the offsets would be
0x01 = 4800000000
0x02 = 9F00000000
0x03 = BC00000000
0x04 = 2A01000000

Alternatively you could include a claim_type record for each type just after the header and before the array of claims which has the type, offset, count, value, size but that might be overkill.  The last option would be to not include the section size or section header (i.e. header then list of claims much like a block is a header and list of txns).  The snapshot will probably be parsed to a database (at least key value db like leveldb) for processing anyways.

First I would look into implementing RFC6979 (Deterministic ECDSA Signatures).  It produces a deterministic but secret k value as an alternative to using a nonce in ECDSA signatures.  That reduces your attack space down to the user's key(s).  I am unsure why you would need more than one key but it doesn't change much.

A shuffled deck of cards has 225 bits of entropy and would be far superior to any javascript PRNG however that may not be practical.  

If you must generate the user's key in browser then there aren't many particularly good solutions but one general concept you may want to look at is to use multiple entropy sources which are XORed together.   As an example you could use javascript PRNG but it is very difficult to verify how secure that is on all browsers, all versions, all OSes.  On the other hand you could have the user provide entropy (random mouse movements, entering random text).  Each method has vulnerabilities.  If you have the user enter 200 charecters some users is going to enter aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, you should count on an attacker doing a preimage attack.  On the other hand if you use the PRNG and it is compromised on some systems than those resulting keys may be breakable.

Instead you would combine the two independent sources and the entropy of the resulting value will be at least as good as the entropy of the higher entropy source.  The simplest option would be to XOR each source but depending on the libraries you have access to I would prefer using something like a HMAC.  So even if both sources have sub par entropy the combined value would be better than either source by itself.  You can even use semi-trusted public numbers like pulling from random.org as long as they properly combined with other entropy sources.

As far as storing in browser local storage make sure you give the user a (strongly encouraged) option to print out the seed.  You wouldn't want a loss of funds due to local storage data loss.

For custom application development it would be nice to use bitcoind as a node only.  Bitcoind supports "no wallet" parameter and txns can be created rather easily using createrawtransaction, signrawtransaction, and sendrawtransaction.  Unless i am missing something there is no easy way to find the unspent outputs of an arbitrary address.  For now lets ignore non-P2SH/P2PkH outputs.

listunspent only returns unspent outputs for addresses in the wallet.

All the necessary information is in the UTXO (chainstate folder) it just is not accessible from RPC.  Am I missing something?

Well 0.0.1 makes me think it is someone doing some alpha development (and obviously doesn't have it correct).  Rather rude to be doing it on the main net though.

Don't believe everything you read on the internet.  What makes you think SHA-2 is "closed source".  The algorithm is publicly available.
http://en.wikipedia.org/wiki/SHA-2#Pseudocode


That is a cornerstone of any strong cryptography.  The algorithm is still secure even if the attacker knows everything except the secret.  If a system needs to keep the algorithm secret in order to remain secure then it is nothing more than feel good security and will be broken wide open relatively quickly. There are no widely used cryptographic system where the algorithm is a secret.  All the algorithms of the cryptographic primitives used in Bitcoin are public knowledge.

You could use deterministic signatures and never use the RNG for singing.  Bitcoin is compatible with RFC6979.  I don't know if any Android wallet supports RFC6979 but that would be a pretty good feature to add.

Not with deterministic wallets.  You could generate an lifetime of keys from a single seed which once backed up never needs to be updated.

We just use exactly whatever the user used in the output.  So if they have an uncompressed pubkey we take the hash of the uncompressed pubkey.  

Sadly most wallets aren't smart enough to realize that if the user has a private key he has both the uncompressed and compressed pubkey and thus could sign using either one.  If the user has a privatekey marked internally as uncompressed he won't see the compressed address in his wallet and if he tries to sign for that address he will get an error.  Technically the user could still claim it by exporting his uncompressed private keys and reimporting them as compressed private keys but that wouldn't be very user friendly.  So we use what the user used.

Example of Uncompressed PubKey -> PubKeyHash
http://webbtc.com/tx/0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098

PubKey: 0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d 4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee
PubKeyHash ( HASH-160): 119b098e2e980a229e139a9ed01a469e518e6f26
The Address: 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX


Example of Compressed PubKey -> PubKeyHash
http://webbtc.com/tx/0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098

PubKey: 024d57123256b2a84e6618bc12b08f81cd54ec79fcd7a55a129eee9402bac8d5f7
PubKeyHash ( HASH-160): f4f5209eb5bce683a4a1dd325e22bdda6a31cf95
Address: 1PLDXZPhFEfGGxdXr54FxvWUvWcRCrjHEG


We aren't changing uncompressed to compressed or compressed to uncompressed just hashing the key as provided to produce the PubKeyHash.  In the first example the user has address 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX in his wallet.  If we switched that pubkey to a compressed pubkey 0296b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52 and hashed it we would end up with address 1PKW9GWX2P2JhCSR17BXa4B8MJ4ozUjW9Y which is probably not in his wallet (although he has the required private key).

I think that is mostly it.  

Claim Values
On edit: I saw your note on more efficient searching by having static record size after writing this.  I could have swore when I read it before it said varint but maybe I was just seeing things.  Lookup time is probably something to consider.  I guess it may makes sense to use unit_64 in the serialization.  As long as the hashes are computed the same way they can be stored internally as the developer sees fit.  The key thing is for the serialized claim that is to be hashed having a single specific form and simple is probably better.   I will leave the notes below as they may be used internally by a developer to compact the snapshot.bin.

The exact varint being used should be clarified since the hashes for the claims (ClaimId?) and the merkle tree will depend on the exact serialization of the bytes.  In Bitcoin what is commonly referred to as "varint" is called "compact_size" in the source code.  Bitcoin also uses a true varint internally which is more space efficient (not sure why Satoshi felt the need for two formats).   The "internal varint" is base-128 and is a better fit here.  More info: http://en.wikipedia.org/wiki/Variable-length_quantity.  Most bitcoin (or cryptocurrency) libraries should have support for base-128 (although it may be named differently).

A weighted average of all claims results in an average value field size of:
uint_64 - 8 bytes per record
bitcoin "compact size" - 3.91 bytes per record (51% space reduction)
varint (base-128) - 2.85 bytes per record (64% space reduction)

PubKeys In Native Multisig
I would recommend storing all PubKeys (native multisig) in compact form.  This is an internal form used by bitcoind for reducing the size of the UTXO and shouldn't be confused with compressed keys.  In compact form all pubkeys are stored as 33 bytes in the form of <prefix:1 byte><x: 32 bytes>.  The y values are not stored and are reconstructed as needed.

Compact PubKey prefixes
0x02 = Compressed Key (even)
0x03 = Compressed PubKey (odd)
0x04 = Uncompressed PubKey (even)
0x05 = Uncompressed PubKey (odd)

Length bytes[/b]
With a fixed size value field for all records the length of 0x01 and 0x02 records will always be 29 bytes so no length field is needed.
<prefix:1><hash:20><value:8>

For 0x03 the length can be computed from the "n" value (length = 11+ n*33)
<prefix:1><m:1><n:1><pubkey_1:33>...<pubkey_n:33><value:8>

This would allow you to save 1 byte per record (except the very few unclassified scripts).


Merkle Tree
You should be explicit in indicating how the txn are ordered (I would assume the same order as the file) for creating the merkle tree.  Also explicitly indicate how to handle an odd number of claims.  One claim will need to be hashed to itself first or last is equally good but it should be defined.

I think a good corollary would be merge mining and transaction fees in pool mining.  Initially some pools kept the merged mining coins and transactions fees.  Competition by pools which paid those out forced most pools to adopt similar policies.

There is no decentralized protocol that could be used to force exchanges to "payout" the spinoff coins.  It will simply require competition and education.  If enough users demand it and are willing to switch exchanges they will be forced to give users that capability.   Especially among exchanges which trade altcoins this can be a very powerful low cost way for the exchange to gain volume (and thus fees) in a spinoff coin.  Instantly all their BTC depositors are also xyzCoin depositors as well.  Many will probably immediately trade either "cashing out" to BTC or scooping up the spinoff at a low cost.

As for the spinoff being "gray area" I don't think it is.  The relationship between an exchange (or wallet or other third party crypto service) and users is one of bailor and bailee.  It is the user's property it is just under the custody of the exchange operator.  Saying it is a gray area would be like saying if your broker took the dividends of your stock it would be a gray area because the stock is in an account at the brokerage.  Granted no such legal cases have occurred (yet) but I can't see a court agreeing that an exchange is entitled to the benefits of its users property.

That is probably not true.  The rate that claimants make their claims is unknown however the exchanges do not have the majority of the Bitcoins in circulation and thus they wouldn't have the majority of the valid claims either.   The largest known bailors (google it) of Bitcoins are BitStamp and Second Market with about 3% and 1% of the outstanding BTC.  In the case of BitStamp since they made their cold storage addresses known (so called "audit") it would be impossible for them to claim the property of their users without it being public knowledge.

Still if you are worried start asking exchanges what their policy would be on spinoff claims from the user's coins in their custody.