Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
Hi all, It looks like there are only a few mailing lists left on https://lists.linuxfoundation.org/mailman/listinfo and all of the remaining ones are using Mailman version 2.1.15, which is not the current version - https://www.gnu.org/software/mailman/ Was there any decision made on where to move the bitcoin-dev mailing list to? Thanks, Brad On 2023-11-11 02:54, vjudeu via bitcoin-dev wrote: > What about using Signet, or some separate P2P network, to handle all of that? > > 1. All e-mails could be sent in a pure P2P way, just each "mailing list node" > would receive it, and include to its mempool. > 2. The inclusion of some message would be decided by signing a block. > Moderators would pick the proper messages, and publish them by broadcasting a > new block to all nodes. > 3. Each message will be signed by some public key. It could be changed each > time, or even derived from some HD wallet. Only those owning "master public > keys" would know, which messages were sent by the same person. > 4. The time of the block could be much longer than 10 minutes. It could be > for example one hour, one day, or even longer. Or, the commitment to all of > that could be just included "every sometimes" to the existing Signet chain, > because it would take no additional on-chain bytes, and can be easily done in > the coinbase transaction. > 5. If there will be too much spam in the mempool, then hashcash-based Proof > of Work can be used to filter messages. Instead of fee-based filtering, it > could be Proof-of-Work-based filtering. Even better: because of "master > public keys", the regular participants could be allowed anyway, without > providing additional Proof of Work. Their signature would be sufficient in > that case. > 6. The code is almost there. Maybe there are even altcoins, designed > specifically for storing data, and we could just use them? > 7. This kind of decision would push things like Silent Payments forward. > Because then, you could develop scanners, to know, who wrote which message. > You could enter some "master public key", scan the whole chain, and find out > all messages written by that particular participant. > 8. It would push commitments forward. Because then, it would be possible to > send some message to the "P2P mailing list network", and reveal it later. Of > course, it is not mandatory to accept commitments at all, which means, they > could be easily disabled, if they would be misused. Or we could start with no > commitments, and introduce them later if needed. > 9. Because Signet challenge can contain some multisig, or even some Taproot > address, there will be no issue with using the same password to access the > moderation panel. Also, in that case, it is possible to prove later, which > moderator accepted which message. And also, it is still possible to use some > shared key, if revealing that is not desirable, or even it is possible to > easily reach "approved by all moderators" messages, because their Schnorr > signatures could be combined. Also, any K-of-N multisig can be battle-tested > in that way. > > So, I can see two options: reusing some existing P2P network, or making a new > one, designed specifically for handling mailing list messages in a pure P2P > way. I guess we can try some existing chains first, and if there is no > promising altcoin, or if we don't want to be associated with any altcoin, > then our own Signet-like network could solve it. > ___ > 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] Ordinal Inscription Size Limits
Erik/all, Are you saying that node capacity is the primary technical limiting factor to increasing adoption of bitcoin payments? UBER & Lyft payments are actually poor examples because they are not regular/monthly and I should not have used them (unless refilling existing accounts, like gift cards). But utility bills would be a much better example of an opportunity for bitcoin payments to compete with existing credit card payment systems because processing timing has the potential to be less urgent. Sharing UTXOs seems pretty minor compared to lowering transaction costs. Brad On 2024-01-01 08:08, Erik Aronesty wrote: >> . >> >> In the USA, where I am, large businesses like UBER, Lyft, and many major >> telecom, cable, & electric utilities process huge volumes of regular and >> irregular credit card payments on a monthly basis. Almost none oft hose >> transactions are completed in bitcoin. > > Unfortunately block size is not the limiting factor > > Main chain transactions have to be broadcast and stored on every node in the > network which, as you know, cannot scale to the level of Uber payments > > Lighting and possibly ark are solutions to this problem > > Both require covenant tech of some kind to scale properly (nonrecursive is > fine) > > Covenant tech (any will do, arguing about which is bike shedding at this > point) allows people to share utxos and yet still maintain sovereignty over > their assets > >>___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
Erik,
Fees AKA costs are the best spam control system and I thank you for
highlighting that.
However, I think that bitcoin has yet to receive sufficient payments
usage to challenge credit card payments system when it comes to a race
to the bottom in terms of processing transactional fees.
In the USA, where I am, large businesses like UBER, Lyft, and many major
telecom, cable, & electric utilities process huge volumes of regular and
irregular credit card payments on a monthly basis. Almost none oft hose
transactions are completed in bitcoin.
A focus on lowering fees by increasing the block size by 10x is the
simplest method to start accepting more payments in bitcoin from larger
businesses.
Brad
On 2023-12-30 01:58, Erik Aronesty via bitcoin-dev wrote:
> Bitcoin already has a spam prevention system called "fees". I don't believe
> it's insufficient. The only issue is the stochastic nature of its
> effectiveness
>
> Which can be resolved with things like payment pools, tree payments
> (https://utxos.org/uses/scaling/), etc.
>
> On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoin-dev
> wrote:
>
>>> Unfortunately, as near as I can tell there is no sensible way to
>>> prevent people from storing arbitrary data in witnesses ...
>>
>> To prevent "from storing arbitrary data in witnesses" is the extreme
>> case of the size limit discussed in this thread. Let's consider it along
>> with other (less radical) options in order not to lose perspective, perhaps.
>>
>>> ...without incentivizing even worse behavior and/or breaking
>>> legitimate use cases.
>>
>> I can't find evidence that would support the hypothesis. There had not
>> been "even worse behavior and/or breaking legitimate use cases" observed
>> before witnesses inception. The measure would probably restore
>> incentives structure from the past.
>>
>> As a matter of fact, it is the current incentive structure that poses
>> the problem - incentivizes worse behavior ("this sort of data is toxic
>> to the network") and breaks legitimate use cases like a simple transfer
>> of BTC.
>>
>>> If we ban "useless data" then it would be easy for would-be data
>>> storers to instead embed their data inside "useful" data such as dummy
>>> signatures or public keys.
>>
>> There is significant difference when storing data as dummy signatures
>> (or OP_RETURN) which is much more expensive than (discounted) witness.
>> Witness would not have been chosen as the storage of arbitrary data if
>> it cost as much as alternatives, e.g. OP_RETURN.
>>
>> Also, banning "useless data" seems to be not the only option suggested
>> by the author who asked about imposing "a size limit similar to OP_RETURN".
>>
>>> But from a technical point of view, I don't see any principled way to
>>> stop this.
>>
>> Let's discuss ways that bring improvement rather than inexistence of a
>> perfect technical solution that would have stopped "toxic data"/"crap on
>> the chain". There are at least a few:
>> - https://github.com/bitcoin/bitcoin/pull/28408
>> - https://github.com/bitcoin/bitcoin/issues/29146
>> - deprecate OP_IF opcode.
>>
>> I feel like the elephant in the room has been brought up. Do you want to
>> maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
>> ___
>> 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Melvin/all,
You make good points about high network fees being disruptive.
What is more disruptive are spikes & valleys (instability) that last
longer than the mempool cycle can handle.
Right now, https://mempool.space/ indicates that there are about 105,000
unconfirmed transactions and that current memory usage is 795 mb of 300
mb.
We could compare the bitcoin networks' ability to process transactions
to the California Independent System Operator's (CAISO -
https://www.caiso.com/Pages/default.aspx) task of ensuring the CA
electrical grid stays supplied with the least expensive electricity
available and does not get overloaded, nor has to export too much
electrical power to other grids in times of surplus.
A big part of doing that is noticing past trends and preparing for
future growth, if that is the goal.
Expanding the block size is the simplest way to expand network capacity
and lower transactional costs.
Thank you,
Brad
On 2023-05-08 09:37, Melvin Carvalho via bitcoin-dev wrote:
> po 8. 5. 2023 v 13:55 odesÃlatel Ali Sherief via bitcoin-dev
> napsal:
>
>> 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 in BIP 342 (which defines
>> the validation rules for Taproot scripts) which has allowed these unintended
>> consequences?
>>
>> An alternative would be to enforce this "censorship" at the node level and
>> introduce a run-time option to instantly prune all non-standard Taproot
>> transactions. This will be easier to implement, but won't hit the road until
>> minimum next release.
>>
>> I know that some people will have their criticisms about this,
>> absolutists/libertarians/maximum-freedom advocates, which is fine, but we
>> need to find a solution for this that fits everyone's common ground. 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
>> congestion can never happen again using Taproot.
>
> This is a nuanced and sensitive topic that has been discussed previously, as
> far back as 2010, in a conversation between Gavin and Satoshi:
>
> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>
> Gavin: That's a cool feature until it gets popular and somebody decides it
> would be fun to flood the payment network with millions of transactions to
> transfer the latest Lady Gaga video to all their friends...
> Satoshi: That's one of the reasons for transaction fees. There are other
> things we can do if necessary.
>
> High fees could be viewed as disruptive to the network, but less disruptive
> than regular large reorgs, or a network split.
>
> It might be beneficial to brainstorm the "other things we can do if
> necessary".
>
> A simple observation is that increasing the block size could make it more
> challenging to spam, though it may come at the expense of some
> decentralization.
>
>> -Ali
>>
>> ---
>>
>> [1]:
>> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
>> [1]
>> ___
>> 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
Links:
--
[1]
https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp___
bitcoin-dev mailing list
