Or even simpler:

Scratch the Fees idea (originally I was looking for a design that would motivate Invictus to do this)

INPUT:
OLD_DONOR_ADDRES

OUTPUTS:
1_ANGEL_ADDRESS | AMT: 1 satoshi
1_NEW_DONOR_ADDRESS | AMT: 1 satoshi


If sent 1 satoshi to ANGEL address combined with 1 satoshi to another address, then that's the transfer of responsibility.

DONE - won't even need to create/parse new vanity address!

We already have a tool that parses one address, that's the hard work and it's been done. Parsing a second one is trivial.

EDIT: I might have misunderstood. Did you mean we can't parse multiple output transactions?

I missed that detail, but my solution still works. Let me provide more info.

Make a special 1_AGS_TRANSFER BTC address.

When you want to send a "TRANSFER TO xxx" message as a transaction do this:

Send 0.01 BTC (or whatever fee BM thinks is appropriate, or if generous make it 1 satoshi) to the 1_AGS_TRANSFER address.
In the same transaction send 1 satoshi to the new BTC address that will control your AGS

So you have

INPUT:
OLD_DONOR_ADDRES

OUTPUTS:
1_AGS_TRANSFER | AMT: FEE (say 0.01BTC)
1_NEW_DONOR_ADDRESS | AMT: 1 satoshi

This is totally doable. Parser generating genesis addresses would need to be adjusted to look for 1_AGS_TRANSFER as well.

Final suggestion from me on making AGS liquid:

Why not make it so that if some minimal amount of BTC is sent to the ANGEL BTC address with a special message containing a valid BTC address, then it transfers over the AGS to the new address?

Then that amount can be kept as "transfer fee".

Of course, there could be complication for snapshots that are already taken. i.e. Feb 28 for the BTSX, would it still honor transfer AFTER the Feb 28 snapshot, or not, etc.
But nothing we couldn't implement easily. We already have tools to parse the transactions from AGS, just parse the messages as well.

Thoughts, comments?

UPDATE (examples):

FEB 1, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC

FEB 2, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC

APR 2, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 3 BTC

JUNE 15, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 0.02 BTC
MESSAGE: "TRANSFER TO 1AnotherBTCAddressGPZhHaYfLsMkiQcR"

JUNE 25, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC


Now this person gets to control his 2BTC worth of BTS X with his new address 1AnotherBTCAddressGPZhHaYfLsMkiQcR, even though transfer happened after the snapshot, it happened before BTSX went live. As well as 5 BTC of all future DACs honoring AGS. The 1BTC on JUNE 25, will still be controlled by original address since donation occurred after the transfer.

Or if BM thinks this seems too complicated, then we can just do it for future releases.

Well it is too late to do that right now. But even though I am an old C++ dog myself. I think it's the wrong language to use for this.

A) Security: it is often the source of buffer overruns and what not - look at the heartbleed bug. For example Rust is a language developed specifically for operating systems and guards against all of these issues.

B) Velocity: languages like Python, go, JavaScript are much quicker to prototype and are platform independent. Ethereum uses those for a reason. And they will go very far very quickly.

I've been toying around with NodeJS and the ease if setup is extremely impressive.

Using any of the listed platforms above would make it a lot less prohibitive for developers to join. Ironically most hardcore crypto people are also stubborn C++ old school folks who think it is safer to avoid using a scripting language.

Lol

Inspired by logxing's proposal, i come up with an idea which may completely solve this potential security issue.  if we could use the signature which sign on the specified text(e.g the donation address) with private key, to claim the corresponding shares in different DACs,then we would not worry about private key stolen，as we do NOT need to expose our private key and use different signature to claim the shares in different DAC. e.g signature to claim the XTS shares =sign(“XTS”+Pts/BTC donation address, PrivateKey), signature to claim the DNS shares =sign(“DNS”+Pts/BTC donation address, PrivateKey)

Awesome! I strongly prefer this method. This should be a standard tool in the toolkit. I would imagine we already have a tool that generates the genesis block.

One problem I see with this method however, is that it generates a signature, not a public address. i.e. only holders of AGS could generate the public address for each DAC.

Unless the DAC itself has a method of claiming by signature, but that may complicate the protocol.

Does the Bitshares framework support the same transaction OP_ codes as Bitcoin?