<unnamed>

Public Key

npub1vdngmkaq73c0aq4fp7xgzjjtp9l66l2t50j7ma242lcp8rleuvls8sc3yk

Profile Code

nprofile1qqsxxe5dmws0gu87s25slrypff9sjlad04968e0d74240uqn3lu7x0cpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqt2s0nh

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:19:43 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On 4/23/2014 3:55 AM, Mike Hearn wrote:
> Lately someone launched Finney attacks as a service (BitUndo). As a
> reminder for newcomers, Finney attacks are where a miner secretly
> works on a block containing a double spend. When they eventually find
> a block, they run to the merchant and pay, then broadcast the block.
> In a simpler variant of this attack you make purchases as normal with
> a modified wallet that always submits a double spend to the service,
> and then N% of the time where N is the percentage of overall hash
> power the dishonest miners have, you get your money back minus their fee.
>
> N does not need to be very high to render Bitcoin much less useful.
> Real time transactions are very important. Although I never expected
> it when I first started using Bitcoin, nowadays most of my purchases
> with it are for food and drink. If Bitcoin could not support such
> purchases, I would use it much less.
> Even with their woeful security many merchants see <1-2% credit card
> chargeback rates, and chargebacks can be disputed. In fact merchants
> win about 40% of chargeback disputes. So if N was only, say, 5%, and
> there was a large enough population of users who were systematically
> trying to defraud merchants, we'd already be having worse security
> than magstripe credit cards. EMV transactions have loss rates in the
> noise, so for merchants who take those Bitcoin would be dramatically
> less secure.
>
> The idea of discouraging blocks that perform Finney attacks by having
> honest miners refuse to build on them has been proposed. But it has a
> couple of problems:
>
> 1. It's hard to automatically detect Finney attacks. Looking for
> blocks that contain unseen transactions that override the mempool
> doesn't work - the dishonest users could broadcast all their
> double spends once a Finney block was found and then broadcast the
> block immediately afterwards, thus making the block look like any
> other would in the presence of double spends.
>
> 2. If they could be automatically identified, it possibly could be
> converted into a DoS on the network by broadcasting double spends
> in such a way that the system races, and every miner produces a
> block that looks like a Finney attack to some of the others. The
> chain would stop advancing.
>
> 3. Miners who want to vote "no" on a block take a big risk, they
> could be on the losing side of the fork and end up wasting their work.
>
> We can resolve these problems with a couple of tweaks:
>
> 1. Dishonest blocks can be identified out of band, by having honest
> miners submit double spends against themselves to the service
> anonymously using a separate tool. When their own double spend
> appears they know the block is bad.
>
> 2. Miners can vote to reallocate the coinbase value of bad blocks
> before they mature. If a majority of blocks leading up to maturity
> vote for reallocation, the value goes into a pot that subsequent
> blocks are allowed to claim for themselves. Thus there is no risk
> to voting "no" on a block, the work done by the Finney attacker is
> not wasted, and users do not have to suffer through huge reorgs.
>
> This may seem a radical suggestion, but I think it's much less radical
> than some of the others being thrown around.
>
> The above approach works as long as the majority of hashpower is
> honest, defined to mean, working to stop double spending. This is the
> same security property as described in the white paper, thus this
> introduces no new security assumptions. Note that assuming
> /all/ miners are dishonest and are willing to double spend
> automatically resolves the Bitcoin experiment as a failure, because
> that would invalidate the entire theory upon which the system is
> built. That doesn't mean the assumption is wrong! It may be that an
> entirely unregulated market for double spending prevention cannot work
> and the participants eventually all end up trashing the commons - but
> the hope is that smart incentives can replace the traditional reliance
> on law and regulation to avoid this.
>
> The voting mechanism would only apply to coinbases, not arbitrary
> transactions, thus it cannot be used to steal arbitrary users
> bitcoins. A majority of miners can already reallocate coinbases by
> forking them out, but this wastes energy and work presenting a
> significant discouragement to vote unless you already know via some
> out of band mechanism that you have a solid majority. Placing votes
> into the coinbase scriptSig as is done with other things avoids that
> problem.
>
> The identification of Finney blocks relies on miners to take explicit
> action, like downloading and running a tool that submits votes via
> RPC. It can be expected that double spending services would try to
> identify and block the sentinel transactions, which is why it's better
> to have the code that fights this arms race be out of process and
> developed externally to Bitcoin Core itself, which should ultimately
> just enforce the new (forking) rule change.
>
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
I have some questions:
1. How can we work towards solving the double-spending problem?
2. Is it possible to "scan" for double-spending and correct it?
3. Is the network at large not secure enough?
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/e1e5bf4e/attachment.html>

2023-06-07 15:19:34 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On 4/23/2014 12:04 PM, Christophe Biocca wrote:
> It's not necessary that this "coinbase retribution" be either
> profitable or risk-free for this scheme to work. I think we should
> separate out the different layers of the proposal:
>
> 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
> time for a consensus to be reached, rather than 10 minutes. This
> allows for human verification/intervention if needed (orphaning
> decisions would almost always need to be automated, due to the short
> timeframe). This is a useful insight, and I don't think it's been
> brought up before.
>
> 2. The original specification of how it's done (redistribution, no
> cost to voting) does seem exploitable. This can be fixed by reducing
> the incentive (burning instead of redistributing) and/or adding a risk
> to the orphaning attempts (a vote that fails destroys X bitcoins'
> worth from each voting block's own coinbase). The incentives can be
> tailored to mirror those of orphaning a block, to reduce the risk of
> abuse. Then the only difference from orphaning are 1) More limited
> rewriting of history (only the coinbase, vs all transactions in the
> block), and 2) More time to coordinate a response.
>
> 3. This proposal may be used for things other than punishing
> double-spend pools. In fact it might be used to punish miners for
> doing anything a significant percentage of hashpower dislikes (large
> OP_RETURNs, large blocks, gambling transactions, transactions banned
> by a government). But we can make the threshold higher than 51%, so
> that this doesn't turn into a significant risk (if 75% of hashpower is
> willing to enforce a rule, we're already likely to see it enforced
> through orphaning).
>
> On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
>>> And it still would. Non-collusive miners cast votes based on the outcome
>>> of their own attempts to double spend.
>>
>> Individually rational strategy is to vote for coinbase reallocation on every
>> block.
>>
>> Yes, in that case nobody will get reward. It is similar to prisoner's
>> dilemma: equilibrium has worst pay-off.
>> In practice that would mean that simple game-theoretic models are no longer
>> applicable, as they lead to absurd results.
>>
>>> I'm using it in the same sense Satoshi used it. Honest miners work to
>>> prevent double spends. That's the entire justification for their existence.
>>> Miners that are deliberately trying to double spend are worse than useless.
>>
>> Miners work to get rewards.
>> It absolutely doesn't matter whether they are deliberately trying to
>> double-spend or not: they won't be able to double-spend without a collusion.
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
This all sounds verry restrictive. Is it possible to do a "sweep" in
order to "clean up" double spending? Why punish miners for the sake of
punishing them?
--
Kevin