Andrew Baine [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-03-28 to 2023-05-11
💬 Posted a total of 2 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:21:39

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: It's easy to work around rules that deny mempool inclusion based on fee proportion by adding inputs from your own wallet or borrowing them.
📝 Original message:Regardless of the submitter's rationale, it is easy to work around any rule
that denies mempool inclusion based on fee proportion: if you have plenty,
add inputs from your own wallet and return to yourself; if not, borrow them
and return to the lender, maybe with interest.
On Thu, May 11, 2023 at 9:27 AM Kalle Rosenbaum via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Another use case for paying more fees than outputs is to incentivize
> honest mining when Bitcoin is under a state-level censorship attack.
> If it's really important to me that my transaction goes through, I
> might be willing to set a fee at 99x the output value. It's the only
> way bitcoin could work in an adversarial environment.
>
> /Kalle
>
> On Thu, 11 May 2023 at 13:55, vjudeu via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > confused. the rule was "cannot pay a fee > sum of outputs with
> consideration of cpfp in the mempool"
> > > your example is of someone paying a fee "< sum" which wouldn't be
> blocked
> >
> > Every transaction paying "fee > sum" can be replaced by N transactions
> paying "fee <= sum", where the sum of all fees will be the same. That
> means, someone will still do the same thing, but it will be just expanded
> into N transactions, so you will reach the same outcome, but splitted into
> more transactions. That means, mempool will be even more congested, because
> for example instead of 1kB transaction with huge fee, you will see 100 such
> transactions with smaller fees, that will add to the same amount, but will
> just consume more space.
> >
> > > show me how someone could move 1 btc and pay 2 btc as fees...
> >
> > In the previous example, I explained how someone could move 1k sats and
> pay almost 1 BTC as fees. But again, assuming that you have 3 BTC, and you
> move 1 BTC with 2 BTC fee, that will be rejected by your rules if and only
> if that will be done in a single transaction. But hey, the same owner can
> prepare N transactions upfront, and release them all at the same time,
> Segwit makes it possible without worrying about malleability.
> >
> > So, instead of:
> >
> > 3 BTC -> 1 BTC
> >
> > You can see this:
> >
> > 3 BTC -> 2 BTC -> 1 BTC
> >
> > If that second transaction will not pass CPFP, more outputs could be
> used:
> >
> > +--------------------+--------------------+--------------------+
> > | 3.0 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC |
> > | 0.5 BTC | 0.5 BTC 0.5 BTC | 0.5 BTC |
> > | 0.5 BTC | 0.5 BTC +--------------------+
> > | +--------------------+
> > | 0.5 BTC | 0.5 BTC -> 0.5 BTC |
> > | 0.5 BTC | 0.5 BTC |
> > +--------------------+--------------------+
> >
> > As you can see, there are four transactions, each paying 0.5 BTC fee, so
> the total fee is 2 BTC. However, even if you count it as CPFP, you will get
> 1.5 BTC in fees for the third transaction in the chain. Note that more
> outputs could be used, or they could be wired a bit differently, and then
> if you will look at the last transaction, the sum of all fees from 10 or 15
> transactions in that chain, could still pass your limits, but the whole
> tree will exceed that. If you have 1.5 BTC limit for that 3 BTC, then you
> could have 20 separate chains of transactions, each paying 0.1 BTC in fees,
> and it will still sum up to 2 BTC.
> >
> > > the only way around it is to maintain balances and use change
> addresses. which would force nft and timestamp users to maintain these
> balances and would be a deterrent
> >
> > Not really, because you can prepare all of those transactions upfront,
> as the part of your protocol, and release all of them at once. You don't
> have to maintain all UTXOs in between, you can create the whole transaction
> tree first, sign it, and broadcast everything at once. More than that: if
> you have HD wallet, you only need to store a single key, and generate all
> addresses in-between on-the-fly, as needed. Or even use some algorithm to
> deterministically recreate the whole transaction tree.
> >
> >
> >
> > On 2023-05-10 19:42:49 user Erik Aronesty <erik at q32.com> wrote:
> > confused. the rule was "cannot pay a fee > sum of outputs with
> consideration of cpfp in the mempool"
> >
> >
> > your example is of someone paying a fee "< sum" which wouldn't be
> blocked
> >
> >
> > note: again, i'm not a fan of this, i like the discussion of "bitcoin as
> money only" and using fee as a lever to do that
> >
> >
> > show me how someone could move 1 btc and pay 2 btc as fees... i think we
> can block it at the network or even the consensus layer, and leave anything
> but "non-monetary use cases" intact. the only way around it is to
> maintain balances and use change addresses. which would force nft and
> timestamp users to maintain these balances and would be a deterrent
> >
> >
> > im am much more in favor of doing something like op_ctv which allows
> many users to pool fees and essentially "share" a single utxo.
> > .
> >
> >
> >
> > On Wed, May 10, 2023 at 12:19 PM <vjudeu at gazeta.pl> wrote:
> >
> > > possible to change tx "max fee" to output amounts?
> >
> > Is it possible? Yes. Should we do that? My first thought was "maybe",
> but after thinking more about it, I would say "no", here is why:
> >
> > Starting point: 1 BTC on some output.
> > Current situation: A single transaction moving 0.99999000 BTC as fees,
> and creating 1000 satoshis as some output (I know, allowed dust values are
> lower and depend on address type, but let's say it is 1k sats to make
> things simpler).
> >
> > And then, there is a room for other solutions, for example your rule,
> mentioned in other posts, like this one:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021626.html
> >
> > > probably easier just to reject any transaction where the fee is higher
> than the sum of the outputs
> >
> > Possible situation after introducing your proposal, step-by-step:
> >
> > 1) Someone wants to move 1 BTC, and someone wants to pay 0.99999000 BTC
> as fees. Assuming your rules are on consensus level, the first transaction
> creates 0.5 BTC output and 0.5 BTC fee.
> > 2) That person still wants to move 0.5 remaining BTC, and still is
> willing to pay 0.49999000 BTC as fees. Guess what will happen: you will see
> another transaction, creating 0.25 BTC output, and paying 0.25 BTC fee.
> > ...
> > N) Your proposal replaced one transaction, consuming maybe one kilobyte,
> with a lot of transactions, doing exactly the same, but where fees are
> distributed between many transactions.
> >
> > Before thinking about improving that system, consider one simple thing:
> is it possible to avoid "max fee rule", no matter in what way it will be
> defined? Because as shown above, the answer seems to be "yes", because you
> can always replace a single transaction moving 1 BTC as fees with multiple
> transactions, each paying one satoshi per virtual byte, and then instead of
> consuming around one kilobyte, it would consume around 1 MvB per 0.01 BTC,
> so 100 MvB per 1 BTC mentioned in the example above.
> >
> >
> >
> > On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > possible to change tx "max fee" to output amounts?
> >
> >
> > seems like the only use case that would support such a tx is spam/dos
> type stuff that satoshi warned about
> >
> >
> > its not a fix for everything, but it seems could help a bit with certain
> attacks
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> 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/20230511/b1e6113e/attachment.html>

2023-06-07 17:57:35

- reply

📅 Original date posted:2017-03-28
📝 Original message:The bitcoin ecosystem is better off the more transactions are propogated
peer-to-peer than directly to miners. We want miners listening to the
network, not soliciting transactions directly from users. You whispering
your transactions to your miner-of-choice while I whisper to mine
contravenes a critical value-add of the peer-to-peer network in my opinion.
On Tue, Mar 28, 2017 at 10:35 AM Martin Stolze via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi AJ,
> That's outstanding. I am glad to see that there is actually somebody
> who has made some progress.
>
> > "miners as service providers."
> Great idea! Block space as a resource is under-analyzed.
>
> > miner/pool's political positions, their consensus ideology, physical
> location (yes some people would like only miners in particular countries to
> mine their transactions)
>
> I am not joking when I say that in 3 to 8 years, I want to be able to
> verify my transaction through green blocks that are generated locally
> by my neighbor through the excess capacity of his solar panels or by
> an NGO pool that promotes solar deployment around the equator.
>
> > The main attitude right now is that people would like to 'support'
> miners who signal for the features they care about.
>
> Yes, just selecting all SegWit signaling hash power instead of picking
> individual Authorities would be helpful on preferredminer.com
>
> > I strongly believe, whether the Bitcoin developer community facilitates
> it or not, certain miners will become preferred by users.
>
> Absolutely, considering the recent language used in opinions by the
> ECB and drafts by the EU I see them assembling the artillery. I
> wouldn't be surprised if they start target practice next year. That
> will mean that commercial interest must have a way to transact on
> somewhat regulated space.
>
> > 1) By creating 'segregated mempools' where an authenticated third-party
> like my web service Preferred Miner manages the access to pending
> transactions destined for a specific set of miners
>
> I would call it regulated block space or regulated consensus space. I
> hope that we can do that on a deeper level, as part of the p2p
> protocol layer.
>
> > 2) by creating transactions where the mining fee is in one way or
> another, an output to an address owned by the preferred miner(s).
>
> That's a distinct function, e.g. at least some communities charge a tax.
> [1]
> I fear it is more likely that a business, say Coinbase, will approach
> a "miner" and just say "we pay 100 USD for a KB to your bank account,
> here are our transactions with no fee". It will literally be an
> off-chain fee. That's what I mean by "secondary market". This would be
> one of the least appealing scenarios.
>
> > There are some terrible pitfalls with both of these methods. [...]
>
> Spot on, that's why this should receive some attention before it
> becomes urgent. I think there is much more to it that we are missing
> at the moment, e.g. Tom: "Using xthin/compact blocks miners only send
> a tiny version of a block which then causes the receiving node to
> re-create it using the memory pool."
>
>
> [1] http://thebitcoin.foundation/declaration.txt
>
>
>
> > From: AJ West <ajwest at gmail.com>
> > To: bitcoin-dev at lists.linuxfoundation.org
> > Cc:
> > Bcc:
> > Date: Mon, 27 Mar 2017 12:29:20 -0400
> > Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
> > Hi I'm AJ West, I made a service http://preferredminer.com which is a
> proof-of-concept project designed to spur discussion on exactly this issue
> of "miners as service providers."
> >
> > The current status is that Bitcoin end users are looking to support
> specific miners, whether that's because they agree with a miner/pool's
> political positions, their consensus ideology, physical location (yes some
> people would like only miners in particular countries to mine their
> transactions) and the list of reasons goes on. The main attitude right now
> is that people would like to 'support' miners who signal for the features
> they care about.
> >
> > I strongly believe, whether the Bitcoin developer community facilitates
> it or not, certain miners will become preferred by users. In summary, there
> are realistically two proposed ways of providing this service in the
> present-day situation: 1) By creating 'segregated mempools' where an
> authenticated third-party like my web service Preferred Miner manages the
> access to pending transactions destined for a specific set of miners, and
> 2) by creating transactions where the mining fee is in one way or another,
> an output to an address owned by the preferred miner(s).
> >
> > There are some terrible pitfalls with both of these methods. The first
> being that you have to trust a lot of people, including the 3rd party (me)
> and the pools to work in your users' interest ("don't give my transactions
> to other miners or broadcast to mempool please"). Then there are the extra
> fees users will have to pay to offset the risk of a miner losing out for
> having to send the network a not-yet-broadcasted transaction. And finally,
> the other method requires that they be larger transactions, and a directory
> of mining pools' receiving addresses for outputs must be maintained. Then
> you have to hope the miner will be setup to scoop in your transaction
> knowing it's got a fee for them. Plus, how many nodes going forward are
> going to hold what seem to be 0-fee transactions in mempool (because the
> fee is in the outputs)?
> >
> _______________________________________________
> 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/20170328/a83fafa5/attachment-0001.html>