What is Nostr?
Adrian Macneil [ARCHIVE] /
npub18pl…2ml4
2023-06-07 15:38:56
in reply to nevent1q…l56x

Adrian Macneil [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-19 📝 Original message:> > Unless you're sybil ...

📅 Original date posted:2015-06-19
📝 Original message:>
> Unless you're sybil attacking the network and miners, consuming valuable
> resources and creating systemic risks of failure like we saw with
> Chainalysis, I don't see how you're getting "very small" double-spend
> probabilities.
>

So connecting to many nodes just because we can and it's not technically
prevented is bad for the network and creating systemic risks of failure,
but relaying harmful double spend transactions just because you can and
it's not technically prevented, is good for everyone?


> You know, you're creating an interesting bit of game theory here: if I'm
> a miner who doesn't already have a mining contract, why not implement
> full-RBF to force Coinbase to offer me one? One reason might be because
> other miners with such a contract - a majority - are going to be asked
> by Coinbase to reorg you out of the blockchain, but then we have a
> situation where a single entity has control of the blockchain.
>

If someone did enter into contracts with miners to mine certain
transactions, and had a guarantee that the miners would not build on
previous blocks which included double spends, then they would only need
contracts with 51% of the network anyway. So it wouldn't really matter if
you were a small time miner and wanted to run full-RBF.


> For the good of Bitcoin, and your own company, you'd do well to firmly
> state that under no condition will Coinbase ever enter into mining
> contracts.
>

I don't personally see what good this does for bitcoin. Now you are
suggesting that we should prevent a 51% attack by using policy and
promises, rather than a technical solution. How is this any better than us
relying on existing double spend rules which are based on policy and
promises?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/ad6b6736/attachment.html>;
Author Public Key
npub18plyg5mfmzwlvkcx0fhudfll3x5phjvvlglw4dgj6t5ehyp87ttqzv2ml4