Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
> I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2
Speaking of L2, I had recently proposed a new opcode OP_ZKP to enable
payments based on ZKP proof. I wonder if it has drawn enough attention but
it seems to me a viable way to address transaction fee issues, in addition
to enabling more smart contracts. And it will be a Bitcoin native L2, not a
side chain, not pegging.
scriptPubKey: OP_ZKP
scriptSig: ...
I haven't figured out how to use OP_ZKP to incentivize BRC-20, inscription
etc. to move to L2. But I like to bring it up here and I am open to your
feedback and comments.
Thanks,
Weiji
On Tue, May 9, 2023 at 8:51 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I would like to point out that I'm not an advocate for doing anything at
> this point aside from working on l2
>
> just to make it inconvenient for people
>
> I just think the discussion of outputs and fees is interesting and related
> to the game theory portion of Bitcoin
>
>
>
> On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> Ok, I need to highlight one important thing well proven by this
>> discussion (like it or not)...
>>
>> Not the spam itself is the real reason of feeling: "something must be
>> done"
>> The reason is: $30 fee per transaction (I hope you all agree)
>>
>>
>> Let me paraphrase some quotes used in this discussion, then:
>>
>> 1. Lack of block subsidy long term and necessity of $40 tx fee to
>> compensate it - "threaten the smooth and normal use of the Bitcoin network
>> as a peer-to-pear digital currency, as it was intended to be used as."
>>
>> 2. "the harmony of Bitcoin transactions is being disrupted right now" due
>> to lack of block subsidy and due to exorbitant $40 tx fees as an effect
>> necessary to keep the network security untouched
>>
>> 3. "Fee spikes aren't fun" and it's obvious that keeping the network
>> security only on enormous tx fees of active users and having passive users
>> as free-riders - isn't fun, too
>>
>> 4. by ignoring Bitcoin long-term security budget problem - "we indirectly
>> allowed this to happen, which previously wasn't possible before. So we also
>> have a responsibility to do something to ensure that this kind of
>> tremendous $40 tx fees can never happen again"
>>
>> 5. "Action against exorbitant fees should have been taken months ago.
>> (...) It's a mistake that the" tail emission or other necessary solution -
>> weren't implemented on time
>>
>> 6. "we need to find a solution for long-term horrible fees problem - that
>> fits everyone's common ground."
>>
>>
>> Yes, we need - instead of being still in a heavy denial state.
>>
>> No additional comment then, except this little one:
>> Delay of halving in case of 4 years long network difficulty regression
>> situation.
>>
>>
>> Regards,
>> Jaroslaw
>>
>>
>>
>>
>>
>> W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> napisał:
>>
>> Action should have been taken months ago. Spam filtration has been a
>> standard part of Bitcoin Core since day 1. It's a mistake that the existing
>> filters weren't extended to Taproot transactions. We can address that, or
>> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
>> Since this is a bugfix, it doesn't really even need to wait for a major
>> release.
>>
>> (We already have pruning. It's not an alternative to spam filtering.)
>>
>> Luke
>>
>>
>>
>>
>> On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:
>> Hi guys,
>>
>>
>> I think everyone on this list knows what has happened to the Bitcoin
>> mempool during the past 96 hours. Due to side projects such as BRC-20
>> having such a high volume, real bitcoin transactions are being priced out
>> and that is what is causing the massive congestion that has arguable not
>> been seen since December 2017. I do not count the March 2021 congestion
>> because that was only with 1-5sat/vbyte.
>>
>>
>> Such justifiably worthless ("worthless" is not even my word - that's how
>> its creator described them[1]) tokens threaten the smooth and normal use of
>> the Bitcoin network as a peer-to-pear digital currency, as it was intended
>> to be used as.
>>
>>
>> If the volume does not die down over the next few weeks, should we take
>> an action? The bitcoin network is a triumvirate of developers, miners, and
>> users. Considering that miners are largely the entities at fault for
>> allowing the system to be abused like this, the harmony of Bitcoin
>> transactions is being disrupted right now. Although this community has a
>> strong history of not putting its fingers into pies unless absolutely
>> necessary - an example being during the block size wars and Segwit - should
>> similar action be taken now, in the form of i) BIPs and/or ii) commits into
>> the Bitcoin Core codebase, to curtail the loophole
Re: [bitcoin-dev] tx max fee
> 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.9000 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.9000 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.4000 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 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Blocking Vasil was discussed on a similar GitHub PR. Whether or not one agrees or disagrees, the same process is being used. Anyone can NACK and give a reason for Russ as well. On Wed, May 10, 2023 at 8:55 AM Michael Folkson < michaelfolk...@protonmail.com> wrote: > Hi Steve > > > Isn't this as simple as anyone (in particular Core project > contributors) can express their view in this PR? > https://github.com/bitcoin/bitcoin/pull/27604 > > Nope. The extent to which the rationale for blocking Vasil as a maintainer > applies or doesn't apply to ryanofsky (or future potential maintainers) > isn't discussed. From now on the precedent is proposed maintainers can be > blocked for unknown and/or potentially inconsistent reasons by the existing > maintainers. > > Thanks > Michael > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin > > --- Original Message --- > On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Isn't this as simple as anyone (in particular Core project contributors) > can express their view in this PR? > https://github.com/bitcoin/bitcoin/pull/27604 > > On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote: >>> > Essentially my concern is going forward current maintainers will >>> > decide which proposed new maintainers to add and which to block. >>> >>> This is how a large percentage of organizations are run. The current >>> members of a board or other governance group choose who will become a >>> new board member. >>> >> >> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of >> independent contributors merging different pull requests or patches. The >> github controls are merely because that is how github works. There is also >> a secondary issue of people tending to confuse Bitcoin Core with the >> bitcoin protocol in general: >> https://blog.lopp.net/who-controls-bitcoin-core/ >> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd >> >> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427 >> >> - Bryan >> https://twitter.com/kanzure >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Hi Steve > Isn't this as simple as anyone (in particular Core project contributors) can > express their view in this PR?https://github.com/bitcoin/bitcoin/pull/27604 Nope. The extent to which the rationale for blocking Vasil as a maintainer applies or doesn't apply to ryanofsky (or future potential maintainers) isn't discussed. From now on the precedent is proposed maintainers can be blocked for unknown and/or potentially inconsistent reasons by the existing maintainers. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev wrote: > Isn't this as simple as anyone (in particular Core project contributors) can > express their view in this PR? https://github.com/bitcoin/bitcoin/pull/27604 > > On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev > wrote: > >> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev >> wrote: >> >>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote: Essentially my concern is going forward current maintainers will decide which proposed new maintainers to add and which to block. >>> >>> This is how a large percentage of organizations are run. The current >>> members of a board or other governance group choose who will become a >>> new board member. >> >> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of >> independent contributors merging different pull requests or patches. The >> github controls are merely because that is how github works. There is also a >> secondary issue of people tending to confuse Bitcoin Core with the bitcoin >> protocol in general: >> https://blog.lopp.net/who-controls-bitcoin-core/ >> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd >> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427 >> >> - Bryan >> https://twitter.com/kanzure >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Package Relay Proposal
Hi Tom, Yesterday a PR was opened to do just that, with caveats: https://github.com/bitcoin/bitcoin/pull/27609 For higher level tracking of the project: https://github.com/bitcoin/bitcoin/issues/27463 Cheers, Greg On Wed, May 10, 2023 at 11:39 AM Tom Trevethan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The submitpackage RPC is available on regtest in the current core > release. Is there any plan or timeline for deploying this on mainnet in the > next release? Can't find any recent discussion. It would be very helpful > given current (and likely future) issues with mempool purge. > > Tom > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Interactive Payment Batching w/ Payjoin
Hi list, The following message details a number of examples using payjoin P2EP to coordinate payment batches. I stray from the original shape of stenographic payjoin, what I call "canonical payjoin" with 2 inputs and many outputs, to describe what I believe are novel structures that break heuristics used to track batched payments. The later examples match typical batch structure while breaking common input heuristic. I'm curious to hear any feedback or concerns with these methods. This work is written in a less technical register than this list may be used to, but bitcoin-dev is the best forum to request for a critique of the thinking. Thanks, Dan — INTERACTIVE PAYMENT BATCHING IS BETTER ## Payjoin for More Than Privacy A high fee bitcoin always [triggers](https://twitter.com/BTCsessions/status/1655733065426296832) a [search](https://twitter.com/w_s_bitcoin/status/1655885695762808832) for more efficient use of blockspace. Blockchain is a slow database, and batching has got to be one of the oldest ways to optimize a database. Lightning is interactive payment batching based on intermittent settlement. Payjoin is interactive settlement batching. Merchant to customer payjoin is what led to the formal spec. No surprise then that a merchant / customer frame stuck versus a frame payment batching like lightning. Lightning has been batching for scaling all along. The following outlines how payjoin fits into batched transfer settlement infrastructure and how it helps prepare for the next wave of blockspace scarcity. The term "payjoin" is used to describe both an interactive way to build transactions between peers on the web, aka Pay-to-Endpoint (P2EP), and an ambiguous transaction structure, typically with many inputs and two outputs that I dub *canonical payjoin*. Canonical payjoin looks like transaction behavior that any wallet could make, but its inputs actually come from more than one person. Breaking the assumption that all transaction inputs belong to the same person breaks the foundation of blockchain surveillance and the sole privacy problem left open in Satoshi's whitepaper. In an effort to improve bitcoin's privacy through payjoin adoption, I outline a number of ways payjoin can significantly reduce fee expenditure and blockchain throughput in individual and enterprise circumstances. Some of these new techniques preserve privacy for transactions otherwise thought of as unambiguous and certainly traceable. The examples mostly ignore mining fees for the sake of simplicity. ## Before the Batch ### Paying Naively Payjoin without the joi is just payn. ouch. ``` A's input0:2 btc A's input1:3 btc --- B's output0: 4 btc B's address0 A's output1: 1 btc A's change ``` A typical bitcoin transfer from `A`lice to `B`ob looks like this. Note that only the addresses and amounts are posted to chain with no further relation between inputs and outputs. The named labels are not. Third party analysts assume both inputs come from the same entity (because they usually do). They also assume `output0` is the payment because neither input is alone sufficient to make a payment of 4 btc. ### Canonical Payjoin Payjoin foils that assumption because it lets Alice and Bob both contribute inputs. What would be interpreted as a naive payment might actually be a payjoin. Assuming both inputs always come from either Bob or Alice is wrong. ```pre A's input0: 2 btc B's input1: 3 btc --- A's output1: 1 btc A's change B's output0: 4 btc B's address0 ``` Alice only paid 1 btc to `output0`'s 4 btc while merging it with Bob's 3 btc input txo too. Bob's 4 btc is not the 1 btc amount Alice paid, which is not visible. ## Enter Output Substitution Payjoin [payment output substitution](https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki#payment-output-substitution) (`pjos`) lets a receiver like Bob substitute a proposed output with any outputs of equal amount. BIP 78 `pjos` is insecure over relayed communications and thus forbidden. BIP 78 receivers must run their own authenticated server to use `pjos`. [Serverless Payjoin](https://gist.github.com/DanGould/243e418752fff760c9f6b23bba8a32f9) secures relayed `pjos`. The following examines the use of this technique to prevent address reuse, redirect funds to cold storage, forward payments, and batch transactions for massive fee savings. ### The Minimum Effective Interaction Let's make not-quite-payjoin but something still fun. Call that Payjoi. Get it? Joy again? Hah 論. If Bob's wallet is empty or he's using a cold wallet this would still work. Imagine Bob's a bartender who posts the QR code for `bitcoin:address0?pj=https://payjoin.bob.cash` on an the wall at the bar. Alice would scan it to propose the transaction as before, but Bob returns the payjoin proposal with one tiny change. In this way he keeps his tip private from nosy neighbors at the bar. ```pre A's input0:2 btc A's input1:
[bitcoin-dev] Package Relay Proposal
The submitpackage RPC is available on regtest in the current core release. Is there any plan or timeline for deploying this on mainnet in the next release? Can't find any recent discussion. It would be very helpful given current (and likely future) issues with mempool purge. Tom ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR? https://github.com/bitcoin/bitcoin/pull/27604 On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote: >> > Essentially my concern is going forward current maintainers will >> > decide which proposed new maintainers to add and which to block. >> >> This is how a large percentage of organizations are run. The current >> members of a board or other governance group choose who will become a >> new board member. >> > > Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of > independent contributors merging different pull requests or patches. The > github controls are merely because that is how github works. There is also > a secondary issue of people tending to confuse Bitcoin Core with the > bitcoin protocol in general: > https://blog.lopp.net/who-controls-bitcoin-core/ > https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd > > https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427 > > - Bryan > https://twitter.com/kanzure > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
