@NanoAkron I speak with no authority at all on BitID. In fact, I have nothing to say on what BitID is, what BitID is not, or what BitID should be. I sincerely apologise if I've given any impression to the contrary.

Please re-read my posts. I'm simply trying to illustrate a new idea here, which BitID may or may not benefit from incorporating, and which people implementing BitID are free to use or ignore as they see fit.

I speak with certainty only about my own proposal. I think you'll agree it's fair for me to be certain about my own ideas at least ;-)

The idea I'm trying to illustrate is just:
* there exists a way that anonymous users can offer information to a webserver that can help it distinguish them from throwaway accounts.

That is all. This idea exists independently of BitID, and could be implemented independently of BitID. It just makes it easier if the user has some sort of portable identity that they can tie the proof-of-stake to, so that they don't need to re-calculate it for every site. An email address would work fine.

I proposed the idea in this thread because:
* a BitID would also work fine (being a portable ID that could be used on multiple websites)
* the set of potential BitID users and the set of potential users of my proposal heavily overlap: all Bitcoin users, basically. That makes BitID an obviously natural fit.
* it would provide an additional benefit to use of BitID, potentially increasing adoption.

The two complement each other.

That was just one example.

I'm sure there are hundreds of use cases for BitID. And a single user can cheaply create hundreds of BitIDs for any of those use cases :-) How many of those use cases would benefit from being able to distinguish cheaply created throwaway BitIDs from more long-lived ones? Use your imagination.


Or even by anyone with zero satoshi to their name, right?

My proposal doesn't affect that in the slightest. Signatures proving stake are an optional extra for any user who wishes to provide them. Not doing so just means you get treated as a normal user (ie. the status quo today.)


Why should it not be cheap? It should be free.

Nobody is forcing anybody to prove stake if they don't want to.


Nobody suggested locking down anything. I'm afraid you must have misunderstood me somewhere.


Not a trust system.

It could be validated as frequently as the server needs. If the server just needs to decide whether or not to show you a CAPTCHA upon account creation (a very common use case I forsee) then once is fine. But if the server is doing something more complex there's no reason it couldn't refresh your stake weighting at will.


Uh, that's your BitID. (ie. the address you're using to sign in with BitID - replace QRSTUVWXYZ with your actual address.)

An email address would work equally well. We just need a way of tying the signature to your identity, so that nobody else can use it (and potentially get it blacklisted.) Anything unique that the website knows about you would work. But it's a hassle for the user to have to create the signatures more than once, so best to use something common (thus I thought it might be a good fit to use BitID.)


Well, everybody can always participate, exactly as they do now all over the web. Without a signature to prove ownership of a single satoshi you'd just be a normal user (ie. the status quo today.) Any threshold is better than nothing; there are only advantages to implementing this that I can see.


You have badly misunderstood me :-)

* This is not an authentication mechanism
* Authentication would happen with ordinary BitID (ie. signed challenge - no change there at all)
* In addition, once the user has successfully authenticated as per normal, the server can be optionally be given one or more signatures proving ownership of stake. The server can make use of the weighting it calculates from this information in any way it sees fit.
* The signatures are static because they just sign the user's ID (eg. BitID, or email address) - so they must be created exactly once and never change
* The server just used the signature to prove a link between the stake and the user, nothing else.

Just one other small point - it might be necessary to tweak the (balance * coin age) formula, perhaps to give more weight to balance, or more weight to coin age, or to impose a minimum coin age (1 day? 1 week?) or whatever.

I'm simplifying a bit here because I'm just trying to illustrate an idea.

The key point is that:
* BitID need not concern itself with the formula (but it would be helpful if it would automatically pass the address signatures (for proof of funds) during BitID login, to simplify the user experience.)
* Individual sites could employ a different formula to calculate the weighting (some might give more weight to coin age, some less) ... and use that weighting in different ways.
* What works best for any given site could be arrived at through trial and error.
* The user doesn't have to care. They just (optionally) provide signatures for a decent amount of funds that they've had lying in one place for a while, or intend to have lying in one place for a while, and forget about it. Anywhere it helps them with account creation (skip the CAPTCHA, start with +ve reputation, or whatever) is a bonus. Anywhere it doesn't (ie. 99% of the web) doesn't matter, no harm done.

If this were implemented I'd probably just put ~$100 into a new cold storage address, create my BitID signature, and then forget about it. As time goes on my ID will just continue to accumulate more and more legitimacy. I know I won't move it, so it doesn't have to be a huge amount (and, indeed, I'd refrain from signing with my main savings wallet, for financial privacy reasons.) If I ever need that $100 back it's still mine, so no harm (although my BitID's legitimacy rating would be reset as soon as I moved it, of course - but I could substitute/add other signatures at any time.)

We can't prove goodwill, only "likelihood that user is not a throwaway account." But if you don't act with goodwill we'll ban your account (as per usual) and you'll be on to creating throwaway accounts soon enough. If you have a huge stack of bitcoins, and you're prepared to split them up into lots of addresses and wait for them to age... then yes, you could create a greater number of throwaway accounts that we erroneously think are legitimate users. But you'll still burn through them eventually :-)

Additionally, I'd suggest:
* you would have to be a very determined troll to plan your trolling weeks or months in advance :-)
* we could just "lift the bar" (adjust the weighting that our site is looking for upwards) so that your troll accounts still don't meet it

As you see, it's an arms race between you and the legitimate users. But you have two disadvantages:
* you have multiple IDs that you need to plan in advance and adequately fund (a normal user just has one)
* those multiple IDs that you put so much hard work into keep getting reset to zero every time you do something naughty with them

It isn't a perfect system. But it would surely discourage some (most?) trolls. It gives us the tools to fight, at least. Making life harder for trolls and scammers is IMO always worthwhile even if not perfect.

I'm not suggesting that wealthy people are intrinsically more trustworthy. Indeed, the weighting I'm talking about is not a measure of trust. It's just a measure of how likely any given user is not to be using a throwaway account.

When users are anonymous and accounts are free to create there is zero barrier to people creating hundreds of throwaway accounts, which has wreaked all kinds of havoc all over the 'net, and is mainly responsible for the current state of affairs of semi-illegible CAPTCHAs everywhere you look.

We're not trying to compare two genuine users, Alice and Bob, and determine that Alice is more trustworthy or important based on the fact she is richer. We're just trying to screen out the thousand spam accounts that Eve has created to try to game the ratings system / act as sockpuppets / troll their merry way around the ban-hammer. Above a fairly low bar everybody would be equal.

Eve's spam accounts will find it much harder to each reach that bar, because she has lots of them that she needs to fund. And every time an admin brings down the ban-hammer Eve suffers a setback.

Any genuine users who can't reach the bar will be indistinguishable from Eve, and will have to establish their reputation from scratch. But they currently do anyway. That's the current status-quo.

In reality showing that you had $20 sitting in one place for a month might be enough to skip the CAPTCHA on most sites. Or showing that you had ~$500 sitting in one place for a day, if you're wealthy and in a hurry. Or showing that you had ~$3 sitting in one place for 6 months, if you're really poor but not in a hurry. This is a mechanism that everybody can take advantage of to distinguish themselves from Eve's throwaway accounts, if they want to.

Negative. You only need a /signature/, created once by the key with access to the funds, which does not change. For an entirely manual implementation you could simply save the signature in a text file on your desktop and cut/paste it into a form on the website the first time you log in.

Try this:
1. Open bitcoin-qt
2. File -> Sign Message
3. Pick address that contains some aged funds
4. Enter message - "My BitID is: QRSTUVWXYZ"
5. Sign
6. Copy/paste the address and the signature into a text file (eg. "IAV7hQhB5d5z0PGJFpqF+xiGt1T+u6etvBx56jCA2TxXf9LaTb/+iX9H/87UKx9S9vOqiL11n1GqkoaTiGjsQwA=")
7. GOTO step 1, repeat for as many addresses as you desire

Now, if you happen sign into my website with BitID QRSTUVWXYZ, you need only provide me the contents of your static text file sometime (and only the first time you sign in) in order to establish that you're "probably genuine."

I determine how much weight I give to your genuineness based on the sum of (coins * age) in all the addresses you've provided that:
1. have correct signatures matching your BitID
2. I haven't yet blacklisted for being associated with bad behaviour

A higher weighting might mean you start with more forum reputation, or aren't challenged with a CAPTCHA. A low enough weighting means you still get the CAPTCHA / default newbie reputation / whatever (ie. status quo, no disadvantage.)



Indeed. There /is/ a little bit of extra work for the server here. But this is for a non-critical bitcoin application (no money gets lost if we screw up) so we don't need to run a full trustless node. A light SPV client like bitcoinj should work fine, or perhaps even something like the blockchain.io API. Hardly prohibitive resource-wise.


I think it'd be a nicer user experience if this were integrated with BitID, as the user could just configure their proof-of-stake signatures once and then not care, and get the free reputation benefit everywhere they use BitID. But, in the simplest case, as I say, a website that already accepts BitID login could just provide a "paste your proof-of-stake signatures here" text field for the user to optionally submit.

I'm just throwing ideas around here, but I suspect this could prove to be quite effective.

A universal measure of how much a user has invested in their current ID should be very generally applicable. I think it belongs in the auth protocol. When I sign in with BitID the server should just have that "likelyhood of uniqueness" weighting available to it for free. I need only transmit a few bytes during authentication and it'd be available. It's then up to the server whether it wants to make use of that information or not.


Completely tangential use case sorry If the user is paying you for goods/service then you don't care if they do it 100x - as long as they're paying you every time When was the last time you typed in your visa card number and then got presented with a CAPTCHA? The fact that you've just presented payment is all the proof most people want that you're serious about the transaction.

Think instead of something like this forum, where account creation is free:
1. create account
2. troll / scam like crazy
3. acquire negative reputation
4. ditch account, GOTO 1, rinse & repeat.

That's pretty common. How can we combat it? One idea is to make newly created accounts start with negative reputation (or restricted to posting in a newbies area, or whatever.) But then genuine new users face an uphill battle to distinguish themselves from the trolls and scammers, and to build up a reputation.

/I'm just suggesting one cheap way that we could distinguish them./

If the user can show signatures proving control of a suitable amount of aged coins (the more coins the better / the older the better), that we haven't ever seen before, then they're /probably/ a genuine new user.

In the case of a forum, we might grant that "probably genuine" new user a positive starting reputation, whereas an unverified new user (more likely to be a troll/scammer creating throwaway accounts) starts with default lower reputation. We're just sorting the sheep from the goats, if you see

In the case of, eg. an email service, we could allow the "probably genuine" new users to skip the CAPTCHA (ie. if their [balance * coin age] score meets a certain configurable threshold.) The CAPTCHA is designed to prevent an automated script from creating thousands of accounts, right? Such an automated script is very unlikely to be able to provide thousands of unique high/aged BTC balances.

Yes, the spammer could invest in an enormous amount of BTC, split it into thousands of addresses, and then wait for a few months for it to age enough to perform his attack. All the site admin needs to do to respond is bump the threshold up. He can quickly establish a bar that is high enough that only the most determined spammer would bother.



I'm an avid bitcoin user, I pay for stuff in bitcoin whereever I can. But even I can't be bothered to keep funds in a hot wallet so I can make micro payments to sign up for forums. I don't expect you'll get many takers for that one


I advocate simply that you give them one tool to do this: BitID uniqueness weighting. (grasping for a good descriptive term here!)

The more aged coins this BitID user controls, the more likely they are to be a unique person. It's just a weighting - let site operators make use of it any way they wish.

Abusive behaviour isn't the problem I want to fix - /cheap identity creation/ is.

Abusive behaviour is easily dealt with by simply banning the user. A problem only arises when the user has nothing invested in the account that you banned, so can simply create a new account and come back.

(coin age * balance) is a very good proxy for investment in an identity, because you can't repeatedly fake it. Sure, everybody starts with some reputation, even the bad guys. But the bad guys only get one chance to burn up their reputation, then acquiring more will be very slow.



He'd get banned very quickly, and then not come back (well, not without significant resources + time to throw at the problem.) I'm not talking about a 100% bulletproof solution, just cheaply raising the bar.



My objections to the sacrifice approach are:
* the bootstrapping problem: real upfront costs to users to participate a new, as-yet-unestablished mechanism, will prevent it gaining significant traction
* the fluctuating value problem: a sacrifice of 1 BTC right now represents about USD$440. A sacrifice of 1 BTC in Janurary might have represented closer to $1000; in Janurary last year, ~$17. Measuring sacrifices is non-trivial, requires knowledge of historical exchange rates.

Objections to the other two - escrow with the website, or outright micro payment - are similar:
* bootstrapping problem: too complex / expensive to gain significant usage
* requires funds in a hotwallet, which may be vulnerable to theft
* requires the client to have access to the blockchain / actually broadcast transactions

By comparison, what I'm suggesting:
* requires the client to simply have some signatures which prove control of funds, nothing more. The BitID authentication remains very simple (just a few extra bytes to transmit.)
* client requires no hot wallet, no knowledge of blockchain, makes no transactions.
* requires new users to simply have a bitcoin balance somewhere, which most already do (even cold storage - as long as they have access to the private key to sign their BitID to prove control of funds.)

Think about it. Most bitcoin users probably already have control of an address:
A) with significant funds
OR:
B) with even a small amount of funds that haven't moved for a very long time
OR:
C) both (ie. your typical cold storage user)

They could just sign a simple message (eg. bitcoin-qt has a feature to sign arbitrary messages with private keys from your wallet) that says "My BitID is: XYZ", cut-and-paste the output into the client software they use for BitID (browser plugin, whatever.) And - bingo - instant reputation everywhere they use BitID.

Not directly related to your round-robin rotating single mint idea (which I still haven't fully wrapped my head around), but you may wish to add this to your reading list at the top of the thread:

http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/

A big problem on the internet today is the cheapness of identity. Many sites struggle with a constant influx of trolls and sock-puppets. We attempt to address this with:
* Forum reputation systems - but there's still no easy way for a new user to prove they have anything invested in their identity.
* The ubiquitous CAPTCHA, just to establish that a visitor is a human - the very lowest bar we can put up, and even that is constantly being eroded, and causes problems for visually impaired users.

If I'm using a bitcoin address to sign in to a website, the site now has some extra information about me:
* the amount of BTC I control with that address
* the coin age

Or, put another way, the site can predict:
* the number of "Bitcoin Days Destroyed" that would occur if I were to hypothetically move the coins to another address I control in a self-payment.

So an address with 2 BTC in it for the last 5 days gets a score of 10, an address with 0.5 BTC in it for the last 21 days gets a score of 10.5, etc.

If this score is high enough you don't need to bother me with a CAPTCHA. You can also initialise forum reputation based on this score, etc etc. It'd be useful for all kinds of applications where anonymous identity is desired but the cheapness of identity creation causes problems (eg. distributed markets?)

Of course, I don't want to keep a significant balance in a wallet accessible by my browser. But I could:
* sign my BitID address with my main (perhaps offline) wallet address(es)
* provide these signatures to the server while negotiating BitID login

The server could then establish a score for my identity (coins in signatory addresses * coin age) - the higher the score, the less likely I am to be engaging in abusive behaviour. If I do engage in abusive behaviour then:
* the server adds all the signatory addresses to a blacklist (either internal, or perhaps shared with other sites somehow)
* assigns a zero/negative score to any BitID that provides any blacklisted signature upon login in future

If I wanted to dodge the blacklist and continue to engage in abusive behaviour, I'd need to move the coins to a new address. This effectively resets my "Bitcoin Days Destroyed" score to zero, and I need to wait for it to accumulate again, thus braking (rate limiting) my behaviour.

How high the bar needs to be (score of 5? 100? 0.1?) would be established by individual site operators for their own sites through trial and error.

Please consider extending your BIP to cover this. It would provide an additional factor to motivate adoption of your authentication scheme for relatively little added cost.

I was responding to etotheipi's opinion that we should just write off PoS applications as not viable.

Ideally we'd have some sort of "PoS applications standard" that popular / "well behaved" mobile wallet apps would adhere to:
* never send a TX using any unconfirmed UTXO as an input
* never send a TX without the appropriate fee
* (something else?)

Andreas Schildbach's android wallet already forces #2. And we could potentially do away with #1 in future, once TX mutability is fixed properly.

All PoS systems could accept a zero conf TX only if it meets the standard, otherwise wait for a block before displaying "PAID" to the operator. ie. the PoS system should be as defensive as practical, but in a well publicised, well defined way. Then it's up to the customer to use a wallet app that conforms to this standard if he doesn't want to wait at the counter.


As per the standard I propose: ignore it until it makes it into a block.
If this behaviour was standard then customers / wallet apps would quickly learn better than to do this.


It remains to be seen how big an issue this would be in practice. As was suggested elsewhere in this thread,
a wallet could have a "fragmentation threshold" that it attempts to maintain, eg. by splitting change to itself, which would help mitigate this.

Of course, in an ideal world our wallets will all do an opportunistic CoinJoin whereever possible too ;-) That'll require a certain level of fragmentation to be effective anyway.

Maintaining a single large UTXO, slicing a little bit off every time you make a payment, and returning change in another single large UTXO... just isn't viable from a financial privacy point of view anyway.

I disagree.This is a very popular use case, and there's no reason that it can't work "well enough" in the real world.

Consider this typical scenario of a pub selling beer for bitcoin:
* we have a well connected node
* we receive a ZC txn for the beer composed entirely of confirmed UTXO as its inputs (even just 1 block deep)
* we listen for N seconds and do not observe other txns that double spend our ZC txn's inputs
* our ZC txn pays the appropriate fee to be included in a block quickly

Should we give the beer to this bloke right away, or wait for his txn to make it into a block?

I'd argue we're pretty safe just giving him his beer. It's worth all of $5.50, and the chance of a double spend invalidating that txn, given the above observations, is vanishingly small. Yes, he might:
* have a node connected to hashpower we're not aware of / well connected to
* be able to broadcast his double spend txn to that part of the network without us noticing it
* be lucky and get it into a block
* be really fast at drinking his beer and running out the door

But it's not bloody likely :-)

Honest customers will always outnumber this guy 1000:1.

Space in the bitcoin blockchain is a scarce (and expensive) resource.

By reusing the BTC send address as the XCP send address, you get the following for free:
* the send address already being part of the transaction
* the proof that the sender "owns" the XCP send address (by bitcoin-validated scriptSig containing ECDSA signature)

That's sort of a big deal. If you want to use separate addresses for XCP, embedded as metadata in bitcoin transactions (which currently relies in the CHECKMULTISIG trick, the "expense" of which a bunch of people have been complaining about lately)... then you also need to embed a signature scheme for proving ownership of your XCP addresses and can't just rely on bitcoin's heavily battle tested one for free.

That's a LOT of extra data to be trying to stuff into bitcoin transactions. It'd contribute significantly to blockchain bloat, and would cost you a lot more in fees because of the unnecessarily large size (in kBs) of each transaction (and if it wouldn't, it certainly ought to.)

On top of that, the security of your XCP transactions would now be highly questionable.

I imagine that would be why the devs have designed counterparty the way it is :-)
(Incidentally, you'll notice most other coloured-coin schemes out there do something similar.)

Agree. Having more than one mechanism to penalise BTCpay defaulters adds unnecessary complexity. Plus it damages order fungibility (the idea that any order can be matched against any other without the user having to jump through hoops.)


This is exactly what I'm attempting to address here:
https://forums.counterparty.co/index.php/topic,69.msg340.html#msg340

* the fee mechanism/concept kept simple - an XCP sell order always specifies his fee_required as a simple number (ideally proportional to the size of his order)
* the ability of an XCP buy order to match any sell order, providing the required fee as any combination of XCP and BTC he prefers
* the automatic refund of XCP fees upon BTCpay settlement

If implemented, this would result in:
* the vast majority of fees being paid in XCP (any sensible client would do this automatically where ever possible,) massively improving fee efficiency.
* serious troll deterrence, as matching any appreciably large sum of XCP and failing to BTCpay would cost you heavily (but it'd be free if you utilised the XCP fee and did BTCpay.)
* retained simplicity of the fee mechanism. XCP sellers just specify a single fee. XCP buyers can match any order on the book, paying the fee with whatever they have available. Software could automatically default optimal values very easily so that the user need never even think about fees.

I must correct you on two points:

1. I'm not a counterparty dev.
I can't take credit for a single line of code in counterpartyd. I actually only heard about counterparty in the last week I'm just some random guy with an interest in trustless protocol design. But then, this is the internet right? It doesn't matter who you are, only what you have to say. Good ideas should stand on their own, regardless of who advances them.

2. I don't advocate burning more per transation.
If you were going to selectively quote me from https://bitcointalk.org/index.php?topic=395761.msg5053391#msg5053391 then you could at least select this bit: "XCP fees are fully refunded upon BTCpay". It was even in bold. How did you not see it?

(to be clear, I want to see the bare minimum BTC burned per transaction; I don't anticipate my proposal would see anybody ever "burning" much more than the minimum miner fee)


You're aware you're not buying XCP from the developers or something, right? The DEX is an open market where anybody can buy or sell.  "More options" can be given to BTC sellers only at the expense of BTC buyers.

A BTC buyer (ie. "XCP offer") will very obviously always prefer prompt settlement. What possible reason could anyone have to want their BTC buy order to be matched and locked for 150 blocks while they wait for BTCpay (which may never come.) During that 150 blocks the market price may fluctuate. The BTC buyer has no mechanism to back out if the price fluctuates against him. But the BTC seller does have such a mechanism, unfortunately - he can just default on the BTCpay. This gives him a massive advantage, and makes the market essentially unusable.

 

I think --fee_required has been updated in the dev branch to mean "as a percentage of the total order", with a default of 1% (ie. 0.01.) The idea is that you shouldn't need to specify --fee_required, counterpartyd should automatically calculate something appropriate. But if you want to override it, specifying "0.0006" would mean your fee required is 0.06% of the value of your order (ie. very small.)

Example:
If you're ordering, say, 0.02 BTC, and you want the fee to be 0.0001, then you'd set --fee_required=0.005 (ie. half a percent. Because 0.5% of 0.02 BTC == 0.0001.)

This might seem a little weird, but makes very good sense when considered in combination with a new protocol change - proportional matching. For example, there's currently a troll order on the DEX for some absurd amount of XCP, but paying 0.0005 fee. There might be 20 orders on the book that all require 0.0001, and he'll match all of them. With the protocol change, he'd only match the first 0.0005 worth (ie. the first 5 orders) and then his fee would be exhausted and the remainder of his order ineffective. If you had the top sell order on the book, with a 0.002 fee, then he'd only match one quarter of your order and have no effect on anyone else. See?

(Note that I'm not responsible for the implementation (I can't claim to have written a single line of counterpartyd code,) I'm just some guy who thinks it's a good idea and wants to help explain it.)

Please take a look at my suggestion here:
https://forums.counterparty.co/index.php/topic,69.msg340.html#msg340

I'm advocating much higher fees (and, importantly, fees in proportion to the size of the order matched.) But - and this is the catch - I'm also advocating that fees be payable in whatever blend of XCP and BTC the person paying them prefers, and the XCP fees are fully refunded upon BTCpay.

In other words, this would make fees very minimal (ie. just the unavoidable bitcoin network fee) for the vast majority of orders, even really large orders. But it would cost anybody failing to BTCpay heavily, in proportion to the amount of XCP that they matched and then failed to pay for.

Fundamentally, when you match an order, you're committing to buy - you're blocking anybody else from matching it after all. You should be expected to always BTCpay for your orders if you are an honest node. What's more, you should be expected to BTCpay promptly. There's no excuse for matching somebody's order, tying up their funds, and delaying payment.

The BTCpay mechanism isn't intended to be an "option" for people to have the luxuary of locking in a price and deciding later whether to exercise it. It has worked that way so far only by an unfortunate accident in the protocol design - one that can be corrected. Those who want to keep the current "XCP buyer has an option and can choose to exercise it" type behaviour must accept that the trolls also get to use it.

Let's iron it out of the protocol and make this bullet proof. It'll result in cheaper orders for everyone except the trolls, prompt settlements, and a more smoothly functioning market.

That's mighty kind of you; thank you! I'll PM you the relevant txns on the Counterparty Forums regarding your offered reimbursement, which is much appreciated.

I have pulled from master and attempted another purchase to help you test:
http://blockscan.com/order.aspx?q=3337

However, with 6/10 blocks to go until expiry, my offer (buy 5 XCP @ 0.005 BTC per each) so far remains unmatched

At the time I posted my buy order there were no sell orders within an order of magnitude of it. It appears that somebody has swept the order book clean with a ridiculously large offer (which they presumably don't intend to fulfil with BTCPAY) in order to get the front page of blockscan.com to display:
Last DEX Matched Price :     1000.0000 BTC/XCP @ $756,500.000

I can try another test buy later, once the order book straightens itself out. Hope this helps.

I'm not sure there's an easy way to mitigate this attack - does anyone who wants to match my order get automatically matched against the ridiculously high fake one first? I guess they could require a higher fee... and I could pay a higher fee....?

Holy crap, that's me! Well, 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx and 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN at least. Wish I'd seen this thread earlier :-(

Already posted about this here:
https://bitcointalk.org/index.php?topic=406408.20
And here:
https://forums.counterparty.co/index.php/topic,2.0.html

I thought I was up to date. I cloned from master yesterday. Did a git pull from ~/counterpartyd today, but forgot to also run git pull in ~/counterpartyd/dist/counterpartyd , which I'm guessing is what has bitten me.