<<  >> (p.2)
    Author Topic: Creating Bitcoin passports using sacrifices  (Read 12980 times)
    Peter Todd
    Legendary
    *
    expert
    Offline Offline

    Activity: 1134
    Merit: 1222


    View Profile
    February 11, 2013, 02:31:51 PM
     #21

    Quote
    Is this really an issue? Well, I think the the question really is why would you use a sacrifice method where the value is so sensitive to so many variables? In particularly, a method where the actual cost of the sacrifice is inversely and exponentially dependent on the size of the largest miner.

    You said yourself, the orphan rate is not only measurable but also quite low. I'm not sure it's really that complicated.

    Re-read what I wrote. A low orphan rate is what makes the attack possible. Assuming it is always zero is the conservative way of estimating sacrifice value. More to the point, the real issue is the sensitivity to mining power; try experimenting with plotting the cost vs. hashing power curve. It's a very, very fast decline to zero as you get close to even just 20%, whereas tx-in-tx is just a straight linear line from 0% to 100% and doesn't require any analysis.

    And again, it only takes a small orphan rate to mess up multiple tx schemes by dramatically increasing the difficulty of getting a valid set of consecutive transactions. You said it yourself that miners don't appear to always be rational profit-driven entities. All you need is some that have a grudge against your service for whatever silly reason.


    So then sites that are using passports to avoid being abused just set the multiplier in their config file to 0.7 and they're done. The actual multiplier can be updated every so often and re-distributed ... no big deal as the operators who are accepting these passports already need to share blacklists and so on for the system to work.

    You know, I think this gets to the core of my objection: why settle for a system that requires all this maintenance? For tx-in-tx you can set the discount to 0.5 on the assumption that if >50% of the hashing power is controlled you're screwed anyway. Done. If you're particular use allows for resale you will need to check that the secondary market hasn't crashed, but that's true regardless of how the sacrifices are created.

    Ultimately I understand that passports probably don't really need iron-clad security, and do need lots of human intervention for other reasons. But the cost of getting the best security possible, short of just sending value to unspendable txouts, is pretty low, and it does make for shorter proofs than multiple-tx schemes. (if n > 2)

    It's only real disadvantages is the need to ensure the signatures on the published sacrificial tx are valid, a potentially tricky bit of code, the fact that the initial announcement tx is (currently) non-standard, and the need to write a blockchain watching bot to recognize the sacrificial txs and broadcast them. (or add them to the local mempool and try to mine them yourself) I just don't see those three issues as major problems, and I'd much rather see your passports use the same system as fidelity bonded coin transfer services and whatever else people come up with so efforts can be focused on getting one solid system rather than a couple of incomplete ones.

Page 1
Viewing Page: 2