Good Afternoon,
Thank-you Jeremy for your work on this, it is valuable for the public
consideration but unfortunately I disagree. The idea of being able to
arbitrarily attach a fee to a transaction allows a miners-only attack in
which all sponsored transactions are mined and the fee-rate can be
manipulated. It is possible that it will also allow other exotic forms
of attack. It is true that is seems like a drawback that we cannot see
the future fee rate when we create a transaction but given the value of
Bitcoin it seems more likely that we will have overpaid for the fee
component and our transactions will be sort after to make the most
valuable blocks. If somehow you disagree, I would be interested to hear
how it would not make a problem?
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.
--------------
On 2022-02-10 17:58, Peter Todd via bitcoin-dev wrote:
On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
Happy new years devs,
I figured I would share some thoughts for conceptual review that have
been
bouncing around my head as an opportunity to clean up the fee paying
semantics in bitcoin "for good". The design space is very wide on the
approach I'll share, so below is just a sketch of how it could work
which
I'm sure could be improved greatly.
Transaction fees are an integral part of bitcoin.
However, due to quirks of Bitcoin's transaction design, fees are a
part of
the transactions that they occur in.
While this works in a "Bitcoin 1.0" world, where all transactions are
simple on-chain transfers, real world use of Bitcoin requires support
for
things like Fee Bumping stuck transactions, DoS resistant Payment
Channels,
and other long lived Smart Contracts that can't predict future fee
rates.
Having the fees paid in band makes writing these contracts much more
difficult as you can't merely express the logic you want for the
transaction, but also the fees.
Previously, I proposed a special type of transaction called a
"Sponsor"
which has some special consensus + mempool rules to allow arbitrarily
appending fees to a transaction to bump it up in the mempool.
As an alternative, we could establish an account system in Bitcoin as
an
"extension block".
<snip>
This type of design works really well for channels because the
addition of
fees to e.g. a channel state does not require any sort of pre-planning
(e.g. anchors) or transaction flexibility (SIGHASH flags). This sort
of
design is naturally immune to pinning issues since you could offer to
pay a
fee for any TXID and the number of fee adding offers does not need to
be
restricted in the same way the descendant transactions would need to
be.
So it's important to recognize that fee accounts introduce their own
kind of
transaction pinning attacks: third parties would be able to attach
arbitrary
fees to any transaction without permission. This isn't necessarily a
good
thing: I don't want third parties to be able to grief my transaction
engines by
getting obsolete transactions confirmed in liu of the replacments I
actually
want confirmed. Eg a third party could mess up OpenTimestamps calendars
at
relatively low cost by delaying the mining of timestamp txs.
Of course, there's an obvious way to fix this: allow transactions to
designate
a pubkey allowed to add further transaction fees if required. Which
Bitcoin
already has in two forms: Replace-by-Fee and Child Pays for Parent.
_______________________________________________
bitcoin-dev mailing list
bitcoin-...@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
