What if a miner mines a block that has a very high block reward (i.e.
confirmed a juicy transaction), while at the same time having a floating
point fitness very close to the minimum?
For the sake of argument, let's say the block reward is 6.50 (4% more
than average), the fitness is 1.001,
Currently, Bitcoin's timestamp rules are as follows:
1. The block timestamp may not be lower than the median of the last 11
blocks'
2. The block timestamp may not be greater than the current time plus two
hours
3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
06:28:16
The reason Samourai did not propose a BIP is that that was not a
proposal to improve the Bitcoin protocol.
You could write a specification for it, but this mailing list is
probably the wrong venue.
On 2020-12-06 18:20, Prayank via bitcoin-dev wrote:
Hello Everyone,
I know there have been
On 2020-11-23 12:24, AdamISZ via bitcoin-dev wrote:
‐‐‐ Original Message ‐‐‐
On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev
wrote:
Canvassing opinions/critiques from those working on bitcoin and
related protocols.
See the attached gist for a write-up of an outline of an
of PoS/PoB (assuming
all incentive problems are solved).
ie: once you have uses PoW to bootstrap the system, you can "recycle"
that work.
On Thu, Jun 24, 2021 at 4:41 PM yanmaani--- via bitcoin-dev
wrote:
No, 51% of the *coin holders* can't do diddly squat. 51% of miners
can,
but
No, 51% of the *coin holders* can't do diddly squat. 51% of miners can,
but in PoW, that's a different set to the coin holders.
The basic problem with PoS, anyway, is that it's not actually a
consensus system ("weak subjectivity"). Either you allow long reorgs,
and then you open the door to
This is silly, but I'll add my take:
This would create the incentive to have chips that are idle 50% of the
time and work harder 50% of the time. This means miners would buy twice
the chips to use the same amount of power, for example.
This in turn means a greater portion of your operational
Why the existing mnemonic? If you've already dealt with unencrypted
material carelessly, the genie is out of the bottle. And if you're OK
with making a new one, why not just use BIP-39 passphrases to begin
with?
If you must, it seems like a decent way to accomplish it, but raw
SHA-256 is
On 2021-03-03 20:48, Chris Belcher wrote:
On 03/03/2021 17:30, yanma...@cock.li wrote:
Is that supposed to be a good thing? "We should do X because it'll
work"
doesn't prove X is actually good. These things can be evil, but they
can
also be legitimate opposition to a change. Taking away the
for LOT=true holds
And all of the arguments for LOT=false are satisfied by the cool down
period.
On Mon, Mar 1, 2021, 12:05 PM yanmaani--- via bitcoin-dev
wrote:
How about a compromise?
With LOT=false, taproot will be activated if at least 95% of the
miners
vote yes.
With LOT=true, taproot will
On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
Enter flag day activation. With a flag day there can be no
brinksmanship. A social media blitz cant do anything except have its
own
followers fork away. Crucially, miner signalling cant be used to change
the activation date for nodes
How about a compromise?
With LOT=false, taproot will be activated if at least 95% of the miners
vote yes.
With LOT=true, taproot will be activated if at least 0% of the miners
vote yes.
...with LOT=maybe, taproot will be activated if at least ~some% of the
miners vote yes?
If you want the
Bitcoin presently suffers from unconstrained UTXO set growth. It would
be possible to disincentivize this and incentivize consolidating UTXOs
by adding a block weight penalty for UTXO creation, and bonus for UTXO
destruction:
* For each block, calculate the net change in UTXOs. If all the
This has already been discussed and proposed in various papers and
articles, typically to replace SHA-256d with something else. It
basically works, but there's a some tiny issues:
1) Who goes first?
If you first calculate the expensive PoW and then do a cheap SHA-256d
around it, anyone can
If only one hash is allowed per block, then those who wish to utilize
the hash will have to out-bid each other ("fee-bidding"). This hash can
then be used to create another chain ("merged-mining")
Merged mining at present only needs one hash for a merkle root, and
that's stored in the
You appear to have reinvented Namecoin ;)
On 2021-04-21 20:28, Christopher Gilliard via bitcoin-dev wrote:
I have created an additional BIP that is associated with the recent
BIPs that I have sent to the mailing list. This one defines a
decentralized naming protocol. The BIP can be found
What, no. The `k` value is calculated implicitly, because there's only
one value of it that could ever be valid - if `k` is 1 too small, we're
70 years too far back, and then the block will violate median of last
11. If `k` is 1 too large, we're 70 years too far in the future, then
the block
It's well-known. Nobody really cares, because it's so far off. Not
possible to do by softfork, no. It is possible to do by something that
becomes a hardfork in 80 years, though, which is probably good enough.
I proposed a solution, but nobody was really interested. Let's see if
anyone bites
Well, it's the right word. If you're going to do a hardfork by changing
the timestamp definition, you're already doing a hardfork. At that
point, you've already crossed the Rubicon and might as well put in any
other necessary changes (e.g. to transaction locking), because it will
be as much of
[I removed a comment regarding the moderation of this list here because
it caused for my message to be rejected]
On 2021-10-26 02:56, lisa neigut via bitcoin-dev wrote:
[...] the mempool is obsolete and should be eliminated.
Instead, users should submit their transactions directly to mining
On 2021-11-05 08:17, Prayank via bitcoin-dev wrote:
What followed it (whitepaper being shared on different websites) was
true decentralization and we need something similar in other aspects
of full node implementations. Few things that can improve
decentralization:
1.More people using
How does this differ from p2pool?
If you've just re-invented p2pool, shouldn't you credit their prior art?
Monero is doing their implementation of p2pool. They have viable solo
mining, as far as I understand. The basic idea is you have several
P2pools. If you have a block time of 10 minutes,
On 2022-02-07 14:34, Billy Tetrud via bitcoin-dev wrote:
I do think that UTXO set size is something that will need to be
addressed at some point. I liked the idea of utreexo or some other
accumulator as the ultimate solution to this problem.
What about using economic incentives to
23 matches
Mail list logo
