damian at willtech.com.au [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-10 📝 Original message: Good Afternoon, Thank-you ...
📅 Original date posted:2022-02-10
📝 Original message:
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-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:
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-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev