Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Melvin Carvalho via bitcoin-dev]

pá 3. 11. 2023 v 11:16 odesílatel Brad Morrison 
napsal:

> 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.
>

The block size is a sensitive topic, as it has been used as an attack
vector in the past.  It is now a loaded topic baked into the mythology of
the project.  Discourse on the topic benefit from a dispassionate analysis
of the technical trade-offs and what properties of the network they affect.

There exists an attack on bitcoin where the lowest fee rises to make it
much harder to participate.  You could imagine a well funded attack,
creating fees of, say, 10,000 sats/vbyte, for a period of time.

While this could be viewed as positive from one lens (miners benefit),
there would at least be a vocal minority, legitimately arguing that this is
disruptive to the ordinary function of the network.

It's worth recognizing that a bigger block size makes this kind of
disruptive attack more expensive.

It's a tricky topic because of the history, and because some of the "spam"
may be seen by some as legitimate.

I think in the long-term miners and users will treat the fee auction in new
ways, with the use of AI algorithms.  Trillions are transmitted through the
bitcoin network.  A fraction of that is captured.  As the block subsidy
goes away over the next 2 decades, it might lead to a kind of "AI mexican
standoff" where the highest value transactions pay a bit more for priority
transfers.  AI will likely change the game theory, and we'll find out how,
over the next 2 epochs.

If that is the case, then block size can increase with hardware advances,
while maintaining much valued decentralized properties of the network.  In
this regard we probably would benefit from things like stratumv2 and
utreexo being rolled out first.


> 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 <
> bitcoin-dev@lists.linuxfoundation.org> 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 peo

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Melvin Carvalho via bitcoin-dev]

po 8. 5. 2023 v 13:55 odesílatel Ali Sherief via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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/
> 
> ___
> 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

[Melvin Carvalho via bitcoin-dev]

pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> napsal:

> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). The
> ordinal scheme is elegant and genius IMHO, but when I think about the
> future disk use of all unpruned nodes, I question whether unlimited storage
> is wise to allow for such use cases. Wouldn't it be better to find a way to
> impose a size limit similar to OP_RETURN for such inscriptions?
>
> I think it would be useful to link a sat to a deed or other legal
> construct for proof of ownership in the real world, so that real property
> can be transferred on the blockchain using ordinals, but storing the
> property itself on the blockchain seems nonsensical to me.
>

Low tech solution: miners charge a premium for storing images in the block
chain.  Say 2x, 5x, 10x.

This encourages bitcoin to be used as a financial network, while increasing
the security budget.

>
> ___
> 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] What to expect in the next few weeks

[Melvin Carvalho via bitcoin-dev]

On Fri, Apr 22, 2022 at 7:33 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the next few weeks go how I fear they will it could get messy. If you
> care about Bitcoin's consensus rules I'd request you pay attention so you
> can make an informed view on what to run and what to support. For those of
> you who were around in 2015-2017 you'll know what to expect. The right
> outcome endured in 2017 and I'm sure the right outcome will endure here
> assuming people pay attention and listen to the individuals who were
> trusted during that period. There are always a large number of motivated
> parties who are incentivized to break nodes off from Bitcoin and may seek
> to take advantage of a contentious soft fork activation attempt.
>
> Remember that if all the information is presented to users in a clear way
> well ahead of time then they can make their own mind up. I fear that things
> will be made as convoluted as possible in a way intended to confuse and
> information will be withheld until the last minute. When in doubt it is
> generally better to rely on the status quo and tried and trusted. In this
> case that would be Bitcoin Core. Alternative releases such as those seeking
> to attempt to activate CTV or indeed those seeking to resist the activation
> of CTV really should only be considered if you are informed on exactly what
> you are running.
>
> If you are interested in the effort to resist the contentious soft fork
> activation attempt of CTV please join ##ursf on Libera IRC.
>
> Have a good weekend. Hopefully those behind this contentious soft fork
> activation attempt will see sense and we can go back to more productive
> things than resisting contentious soft forks.
>

Thanks for raising this

Remembering 2017 quite well, it's often characterized as small block(ers)
vs big block(ers).  While that was certainly the case, I see it slightly
differently.

I think the bigger argument of 2017 was around a network split.  Splitting
the network is problematic because one or other of the split chains may
experience a hash death (without mitigating difficulty adjustment
algorithms), or the so-called "famine and feast" minority hash behaviour,
experienced on testnet, and disruptive to users

Any proposed changes should factor in network splits as a potential risk.
Or perhaps through another lens, you could see a network split as an
attack, on a par with a 51% attack, in terms of user disruption.  It may in
fact, be more potent, since we've never had a serious 51% attack, but we
have had network splits

I do think the conversation here is MUCH better tempered than 2017.
Hopefully we can try and avoid perceptions of gate keeping and railroading,
and keep the network together, as we did back then


>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> ___
> 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] Reducing block reward via soft fork

[Melvin Carvalho via bitcoin-dev]

On Mon, 24 May 2021 at 22:32, Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Before we can decide on tradeoffs that reduce security in favor of less
> energy usage, or less inflation, or whatever goal you might have for
> reducing (or delaying) coinbase rewards, we need to decide as a community
> how much security bitcoin *needs*.
>
> Do we need to be secure against an attacker with a budget of $1
> billion/year for an attack? $10 billion/year? More?
>
> An upper limit would be the budget of the largest government: the US. The
> US federal budget is almost $5 trillion/year. But they certainly couldn't
> spend all that budget attacking bitcoin. About $3 trillion of that is
> mandatory spending, which couldn't be allocated to such an attack. About
> $1.5 trillion is discretionary, which includes the military budget. It
> seems like an upper limit on the amount that could be siphoned from that
> budget to attack bitcoin would be 5%. That would take massive political
> cooperation and wheeling and dealing. Likely spending that much would not
> be politically feasible, but it seems possible, since a 5% reduction in
> other activities is something other departments would likely be able to
> sustain with just a bit of downsizing. Or that money could simply come from
> more borrowing. 5% of $1.5 trillion is $75 billion. So that seems like a
> pretty solid upper limit on the amount the US could allocate to an attack
> in a year, in that it seems incredibly unlikely that more money than that
> could be allocated. Such an expenditure might be eventually seen as
> justified since the federal reserve has been inflating the supply of
> dollars by 17.5% on average every year, which would be $1 trillion next
> year (and more the next, etc). A similar story is told if you calculate the
> amount of seigniorage banks get access to by their ability to use
> fractional reserve to inflate the supply of M2 money.  It should be
> considered tho that this seigniorage doesn't give its beneficiaries that
> full value, but rather some fraction of that value - say 5% earned by being
> first to buy with that new money and earning interest on it. So 5% of a
> trillion is $50 billion. Still, over just two years, that's enough to pay
> for an attack of at least that size ($75 billion).
>
> The budget for the government of China is about $3.6 trillion, the second
> largest in the world. And since they're an authoritarian country, they can
> basically do whatever they want with that money. It still seems unlikely
> they would spend more than 5% of that budget on doing something like
> attacking bitcoin. However, consider that China's M2 money supply has been
> increasing at a rate of almost $3 trillion per year. Protecting the ability
> to do this is seems like something worth spending some (printed) money on.
> So perhaps at some point, spending 10 or 20% of their budget for a year or
> two to attack bitcoin might seem like a good idea to some mickey mouse in
> the government. That would be $720 billion/year.
>
> So given the amount of seigniorage taken in every year by these central
> banks, it would seem to justify large expenditures. I'm not sure how
> realistic it would be, politically speaking, to gather $720 billion in a
> single year to attack bitcoin. It seems far fetched, even if the
> seigniorage they're protecting seems to justify it.
>
> So is this the level of attack we want to be resilient to? Nearly a $1
> trillion attack? I don't know. But we should figure that out as a
> community. And keep in mind, the level of attack we need to defend against
> depends on the size of bitcoin. The more valuable bitcoins are, the more
> damaging, more lucrative, and more valuable an attack would be for
> attackers. Its seems reasonable to assume that this is a linear
> relationship - that if bitcoins are worth twice as much, we need twice as
> much security (ie we want to make attacking bitcoin twice as costly).
>
> The next step is figuring out a reasonable lower bound for how much it
> takes to attack bitcoin. There are many attacks that can be done on
> bitcoin, but the one relevant to the discussion here is a 51% attack.
> Bitcoin's PoW basically is attackable buy buying about 25% of the existing
> mining power (for reasons like the selfish economic attack
> 
>  and
> the economic mining monopoly attack
> ),
> which is about 40 exahashes/second.
>

Agree that it is valuable to find a reasonable lower bound to how much it
take to 'attack' bitcoin

Two observations:

1. The security model of bitcoin is dual and heterogeneous.  There is both
a block subsidy and a fee model.  These are not like for like.  One is
steady, and one fluctuates.  You might make the analogy with steady nuclear
power, and 

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

[Melvin Carvalho via bitcoin-dev]

On Mon, 26 Apr 2021 at 22:08, Greg Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I endorse Harding's recommendations.  On the point about mirroring,
> one thing to keep in mind is that the other repositories may go
> offline.
>
> Modification confusion could be avoided by recording what revision
> (commit hash) was current at the time of inclusion, but the document
> going offline can only be protected against by maintaining a copy
> somewhere.
>

One could partially solve the mirroring issue by giving each decentralized
BIP (optionally) a genesis transaction ID, that moved in time on the block
chain

This can be made to mirror / witness the evolution in git of the BIP using
git commit hashes (in time), and then matching those commit hashes in the
block chain by tweaking the public key address by the same amount (with no
change address)

What would occur then would be a genesis and current definitive HEAD of a
BIP, and the history it's gone through.  The whole history can be
reconstructed from any one transaction.  This is quite similar to Peter
Todd's single use seals, and the work done on RGB

Regarding commit trees going offline, they can be mirrored, hosted on
popular sites (github/gitlab) and it's natural that popular repos in git
are cloned

This also provides a little skin in the game and prevents some sybil
attacks, because you need to spend money on a TX

In this way whole BIPs can have a life cycle outside of any official body,
but also be assigned BIP numbers in the bitcoin repo

This mainly an informational idea, however, I have been working on some
code and early prototypes to do this, so feel free to message me off-list
if there's additional interest


>
>
> On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev
>  wrote:
> >
> > On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > > In general, I think its time we all agree the BIP process has simply
> failed
> > > and move on. Luckily its not really all that critical and proposed
> protocol
> > > documents can be placed nearly anywhere with the same effect.
> >
> > I recommend:
> >
> > 1. We add additional BIP editors, starting with Kalle Alm (if there are
> >no continuing significant objections).
> >
> > 2. We seek Luke Dashjr's resignation as BIPs editor.
> >
> > 3. We begin treating protocol documents outside the BIPs repository as
> >first-class BIP documentation.
> >
> > The first recommendation permits continued maintenance of existing BIPs
> > plus gives the additional maintainers an opportunity to rebuild the
> > credibility of the repository.
> >
> > The second recommendation addresses the dissatisfaction of many BIP
> > authors and potential authors with the current editor, which I think
> > will discourage many of them from making additional significant
> > contributions to the repository.  It also seems to me to be a better use
> > of Luke's talents and interests for him to focus on protocol research
> > and review rather than procedurally checking whether a bunch of
> > documents are well formed.
> >
> > The third recommendation provides an escape hatch for anyone, such as
> > Matt, who currently thinks the process has failed, or for anyone who
> > comes to that same conclusion in the future under a different editing
> > team.  My specific recommendations there are:
> >
> > a. Anyone writing protocol documentation in the spirit of the BIP
> >process can post their idea to this mailing list like we've always
> >done and, when they've finished collecting initial feedback, they can
> >assign themselves a unique decentralized identifier starting with
> >"bip-".  They may also define a shorter alias that they encourage
> >people to use in cases where the correct document can be inferred
> >from context.  E.g.,
> >
> >   bip-wuille-taproot (bip-taproot)
> >   bip-towns-versionbits-min-activation-height (bip-vbmah)
> >   bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
> >
> > b. The author then publishes the document to any place they'd like,
> although
> >they are strongly encouraged to make any document source available
> >under an open license to ensure others can create their own
> >modifications.
> >
> > c. Implementations of BIPs, whether original repository BIPs or
> >decentralized BIPs, link to the BIPs they implement to ensure
> >researchers and developers can find the relevant protocol
> >documentation.  E.g.,
> >
> https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
> >
> >  (It may also be advisable for implementations to mirror copies of
> >  the BIPs they implement so later modifications to the document
> >  don't confuse anyone.  For this reason, extremely liberal
> >  licensing of BIP documents is encouraged.)
> >
> > d. To help maintain quality and consistency between documentation, the
> >BIP editors provide a 

Re: [bitcoin-dev] activation mechanism considerations

[Melvin Carvalho via bitcoin-dev]

On Thu, 4 Mar 2021 at 10:07, John Rand via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Consensus is important for both taproot and separately for the activation
> mechanism.  There are more soft-forks that Bitcoin will need, so it is
> important to achieve positive progress on the activation topic also, not
> get impatient and rush something ill-considered.  Not all future soft-forks
> maybe as widely supported as taproot, and yet it could become existentially
> critical that Bitcoin prevails in achieving a future upgrade in dramatic
> circumstances, even against powerful interests counter to Bitcoin user and
> investors interests.  We should treat the activation topic in a considered
> way and with decorum, provide tight non-emotive reasoning devoid of
> frustration and impatience.  This is a low drama and convenient time to
> incrementally improve activation.  People have varied views about the
> deciding factor, or even which factors resulted in segwit activating after
> BIP 141 failed using BIP 9.  We do not have to solve everything in one
> step, incremental improvement is good, for complex unintuitive topics, to
> learn as we go - and it should not be hard to do less badly than what
> transpired leading up to BIP 148 and BIP 91.  Failure to upgrade if
> permanent, or demoralizing to protocol researchers could be a systemic risk
> in itself as there are more upgrades Bitcoin will need.  We are not Ents
> but we should use our collective ingenuity to find an incremental
> improvement for activation.
>

Great high level thoughts

The Ents themselves were created in Tolkien's fork of Shakespeare, when he
was frustrated to learn that trees didnt actually march :)

Having followed standards for 10+ years consensus can be tricky

IIRC last time with segwit there was a straw poll in the wiki where devs
could express leanings in an informal, async way.  Something like that
could be of value.

There's an insightful spec written at the IETF "On Consensus and Humming in
the IETF", then IMHO is worth reading

https://tools.ietf.org/html/rfc7282

That said, if we could find an incorruptible machine that could gather the
highest fee tx from the mempool and post it every 10 minutes, bitcoin would
largely run itself.  So, while understanding the gravity of each change, we
could perhaps have the mindset that there are a finite number, such that
when complete bitcoin will move to an endgame where for the user it 'just
works', much like the internet.  If devs and changes are needed less, that
could be viewed as a sign of success.  This is a hand wavy way of saying
that forks could potentially be a diminishing issue over time

Just my 2 satoshis


>
> John R
> ___
> 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] Softfork proposal for minimum price of $50k USD/BTC

[Melvin Carvalho via bitcoin-dev]

On Mon, 1 Apr 2019 at 02:32, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Certain parts of the community have been selling bitcoins for unreasonably
> low prices. This has halted Bitcoin's valuation at $20k and even driven the
> price down below $15k! However, clearly Bitcoin is worth much more than
> that, and there is widespread support for higher prices.
>
> In light of this, I have written and implemented two BIPs: one to add a
> signed price field to Bitcoin transactions, and the other to softfork a
> minimum price of $50k USD/BTC a year from today.
>
> The BIPs are here, as well as included at the bottom of this email for
> convenience:
>   https://github.com/luke-jr/bips/blob/softfork_50k/bip-usdprice.mediawiki
>
> https://github.com/luke-jr/bips/blob/softfork_50k/bip-softfork-50k-price.mediawiki
>
> A reference implementation is here:
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:softfork_50k
>
> Please review ASAP so we can get these deployed in Bitcoin Core v0.18.
>

This seems a little arbitrary.  Ask yourself, "Why the USD?".  Yes, it is
the dominant currency now, but in 2, 6, 10, 14 years?  Who knows.

You could make equally an argument to denominate in euros.  Or a basket of
currencies, or even the Bancor.

However the wider question is why even denominate in fiat at all?

I suggest denominating the minimum value in satoshsis themselves, which
would be a negligable upgrade to the network.


>
> Luke
>
>
> 
>   BIP: ?
>   Layer: Applications
>   Title: Signed USD Price Indicator
>   Author: Luke Dashjr 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
>   Status: Draft
>   Type: Standards Track
>   Created: 2019-04-01
>   License: BSD-2-Clause
> 
>
> ==Abstract==
>
> This BIP proposes a method to explicitly specify and sign the USD/BTC
> price
> for transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> Certain parts of the community have been selling bitcoins for unreasonably
> low
> prices. This has halted Bitcoin's valuation at $20k and even driven the
> price
> down below $15k! However, clearly Bitcoin is worth much more than that,
> and
> there is widespread support for higher prices.
>
> This problem can be fixed by setting a global minimum price for bitcoins.
> Unfortunately, today, the consensus protocol is completely oblivious to
> the
> price bitcoins are traded at. Therefore, we must first add a field to
> Bitcoin
> transactions to indicate their price.
>
> ==Specification==
>
> ===New field and legal implication===
>
> A new field is added to Bitcoin transactions. This field, if present, must
> represent the honest and true USD/BTC rate used for the transaction. By
> signing the transaction, the sender legally affirms this is the valuation
> of
> bitcoins used for the transaction.
>
> For the avoidance of doubt: when the transaction is valued in a currency
> other
> than USD, any reasonable exchange rate may be used to come up with the USD
> valuation.
>
> ===Serialisation===
>
> When serialising the transaction for any purpose, including signing,
> weight
> calculation, and so on, the output count must be incremented by one. Prior
> to
> the first real output, the following bytes must be inserted:
>
> * Constant: 00 00 00 00 00 00 00 00
> * A single byte, the size in bytes of the remainder of the inserted data
> * Constant: 6a 04 55 53 44 24
> * A single byte, the size in bytes of the remainder of the inserted data
> * The USD/BTC rate used for the transaction, in standard signed integer
> serialisation, with all leading zeros removed (except as necessary to
> preserve the sign bit).
>
> ==Backwards compatibility==
>
> ===Consensus===
>
> The new price field is serialised as a dummy output, with a value of zero,
> and
> a scriptPubKey that begins with OP_RETURN (6a). Existing nodes will ignore
> this dummy output, and the leading OP_RETURN in the scriptPubKey ensures
> it
> is never considered spendable.
>
> Therefore, current nodes will ignore the new field entirely, and accept
> transactions using it.
>
> ===Wallets===
>
> Existing wallets do not typically generate price indicators as specified.
> Under this BIP, this absence of the field is perfectly acceptable.
>
> ==Reference implementation==
>
>
> https://github.com/bitcoin/bitcoin/compare/v0.17.1...luke-jr:usd_price_tx_field
>
> 
>   BIP: ?
>   Layer: Consensus (soft fork)
>   Title: $50k USD/BTC Minimum Price
>   Author: Luke Dashjr 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
>   Status: Draft
>   Type: Standards Track
>   Created: 2019-04-01
>   License: BSD-2-Clause
>   Requires: usdprice
> 
>
> ==Abstract==
>
> This BIP defines a minimum price of $50k USD/BTC for Bitcoin transactions.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Motivation==
>
> 

Re: [bitcoin-dev] Total fees have almost crossed the block reward

[Melvin Carvalho via bitcoin-dev]

On 21 December 2017 at 22:30, Melvin Carvalho 
wrote:

> I asked adam back at hcpp how the block chain would be secured in the long
> term, once the reward goes away.  The base idea has always been that fees
> would replace the block reward.
>
> At that time fees were approximately 10% of the block reward, but have now
> reached 45%, with 50% potentially being crossed soon
>
> https://fork.lol/reward/feepct
>
> While this bodes well for the long term security of the coin, I think
> there is some legitimate concern that the fee per tx is prohibitive for
> some use cases, at this point in the adoption curve.
>
> Observations of segwit adoption show around 10% at this point
>
> http://segwit.party/charts/
>
> Watching the mempool shows that the congestion is at a peak, though it's
> quite possible this will come down over the long weekend.  I wonder if this
> is of concern to some.
>
> https://dedi.jochen-hoenicke.de/queue/more/#24h
>
> I thought these data points may be of interest and are mainly FYI.  Though
> if further discussion is deemed appropriate, it would be interesting to
> hear thoughts.
>

Just following up on this, for no other reason than I've had my eyes glued
to these stats the last few weeks.  I'll share a few more stats links.

Mempool has come down significantly, as have fees.  Tho, of course, this
could spike any time.

https://bitinfocharts.com/bitcoin/

Typically fees are :

 $2.06 on tx $543 (median) # 0.38%
 $3.47 on tx $75,000 (mean) # 0.005%

Aside: An observation on this.  High value transactors seems to be getting
a much better deal, than the mean.  This lead me to ponder whether the
intuitive metric of satoshi/byte is, in fact, game theory optimal.
Possibly over the short term it is, but over a longer period, those wishing
to increase the longevity of proof of work in general might wish to
consider more progressive fee approaches.  Naively, it might be possible to
imagine some kind of gaussian distribution that picks tx according to a
blended combination of sats/byte and %transacted.  Perhaps something for
miners and fee estimation algorithms to develop over time.

Segwit adoption has increased, and anecdotal evidence shows that trend to
continue.  The release of 0.16 will I think also have a positive effect.

Finally, I came across this wonderful site that shows lightning network
adoption on mainnet

http://shabang.io/

LN is increasing well.  Some blocks are not far off 1% lightning funding,
which I think bodes well.  I'll go out on a limb and predict that over 1%
of btc tx will be lightning based by year end.

Since such posts are not strictly development, I'll keep them to a
minimum.  However, I hope these stats provide useful data points for
project evolution.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Upgrading PoW algorithm

[Melvin Carvalho via bitcoin-dev]

On 17 January 2018 at 23:31, Jefferson Carpenter via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin's difficulty will be maxed out within about 400 years, by Moore's
> law.  (After that - supposing the software does not crash when difficulty
> overflows - block time will start decreasing, and it will not take long
> before blocks are mined faster than photons can be sent across the planet).
>
> Bitcoin is the dominant cryptocurrency today, as the first mover: the
> perfectly fair worldwide game of inventing the cryptocurrency has been
> played and won.  However, unfortunately, it has a built-in end date: about
> 400 years from now.  After that, it won't necessarily be clear what the
> dominant cryptocurrency is.  It might be a lot like VHS vs Betamax, and a
> lot of people could lose a lot of money.  It seems to me, this could be
> mitigated by planning today for what we are going to do when Bitcoin
> finally breaks 400 years from now.
>
> Are there any distinct plans today for migrating to a PoW supporting an
> even higher difficulty?
>

Crypto algorithms have a lifetime, and consensus is no different.

Is it likely to be more than a few years?  Yes.

Is likely to be less than a few hundred years.  Yes.

Every algorithm involves trade offs and it's the job of a thoughtful dev
team to examine those trade offs and come to a consensus optimal solution.

This field is only 9 years old, and there is a large amount of R & D in
this area.  So we can evaluate what seems to working better and what seems
to be working worse, transfer that to BIPs, create code, test it, try to
achieve consensus.  The normal path that has served free software projects
well.


> ___
> 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] Total fees have almost crossed the block reward

[Melvin Carvalho via bitcoin-dev]

I asked adam back at hcpp how the block chain would be secured in the long
term, once the reward goes away.  The base idea has always been that fees
would replace the block reward.

At that time fees were approximately 10% of the block reward, but have now
reached 45%, with 50% potentially being crossed soon

https://fork.lol/reward/feepct

While this bodes well for the long term security of the coin, I think there
is some legitimate concern that the fee per tx is prohibitive for some use
cases, at this point in the adoption curve.

Observations of segwit adoption show around 10% at this point

http://segwit.party/charts/

Watching the mempool shows that the congestion is at a peak, though it's
quite possible this will come down over the long weekend.  I wonder if this
is of concern to some.

https://dedi.jochen-hoenicke.de/queue/more/#24h

I thought these data points may be of interest and are mainly FYI.  Though
if further discussion is deemed appropriate, it would be interesting to
hear thoughts.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev