I very much agree with AJ here. This is something I remember discussing on
Bitcointalk back in 2011: I find it highly intuitive that the amount of
lost coins is not a constant fraction of the supply, because people get
better at keeping their coins with increasing value, distribution and
On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If transaction fees came in at an even rate over time all at the exact
> same level then they work fine for security, acting similarly to fixed
> block rewards. Unfortunately that isn't
On Mon, Jul 11, 2022 at 10:00 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> If you actually do the numbers on this, you'll realize it takes absolutely
> catastrophic black swan events that make WW2 look like a minor conflict to
> make
> even insignificant
I believe it's foolish to attempt objective definitions of things that we
define collectively, like "Bitcoin." The best any one of us can do is to
be consistent with a subjective personal definition. I believe most people
do that with the term "Bitcoin" and that the capped supply is intrinsic to
If transaction fees came in at an even rate over time all at the exact same
level then they work fine for security, acting similarly to fixed block
rewards. Unfortunately that isn't how it works in the real world. There's a
very well established day/night cycle with fees going to zero overnight
Sorry, I totally forgot the checksum.
You can take my ops-per-second and multiply it by about 16 (because of the
4 check bits), making a delete + two swaps or 4 swaps, etc. still pretty
reasonable.
On Mon, Jul 11, 2022 at 9:11 AM Erik Aronesty wrote:
> 1. You can swap two positions, and then
>
>
> Alternatively, losses could be at a predictable rate that's entirely
> different to the one Peter assumes.
>
No, peter only assumes that there *is* a rate.
Regardless of what the rate is, if it is any value for which there exists
*any fixed central tendency*, tail emission is *evenually*
1. You can swap two positions, and then your recovery algorithm can
brute-force the result by trying all 132 possible swaps.
2. You can make a single deletion and only have to brute 2048
3. You can keep doing these, being aware that it becomes geometrically more
difficult each time (deletion +
Update: Bob doesn't have to watch all address types he's advertising. When
notifying Bob, Alice will pick one address type out of the ones Bob is
advertising and include it in the notification. That way even if Bob's wallet
accepts many address types, he still doesn't have to watch all of them
I think the discussion has some anecdotic interest but has zero relevance
as far as any decision making is concerned.
Any extension of block rewards after the current deadline should only be
done if and only if the community agrees that it is the only way to keep
the network secure.
The fact
On Mon, Jul 11, 2022 at 12:32:47PM +1000, Anthony Towns wrote:
> This isn't necessarily true: if the losses are due to a common cause,
> then they'll be heavily correlated rather than independent; for example
> losses could be caused by a bug in a popular wallet/exchange software
> that sends
On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote:
> On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via bitcoin-dev
> wrote:
> > > What happens after that I'm not sure.
> > >
> >
> > Miners will learn to create anyone-can-spend outputs to bribe other miners
>
On Tue, Jul 12, 2022 at 02:01:09AM +0200, James MacWhyte wrote:
> On Tue, Jul 12, 2022 at 12:26 AM Peter Todd wrote:
>
> > Anyway, designing protocols for "price go up forever" hopium is a bad idea.
> >
>
> I'm quite disappointed that this is what you've reduced my argument to. The
> price
On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> > What happens after that I'm not sure.
> >
>
> Miners will learn to create anyone-can-spend outputs to bribe other miners
> to build on their block rather than reorg it. (Due to the coinbase
> maturity, this
On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev wrote:
> If transaction fees came in at an even rate over time all at the exact same
> level then they work fine for security, acting similarly to fixed block
> rewards. Unfortunately that isn't how it works in the real world.
On Tue, Jul 12, 2022 at 12:19:06AM +0200, James MacWhyte via bitcoin-dev wrote:
> I think many of these discussions about the loss of the mining reward are
> fatally shortsighted.
>
> It's always daytime somewhere--when you talk about volume dropping at
> night, that simply means there is not
> If in the future Bitcoin is entirely dependent on fees for security
(scheduled very strongly) and this pattern keeps up (overwhelmingly likely)
then this is going to become a serious problem.
We should carefully define "when" this becomes an issue.
Suppose the reward is 1.5625 BTC. That's
This problem can be solved by mining decentralization.
> What's likely to happen is that at first there will simply be no or very few
> blocks mined overnight.
Why? When it comes to energy usage, there are also cycles, because energy usage
during the day is definitely higher than at night. You
>
> Miners will learn to create anyone-can-spend outputs to bribe other miners
> to build on their block rather than reorg it. (Due to the coinbase
> maturity, this will require some amount of floating capital.)
>
(reward + avg fee) * 144 * 365 (one year) == approximate investment needed
to
On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> Oops, you are right. We need the bribe to be the output of the coinbase,
> but due to the maturity rule, it isn't really a bribe.
>
> Too bad coinbases cannot take other coinbase outputs as inputs to bypass
>
On 11 Jul 2022, at 19:12, Bram Cohen via bitcoin-dev
wrote:
> There's a very well established day/night cycle with fees going to zero
> overnight and even longer gaps on weekends and holidays. If in the future
> Bitcoin is entirely dependent on fees for security (scheduled very strongly)
>
The expectation is that in a few years a space in the block will be very
competitive / expensive and be used only as a bridge for second layers or
big transactions. Who would have thought in 2017 that one day we would be
worried about cheap rates!
Anyway, it seems like a good point and I suggest
On Tue, Jul 12, 2022 at 12:26 AM Peter Todd wrote:
> Anyway, designing protocols for "price go up forever" hopium is a bad idea.
>
I'm quite disappointed that this is what you've reduced my argument to. The
price doesn't need hopium; if it stays between where it is now and the all
time high,
I think many of these discussions about the loss of the mining reward are
fatally shortsighted.
It's always daytime somewhere--when you talk about volume dropping at
night, that simply means there is not enough activity outside the US. If
Bitcoin continues its rise in price, mining rewards will
On Sun, Jul 10, 2022 at 3:05 AM vjudeu via bitcoin-dev
wrote:
>
> Not really, because people that run full nodes, just accepted Segwit
> and Taproot. They had no choice. And in case of zero satoshis, it could
> be the same: you would see zero if you look at raw bytes, but you will
> see non-zero
On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev wrote:
> If transaction fees came in at an even rate over time all at the exact same
> level then they work fine for security, acting similarly to fixed block
> rewards. Unfortunately that isn't how it works in the real world.
On Mon, Jul 11, 2022 at 08:56:04AM -0400, Erik Aronesty via bitcoin-dev wrote:
> > Alternatively, losses could be at a predictable rate that's entirely
> > different to the one Peter assumes.
> No, peter only assumes that there *is* a rate.
No, he assumes it's a constant rate. His integration
Oops, you are right. We need the bribe to be the output of the coinbase,
but due to the maturity rule, it isn't really a bribe.
Too bad coinbases cannot take other coinbase outputs as inputs to bypass
the maturity rule.
I guess that means the bribe has to be by leaving transactions in the
28 matches
Mail list logo
