Adrian Macneil [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-04-09 to 2015-12-31
💬 Posted a total of 9 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:47:27

- reply

📅 Original date posted:2015-12-31
📝 Original message:I'm not sure if anyone has suggested this in the past, but a novel approach
would be to simply let anyone open a pull request and use the PR # as the
BIP #. This would avoid conflicts, and avoid the chore of having someone
manually assign them.
Downside would be that some numbers will never get used (for example if PRs
are opened to update existing BIPs), but this doesn't seem to be a huge
problem since already many numbers are going unused.
This process can still be independent from approving/merging the BIP into
master, if it meets quality standards.
On Thu, Dec 31, 2015 at 3:14 PM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 30, 2015 at 05:42:47PM +0100, Marco Pontello via bitcoin-dev
> wrote:
> > Sorry to ask again but... what's up with the BIP number assignments?
> > I thought that it was just more or less a formality, to avoid conflicts
> and
> > BIP spamming. And that would be perfectly fine.
> > But since I see that it's a process that can take months (just looking at
> > the PR request list), it seems that something different is going on.
> Maybe
> > it's considered something that give an aura of officiality of sorts? But
> > that would make little sense, since that should come eventually with
> > subsequents steps (like adding a BIP to the main repo, and eventual
> > approvation).
> >
> > Having # 333 assigned to a BIP, should just mean that's easy to refer to
> a
> > particular BIP.
> > That seems something that could be done quick and easily.
> >
> > What I'm missing? Probably some historic context?
>
> You ever noticed how actually getting a BIP # assigned is the *last*
> thing the better known Bitcoin Core devs do? For instance, look at the
> segregated witness draft BIPs.
>
> I think we have problem with peoples' understanding of the Bitcoin
> consensus protocol development process being backwards: first write your
> protocol specification - the code - and then write the human readable
> reference explaining it - the BIP.
>
> Equally, without people actually using that protocol, who cares about
> the BIP?
>
>
> Personally if I were assigning BIP numbers I'd be inclined to say "fuck
> it" and only assign BIP numbers to BIPs after they've had significant
> adoption... It'd might just cause a lot less headache than the current
> system.
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000006808135a221edd19be6b5b966c4621c41004d3d719d18b7
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151231/5214ee14/attachment.html>

2023-06-07 15:42:24

- reply

📅 Original date posted:2015-07-15
📝 Original message:> With my white hat on
> Shapeshift.io lost ~3 BTC this week in multiple txs
I assume as a self proclaimed "white hat", you contacted the relevant
companies and returned their funds? Theft is still theft, regardless of
whether you are doing it for research or not.
On Tue, Jul 14, 2015 at 8:29 PM, simongreen--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> With my black hat on I recently performed numerous profitable double-spend
> attacks against zeroconf accepting fools. With my white hat on, I'm warning
> everyone. The strategy is simple:
>
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc. anything
> that miners don't always accept.
>
> tx2: After merchant gives up valuable thing in return, normal tx without
> triggering spam protections. (loltasticly a Mike Hearn Bitcoin XT node was
> used to relay the double-spends)
>
> Example success story: tx1 paying Shapeshift.io with 6uBTC output is not
> dust under post-Hearn-relay-drop rules, but is dust under
> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not paying
> Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all miners who have
> reverted Hearn's 10x relay fee drop as recommended by v0.11.0 release notes
> and accept these double-spends. Shapeshift.io lost ~3 BTC this week in
> multiple txs. (they're no longer accepting zeroconf)
>
> Example success story #2: tx1 with post-Hearn-relay drop fee, followed by
> tx2 with higher fee. Such stupidly low fee txs just don't get mined, so
> wait for a miner to mine tx2. Bought a silly amount of reddit gold off
> Coinbase this way among other things. I'm surprised that reddit didn't
> cancel the "fools-gold" after tx reversal. (did Coinbase guarantee those
> txs?) Also found multiple Bitcoin ATMs vulnerable to this attack. (but
> simulated attack with tx2s still paying ATM because didn't want to go to
> trouble of good phys opsec)
>
> Shoutouts to BitPay who did things right and notified merchant properly
> when tx was reversed.
>
> In summary, every target depending on zeroconf vulnerable and lost
> significant sums of money to totally trivial attacks with high probability.
> No need for RBF to do this, just normal variations in miner policy.
> Shapeshift claims to use Super Sophisticated Network Sybil Attacking
> Monitoring from Blockcypher, but relay nodes != miner policy.
>
> Consider yourself warned! My hat is whiter than most, and my skills not
> particularly good.
>
> What to do? Users: Listen to the experts and stop relying on zeroconf.
> Black hats: Profit!
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150715/3b6fa212/attachment.html>

2023-06-07 15:39:03

- reply

📅 Original date posted:2015-06-19
📝 Original message:Extremely disappointed to hear this. This change turns double spending from
a calculable (and affordable) risk for merchant payment processors into
certain profit for scammers, and provides no useful benefit for consumers.
I sincerely hope that F2Pool reconsider, given that RBF will decrease the
overall utility of bitcoin and reduce the number of people using it for
online purchases.
Adrian
On Fri, Jun 19, 2015 at 6:33 AM, Stephen Morse <stephencalebmorse at gmail.com>
wrote:
> It is disappointing that F2Pool would enable full RBF when the safe
> alternative, first-seen-safe RBF, is also available, especially since the
> fees they would gain by supporting full RBF over FSS RBF would likely be
> negligible. Did they consider using FSS RBF instead?
>
> Best,
> Stephen
>
> On Fri, Jun 19, 2015 at 6:39 AM, Peter Todd <pete at petertodd.org> wrote:
>
>> Yesterday F2Pool, currently the largest pool with 21% of the hashing
>> power, enabled full replace-by-fee (RBF) support after discussions with
>> me. This means that transactions that F2Pool has will be replaced if a
>> conflicting transaction pays a higher fee. There are no requirements for
>> the replacement transaction to pay addresses that were paid by the
>> previous transaction.
>>
>>
>> I'm a user. What does this mean for me?
>> ---------------------------------------
>>
>> In the short term, very little. Wallet software aimed at average users
>> has no ability to reliably detect conditions where an unconfirmed
>> transaction may be double-spent by the sender. For example, Schildbach's
>> Bitcoin Wallet for Android doesn't even detect double-spends of
>> unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
>> that propagate them. The least sophisticated double-spend attack
>> possibly - simply broadcasting two conflicting transactions at the same
>> time - has about 50% probability of success against these wallets.
>>
>> Additionally, SPV wallets based on bitcoinj can't even detect invalid
>> transactions reliably, instead trusting the full node(s) it is connected
>> too over the unauthenticated, unencrypted, P2P protocol to do validation
>> for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
>> double-spends that spend the output of the conflicting transaction. I've
>> personally tested this with Schildbach's Bitcoin Wallet for Android,
>> which shows such invalid transactions as standard, unconfirmed,
>> transactions.
>>
>> Users should continue to assume that unconfirmed transactions could be
>> trivially reversed by the sender until the first confirmation. In
>> general, only the sender can reverse a transaction, so if you do trust
>> the sender feel free to assume an unconfirmed transaction will
>> eventually confirm. However, if you do not trust the sender and/or have
>> no other recourse if they double-spend you, wait until at least the
>> first confirmation before assuming the transaction will go through.
>>
>> In the long term, miner support of full RBF has a number of advantages
>> to users, allowing you to more efficiently make transactions, paying
>> lower fees. However you'll need a wallet supporting these features; none
>> exist yet.
>>
>>
>> I'm a business. What does this mean for me?
>> -------------------------------------------
>>
>> If you use your own node to verify transactions, you probably are in a
>> similar situation as average users, so again, this means very little to
>> you.
>>
>> If you use a payment processor/transaction API such as BitPay, Coinbase,
>> BlockCypher, etc. you may or may not be accepting unconfirmed
>> transactions, and they may or may not be "guaranteed" by your payment
>> processor even if double-spent. If like most merchants you're using the
>> API such that confirmations are required prior to accepting orders (e.g.
>> taking a meaningful loss such as shipping a product if the tx is
>> reversed) nothing changes for you. If not I recommend you contact your
>> payment processor.
>>
>>
>> I'm a miner. Why should I support replace-by-fee?
>> -------------------------------------------------
>>
>> Whether full or first-seen-safe⁵ RBF support (along with
>> child-pays-for-parent) is an important step towards a fully functioning
>> transaction fee market that doesn't lead to users' transactions getting
>> mysteriously "stuck", particularly during network flooding
>> events/attacks. A better functioning fee market will help reduce
>> pressure to increase the blocksize, particularly from the users creating
>> the most valuable transactions.
>>
>> Full RBF also helps make use of the limited blockchain space more
>> efficiently, with up to 90%+ transaction size savings possible in some
>> transaction patterns. (e.g. long payment chains⁶) More users in less
>> blockchain space will lead to higher overall fees per block.
>>
>> Finally as we'll discuss below full RBF prevents a number of serious
>> threats to the existing level playing field that miners operate in.
>>
>>
>> Why can't we make accepting unconfirmed txs from untrusted people safe?
>> -----------------------------------------------------------------------
>>
>> For a decentralized wallet, the situation is pretty bleak. These wallets
>> only have a handful of connections to the network, with no way of
>> knowing if those connections give an accurate view of what transactions
>> miners actually know about.
>>
>> The only serious attempt to fix this problem for decentralized wallets
>> that has been actually deployed is Andresen/Harding's double-spend
>> relaying, implemented in Bitcoin XT. It relays up to one double-spend
>> transaction per double-spent txout, with the intended effect to warn
>> recipients. In practice however this functionality makes it easier to
>> double-spend rather than harder, by giving an efficient and easy way to
>> get double-spends to miners after the fact. Notably my RBF
>> implementation even connects to Bitcoin XT nodes, reserving a % of all
>> incoming and outgoing connection slots for them.
>>
>> Additionally Bitcoin XT's double-spend relaying is subject to attacks
>> include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
>> interactive attacks⁷ among many others.
>>
>>
>> What about centralised wallets?
>> -------------------------------
>>
>> Here the solutions being deployed, planned, and proposed are harmful,
>> and even represent serious threats to Bitcoin's decentralization.
>>
>>
>> Confidence factors
>> ------------------
>>
>> Many services such as BlockCypher² have attempted to predict the
>> probability that unconfirmed transactions will be mined, often
>> guaranteeing merchants payment³ even in the event of a double-spend. The
>> key component of these predictions is to sybil attack the P2P network as
>> a whole, connecting to as many nodes as possible to measure transaction
>> propagation. Additionally these services connect to pools directly via
>> the getblocktemplate protocol, repeatedly downloading via GBT the lists
>> of transactions in the to-be-mined blocks to determine what transactions
>> miners are attempting to mine.
>>
>> None of these measures scale, wasting significant network and miner
>> resources; in one instance a sybil attack by Chainalysis even completely
>> blocked the users of the SPV wallet Breadwallet⁴ from accessing the
>> network. These measures also don't work very well, giving double-spend
>> attackers incentives to sybil attack miners themselves.
>>
>>
>> Transaction processing contracts with miners
>> --------------------------------------------
>>
>> The next step after measuring propagation fails is to contract with
>> miners directly, signing contracts with as much of the hashing power as
>> possible to get the transactions they want mined and double-spends
>> rejected. The miners/pools would then provide an authenticated API
>> endpoint for exclusive use of this service that would allow the service
>> to add and remove specific transactions to the mempool on demand.
>>
>> There's a number of serious problems with this:
>>
>> 1) Mining contracts can be used to double-spend
>>
>> ...even when they're being used "honestly".
>>
>> Suppose Alice is a merchant using CoinPayCypher, who has contracts with
>> 75% of the hashing power. Bob, another merchant, meanwhile uses a
>> decentralized Bitcoin Core backend for payments to his website.
>>
>> Mallory wants to double-spend Bob's to buy his expensive products. He
>> can do this by creating a transaction, tx1, that pays Alice, followed by
>> a second transaction, tx2, that pays Bob. In any circumstance when
>> Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
>> the chance of Malory's double-spend succeeding becomes ~75% because
>> CoinPayCypher's contracts with mining ensure the transaction paying
>> Alice will get mined.
>>
>> Of course, dishonest use and/or compromise makes double-spending
>> trivial: Malory can use the API credentials to ask miners to reject
>> Bob's payment at any time.
>>
>>
>> 2) They still don't work, without 51% attacking other miners
>>
>> Even if CoinPayCypher has 75% of the hashing power on contract, that's
>> still a potentially 75% chance of being double-spent. The 25% of miners
>> who haven't signed contracts have no _decentralized_ way of ensuring
>> they don't create blocks with double-spends, let alone at low cost. If
>> those miners won't or can't sign contracts with CoinPayCypher the only
>> next step available is to reject their blocks entirely.
>>
>>
>> 3) Legal contracts give the advantage to non-anonymous miners in
>> Western jurisdictions
>>
>> Suppose CoinPayCypher is a US company, and you're a miner with 1%
>> hashing power located in northern China. The barriers to you succesfully
>> negotiating a contract with CoinPayCypher are significant. You don't
>> speak the same langauge, you're in a completely different jurisdiction
>> so enforcing the legal contract is difficult, and being just 1%,
>> CoinPayCypher sees you as insignificant.
>>
>> Who's going to get the profitable hashing power contracts first, if at
>> all? Your English speaking competitors in the west. This is inherently a
>> pressure towards centralization of mining.
>>
>>
>> Why isn't this being announced on the bitcoin-security list first?
>> ------------------------------------------------------------------
>>
>> I've had repeated discussions with services vulnerable to double-spends;
>> they have been made well aware of the risk they're taking. If they've
>> followed my own and others' advice they'll at minimum have constant
>> monitoring of the rate of double-spends both on their own services and
>> on the P2P network in general.
>>
>> If you choose to take a risk you should accept the consequences.
>>
>>
>> How do I actually use full RBF?
>> -------------------------------
>>
>> First get the full-RBF patch to v0.10.2:
>>
>> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2
>>
>> The above implementation of RBF includes additional code to find and
>> preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
>> Secondly, try out my replace-by-fee-tools at:
>>
>> https://github.com/petertodd/replace-by-fee-tools
>>
>> You can watch double-spends on the network here:
>>
>> http://respends.thinlink.com/
>>
>>
>> References
>> ----------
>>
>> 1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
>> variants of existing attacks w/ Bitcoin XT and Android Bitcoin
>> Wallet",
>> Peter Todd, May 23rd 2015, Bitcoin-development mailing list,
>>
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html
>>
>> 2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
>> June 2nd, 2014, Erik Voorhees,
>>
>> https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
>>
>> 3) Coinbase Merchant API, Accessed Jun 19th 2015,
>> https://developers.coinbase.com/docs/merchants/callbacks#confirmations
>>
>> 4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
>> March 14th 2015, Grace Caffyn, Coindesk,
>>
>> http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
>>
>> 5) "First-Seen-Safe Replace-by-Fee",
>> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>>
>> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
>>
>> 6) "Cost savings by using replace-by-fee, 30-90%",
>> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>>
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
>>
>> 7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
>> Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan
>> Capkun,
>> Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
>> http://eprint.iacr.org/2015/578
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/54877f1f/attachment.html>

2023-06-07 15:39:01

- reply

📅 Original date posted:2015-06-19
📝 Original message:Great. Thank you for this!
Adrian
On Fri, Jun 19, 2015 at 7:40 AM, Chun Wang <1240902 at gmail.com> wrote:
> On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil <adrian at coinbase.com>
> wrote:
> > However, we do rely pretty heavily on zeroconf transactions for merchant
> > processing, so if any significant portion of the mining pools started
> > running your unsafe RBF patch, then we would probably need to look into
> this
> > as a way to prevent fraud.
>
> This might be useful to you: https://www.f2pool.com/api/mempool
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/d962d207/attachment.html>

2023-06-07 15:38:57

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> > 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,
>
> Well it is actually; that's why myself, Wladimir van der Laan, and
> Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
> attack.
>
> The Bitcoin P2P network is resilliant to failure when the chance of any
> one node going down is uncorrelated with others. For instance if you
> accidentally introduced a bug in your nodes that failed to relay
> transactions/blocks properly, you'd simultaneously be disrupting a large
> portion of the network all at once.
>
This is exactly what your RBF patch is doing. By your own logic, nodes on
the network should be allowed to relay (or not relay) whatever they wish.
> How many nodes is Coinbase connecting too? What software are they
> running? What subnets are they using? In particular, are they all on one
> subnet or multiple?
>
We're running about a dozen nodes running regular Bitcoin Core in various
subnets. We aren't doing anything particularly out of the ordinary here.
Nothing that would fall under your definition of a sybil attack or harmful
to the network.
> > 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.
>
> But of course, you'd never 51% the network right? After all it's not
> possible to guarantee that your miner won't mine double-spends, as there
> is no single consensus definition of which transaction came first, nor
> can there be.
>
> Or do you see things differently? If I'm a small miner should I be
> worried my blocks might be rejected by the majority with hashing power
> contracts because I'm unable to predict which transactions Coinbase
> believes should go in the blockchain?
>
You seem so concerned that we are actively trying to harm or control the
network. We're simply trying to drive bitcoin adoption by making it easy
for people to spend their bitcoin with merchants online. The problems we
face are no different from other merchant processors, or small independent
merchants accepting online or point-of-sale payments.
We've historically had relatively little interest in what miners were doing
(until RBF came out) - for the most part it didn't affect our business.
However, most large merchants would be simply uninterested in accepting
bitcoin if we forced their customers to wait 10-60 minutes for their
payments to confirm. Many have inventory management systems which can not
even place items on hold that long.
If full-RBF sees any significant adoption by miners, then it will actively
harm bitcoin adoption by reducing or removing the ability for online or POS
merchants to accept bitcoin payments at all. I do not see a single benefit
to running full-RBF.
FWIW, I'm fine with the first-seen-safe RBF, that seems like a sensible
addition and a good way to allow fees to be added or increased on existing
transactions, without harming existing applications of bitcoin.
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/67e0dce0/attachment.html>

2023-06-07 15:38:56

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> > We have no contracts in place or plans to do this that I am aware of.
> >
> > However, we do rely pretty heavily on zeroconf transactions for merchant
> > processing, so if any significant portion of the mining pools started
> > running your unsafe RBF patch, then we would probably need to look into
> > this as a way to prevent fraud.
>
> What happens if the mining pools who are mining double-spends aren't
> doing it delibrately? Sybil attacking pools appears to have been done
> before to get double-spends though, equally there are many other changes
> the reduce the reliability of transaction confirmations. For instance
> the higher demands on bandwidth of a higher blocksize will inevitably
> reduce the syncronicity of mempools, resulting in double-spend
> opportunities. Similarly many proposals to limit mempool size allow
> zeroconf double-spends.
>
> In that case would you enter into such contracts?
>
We take it as it comes.
Currently, it's perfectly possible to accept zeroconf transactions with
only a very small chance of double spend. As long as it's only possible to
double spend a small fraction of the time, it's an acceptable cost to us in
exchange for being able to provide a fast checkout experience to customers
and merchants.
If the status quo changes, then we will need to investigate alternatives
(which realistically would include mining contracts, or only accepting
instant payments from other trusted hosted wallets, which would be a net
loss for decentralization).
Long term we would prefer to see an open, decentralized solution, such as
payment channels / green addresses / lightening networks. However, I think
as a community we are a long way away from choosing a standard here and
implementing it across all popular wallet software and merchant processors.
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/e0ee9118/attachment.html>

2023-06-07 15:38:56

- reply

📅 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>

2023-06-07 15:38:55

- reply

📅 Original date posted:2015-06-19
📝 Original message:>
> For instance, if Coinbase had
> contracts with 80% of the Bitcoin hashing power to guarantee their
> transactions would get mined, but 20% of the hashing power didn't sign
> up, then the only way to guarantee their transactions could be for the
> 80% to not build on blocks containing doublespends by the 20%.
>
This seems to be more of a problem with centralized mining than zeroconf
transactions.
Speaking of, could we get a confirmation that Coinbase is, or is not,
> one of the merchant service providers trying to get hashing power
> contracts with mining pools for guaranteed transaction acceptance? IIRC
> you are still an advisor to them. This is a serious concern for the
> reasons I outlined in my post.
>
We have no contracts in place or plans to do this that I am aware of.
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into
this as a way to prevent fraud.
In the long term, I would love to see a safe, decentralized solution for
accepting zeroconf transactions. However, right now there is no such
solution supported by any wallets in use, and I don't think breaking the
current bitcoin behavior for everyone is the best way to achieve this.
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/f769ac6f/attachment.html>

2023-06-07 15:32:26

- reply

📅 Original date posted:2015-04-09
📝 Original message:Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide adoption of RBF (without a suitable replacement available) would make it extremely difficult to pitch bitcoin as a viable alternative to credit cards payments to large merchants.
Adrian
> On Mar 28, 2015, at 7:22 AM, Peter Todd <pete at petertodd.org> wrote:
>
> Signed PGP part
> Would you so us all a favor and make a list of companies *actually* relying on "first-seen" mempool behaviour. Because I've been having a hard time actually finding anyone who does who hasn't given up on it. Not very useful to talk about attacks against hypothetical defences.
>
> On 28 March 2015 09:58:53 GMT-04:00, Mike Hearn <mike at plan99.net> wrote:
> >I've written a couple of blog posts on replace by fee and double
> >spending
> >mitigations. They sum up the last few years (!) worth of discussions on
> >this list and elsewhere, from my own perspective.
> >
> >I make no claim to be comprehensive or unbiased but I keep being asked
> >about these topics so figured I'd just write up my thoughts once so I
> >can
> >send links instead of answers :) And then so can anyone who happens to
> >agree.
> >
> >(1) Replace by fee scorched earth, a counter argument:
> >
> >https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
> >
> >This article lays out the case against RBF-SE and argues it is harmful
> >to
> >Bitcoin.
> >
> >(2) Double spending and how to make it harder:
> >
> >https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008
> >
> >This article summarises a couple of double spending incidents against
> >merchants and then discusses the following techniques:
> >
> > 1. Risk analysis of transactions
> > 2. Payment channels
> > 3. Countersigning by a trusted third party
> > 4. Remote attestation
> > 5. ID verification
> > 6. Waiting for confirmations
> > 7. Punishment of double spending blocks
> >
> >I hope the material is useful / interesting.
> >
> >
> >------------------------------------------------------------------------
> >
> >------------------------------------------------------------------------------
> >Dive into the World of Parallel Programming The Go Parallel Website,
> >sponsored
> >by Intel and developed in partnership with Slashdot Media, is your hub
> >for all
> >things parallel software development, from weekly thought leadership
> >blogs to
> >news, videos, case studies, tutorials and more. Take a look and join
> >the
> >conversation now. http://goparallel.sourceforge.net/
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150408/35a58f48/attachment.sig>