Source? Client? Beta testing? Escrow? At least try to sell us on this.

Surely the most obvious thing to do in these cases is to take your ill-gotten funds and dump them into an anonymous exchange (that you connect to via Tor) and/or do mixing transactions with blockchain.info? And then route through three different alts before ending up as bitcoin in your "real" wallet. Or do I overestimate the technical capabilities of these people.

Before anyone accuses me of giving them ideas -- smart scammers already know this; the others aren't inclined to learn.

Your generosity is most welcome. I'll see if I have any friends possibly interested in Ripple. Pay it forward, so to speak.

Thinking about this some more:

I'd like to have a voting system to determine whether milestones are completed. Though instead of insecure and easily forged bitcointalk.org votes, have a voting system that more reflects the objective of Skycoin.

In particular, voting is done as follows:
1. Developer announces milestone completion, and a certain timeframe (e.g 1 wk) is agreed to beforehand that allows votes to come in
2. Initial investors can vote with signed messages "yes objective 1 completed successfully", "no", or "abstain" (defaulting to abstain) to determine if the objective has been completed
3. Developer or escrow agent tabulates incoming votes, produced a table with addresses and votes weighed by amount of initial investment (signed, again)
4. If "yes" > "no", then funds are released. If "no" > "yes" votes, then funds are withheld and it's to to the community to figure out what happened.

Still, trust has been irreparably damaged, crushed, defenestrated, incinerated, (insert more words). An escrow-backed IPO would do something to turn the tables, or at least make the scams be more inventive.

Specifically, I'm talking about a tiered escrow with breakpoints/milestones for completed objectives, i.e:
15% - completion of basic code base
15% - alpha testing
10% - revision of code base to beta status
25% - beta testing
rest - initial public release

These could be modified, but should be agreed to beforehand, and doubly signed with both the private keys of the final destination account and the escrow holder's account.

Reminds me... why not multi-sig transactions? Perfect application of escrow capability.

As that only has a 1/2^32 chance of succeeding, you probably will save money by doing that.

Unworkable, because Sybil attack.

Proof-of-work is NOT the sole "fair" distribution scheme, but it is the first. How so-called next-generation coins handle non PoW schemes is still a work in progress (excepting the innumerable scams currently out there).

After witnessing the disaster that is https://bitcointalk.org/index.php?topic=400356 (as an observer, of course) (and all the other IPO schemes that I won't name), I strongly recommend that you handle initial funding with a trusted escrow. That is all.

https://blockchain.info/tx/7ae5e9551f6ed0427f1427292952635137137bdca0719990c0fcf4c6f416cd22

Is this what an actual counterparty tx looks like?

In that case, I would have to respectfully disagree. While exponential decay of rewards allows distribution by PoB to continue, it either ends up a) putting an artificial constraint on price or b) unfairly dilutes early contributors. For a continuous PoB scheme, I'm not sure that any distribution would manage to satisfy both early and late investors (correct me if I'm wrong). The establishment of a market to trade the coins along with useful services is more likely to foster adoption.

@PhantomPhreak can you share how the checksum is calculated directly? I looked through the tools, but didn't understand.

@led_lcd yes, indeed it's a fun mathematical exercise to calculate just how unlikely such an occurrence is. We're talking about "number of atoms in the universe" scales here.

After you get your burn confirmed, check http://www.counterparty-explorer.com/ to see if your address pops up. To actually claim your coins, you need a counterpartyd install and wait for bitcoin 0.9 to be released to spend.

The problem can otherwise be expressed as the amount of time that would be required to generate a vanity address of that length (length 27 excluding the checksum). For each character in the vanity address, it takes 58x the computational power. Considering vanitygen rates, we're talking billions of years even with the entire power of the bitcoin network at your disposal. With that much hashpower, it would be vastly more profitable (by dozens of orders of magnitude) to mine.

http://bitcoin.stackexchange.com/questions/9408/how-does-vanitygen-calculate-difficulty

There's a difference between theoretically possible, and what can be considered a reasonable probability in the likely lifetime of human civilization. Note that as long as this address doesn't spend coins (it can't), even quantum computing will fail to make an appreciable difference. (See stackoverflow for more info).

Essentially how such addresses are generated:
1. Start with some sort of obviously nonrandom string (1CounterpartyXXXXXXXXXXXXXXX)
2. Append dummy checksum to string (e.g. 111111)
3. Base58 decode the above to get network version + RIPEMD160 hash + "checksum"
4. Try at most 16^8 ( = 2^32) (correct me on this) checksums to determine one that corresponds to a valid address; typical videocard (500 Mh/s) could probably do this in seconds.
5. Output the valid address, which has neither an associated pubkey or privkey.

It's quite interesting to say the least. I can't say I understand the technical details completely though, so people can correct me on this.

Essentially, if coins are spent from such addresses, then bitcoin as a while is broken and we should move on to something else.

I think it wouldn't be hard to programmatically check every address you get from that table with counterpartyd, and get the burn amount. In fact, an even easier way is to check the counterpartyd logfile, which has a pretty structured log syntax that you can turn into data with a few string commands. Of course this will require running bitcoind and counterpartyd on your remote server.

Example from log file:

The explorer seemed to indicate that burns with different inputs or more than one output to non-sending address were invalid. The only definitive confirmation though is to check the counterpatyd client.

PS The explorer seems to be down, last time I checked.

PSS I think it wouldn't be hard to programmatically check every address you get from that table with counterpartyd, and get the burn amount. In fact, an even easier way is to check the counterpartyd logfile, which has a pretty structured log syntax that you can turn into data with a few string commands. Of course this will require running bitcoind and counterpartyd on your remote server.

Example from log file:

Really nice UI. Please fix your url link. thanks.

Your BTC and XCP values seem to be a multiple of 6 higher than expected. After all each address can't have more than 1 BTC / 1500 XCP.

Also I see a lot of unfortunate people that messed up the burn. This is why you do a test burn, people.

Particularly it's the multiple inputs part that seems to be a problem. The tutorial should emphasize that multiple inputs are NOT accepted.

The fact that bitcoins are DESTROYED (instead of going to some developer's wallet) will at least hinder adoption of clones by altcoin writers. Why go through the trouble of that when it's so much easier to make a few hundred grand off of a "2nd generation coin" clone?

+-------+---------------+
| Asset |     Amount    |
+-------+---------------+
|  BTC  |            |
|  XCP  | 1144.93630909 |
+-------+---------------+

No idea, ask in the main bitcoin forums (do people go there anymore?)

Sending (or any form of use) will come with the OP_RETURN feature that is almost guaranteed to come in Bitcoin 0.9. Even if OP_RETURN is not implemented, the burn record remains forever, allowing an alternative implementation to be designed. At least that's what I gather.