Thank you for answering. I'll check out the link you provided, while also playing around with the fee settings for my own full node, at my home server.
On Wed, 3 Aug 2022 at 23:02, vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It is possible, because you can find nodes that accept low-fee > transactions. And on some statistics, for example > https://jochen-hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero > to one satoshi per virtual byte transactions could take more space than > other transactions. You can be convinced that those charts are not fake by > running a full node and reaching some nodes with different fee settings. If > miners don't want to accept them, well, it is their choice to leave that > money on the table. As long as the basic block reward is sufficient, they > don't have to accept such low fee transactions, because they can wait > instead, to receive them in some batched form. > > Also, some miners could accept only 10 sats/vB or higher, because why not. > As long as your transaction will reach enough nodes to be confirmed, you > can safely pick lower fees. For now, de-facto standard is one satoshi per > virtual byte, but: > > 1) it is only declared, so you can rely only on declarations, not on hard > consensus rules > 2) there is no way to make sure if some transaction was truly rejected by > some miner, or maybe it was saved somewhere > 3) you can never be sure if some node is a miner and can enforce those > different fee rules or not > > So, you can really judge only by how nodes behave, you cannot make sure in > any way if anyone is running some additional rules. And fees are not a part > of the consensus, so they can be freely adjusted by each node, and there is > no way to make sure, what rules are really executed, you can only assume > that, based on what transactions are included in blocks. > > > > On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > So, can we conclude by something, whether or not it would be possible and > feasible in the future? > > > On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail > wrote: > > > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev > wrote: > > > like a hashcash-based alternative broadcast scheme. > > Hi Peter, > > I've been mulling the idea of attaching work to low fee txns, both as a > compensation (e.g., in a sidechain, or an alt), and/or as a spam proof. > Unfortunately, both suffer from ASICs: > > For spam proof case, the adversary can easily buy a used/obsolete device > to produce lots of spam txns very cheaply, unless you put the bar very > high, making it almost impossible for average users to even try. > > The compensation scenario is pretty off-topic, still, interesting enough > for 1 min read: > > Wallets commit to the latest blockchain state in the transaction AND > attach work. > > It is considered contribution to the security (illegitimate chains can't > include the txn), hence isrewarded by fee discount/exemption depending on > the offset of the state they've committed to (the closer, the better) and > the amount of work attached. > > For this to work, block difficulty is calculated inclusive with the work > embedded in the txns, it contains. Sophisticated and consequential, yet not > infeasible per se. > > > > Unfortunately, this scheme is hard to balance with ASICs in the scene > too, for instance, you can't subsidize wallets for their work like with a > leverge, because miners can easily do it locally, seizing the subsidies for > themselves, long story, not relevant just ignore it. > > We're not talking about a consensus system here. Just a way to rate-limit > access to a broadcast network used by a small minority of nodes. It's > completely ok to simply change the PoW algorithm in the _highly_ unlikely > event > someone bothers to build an ASIC for it. Since this isn't a consensu > system, > it's totally ok if multiple versions of the scheme run in parallel. > _______________________________________________ > 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
