So this half aggregation BIP draft could potentially play the role that BIP340
did for BIP341/342 but it is too premature to start formalizing what the
equivalent of BIP341/342 for this draft BIP would look like. And given there
are use cases for this half aggregation BIP that can be worked on
>And therefore this reduces to the simple fact that tx fees are what provides
>censorship resistance, whether you mine your own or others?.
What's the business model of the person who mines with the intention to censor
transactions when there's no block reward?
Regards
Peter
[my third attempt at getting this message through. Surprisingly, I managed to
send this at the second try with the correct SMTP, From, To and all, but maybe
it was caught in GreyListing (protonmail).]
I was thinking about creating a BIP to address the lack of standardization for
Segwit message
If there’s no block reward, there’s no Bitcoin, so that’s moot. But setting
that aside. The business model of the state is to preserve the reward it
obtains from its own money. This is the reason for currency controls, which are
common.
e
> On Jul 20, 2022, at 03:17, Peter via bitcoin-dev
>
Please see BIP322
https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
On Wed, Jul 20, 2022, 5:46 PM Peter (Coinkite Inc) via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Ali.
>
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My
> proposal is
Hi,
Discussions on covenants have been prolific and intense on this mailing
list and within the wider Bitcoin technical circles, I believe however
without succeeding to reach consensus on any new set of contracting
primitives satisfying the requirements of known covenant-enabled use-cases.
I
Hi Ali.
> This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My
> proposal is simply going to standardize the practice of placing the segwit
> address into the address field, and does not require alterations to the
> message signing format like those BIPs.
COLDCARD makes
