Good morning Mike,
> I think that this implication affects other applications built on the
> blockchain, not just the PubRef proposal:
>
I believe not?
Current applications use txids to refer to previous transactions, so even a
short-ranged history rewrite will mostly not affect them --- they
ZmnSCPxj,
I think that this implication affects other applications built on the
blockchain, not just the PubRef proposal:
> There is a potential for a targeted attack where a large payout going to
a `scriptPubKey` that uses `OP_PUBREF` on a recently-confirmed transaction
finds that recently-con
Good morning Mike,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Sunday, July 28, 2019 4:03 AM, Mike Brooks wrote:
> Hey ZmnSCPxj,
>
> As to your first point. I wasn't aware there was so much volatility at the
> tip, also 100 blocks is quite the difference! I agree
In summary I see three mechansims of making use costly:
1. burn
2. time locked funds, locker will incure opportunity cost
3. proven coin age, holder did incure opportunity cost
I dislike burn as usage of a service is infinite while coin supply is finite.
I prefer time locked funds over coin age
Hi David,
Aquiring coin age is hard not only for an attacker but for any user that
happened to move his funds lately.
Even if coin age is available, proofs of using it to fund a particular operation
are not sybill resistant. Only a centralized service would know for sure that
proof is only used o
