pull down to refresh
Rene actually did a talk that touches on this paper.
https://youtu.be/c3AuaHJordg
Nothing prevents a miner from omitting transactions from their own block template. They will just make less money in fees compared to other miners that do fill up the block to 4000000 weight units according to the current consensus rules.
The witness discount is consensus. You can fit up to 4 MB of witness data into a block per consensus, since 4 MB of witness = 1 vMB.
So you are saying we should uncap the block size limit as long as its filled with witness data?
It is simple and doable with policy or a soft fork.
What you are proposing would require a hard fork.
Make a poll.
Good idea. Why didn't I think of that: #1405126
That being said the real fix to all this crap is utreexo.
Yeah true, would be nice to finally see some adoption of utreexo in major implementations.
You can also just use an RSS reader and add a channel feed. Just need to plug the channel id into the following URL:
https://www.youtube.com/feeds/videos.xml?channel_id=<channel id>
For example BTC Sessions:
https://www.youtube.com/feeds/videos.xml?channel_id=UChzLnWVsl3puKQwc5PoO6Zg
But it seems this is what this tool already does in the background for you.
KeePassXC allows you to store passkeys in your password database which is just a file you can copy anywhere you want.
pk+sig size in the witness will be about 2,000 vB. For comparison, pk+sig for Schnorr is about 25 vB.
Quantum signature size is almost 100x bigger. PQC does not scale on Bitcoin.
It also seems kind of silly to me to be worrying about quantum resistance now when Shor's algorithm on a quantum computer has seen no progress since 2012 when the number 21 was factored.
The larger miner Avalon S3 Nano is reporting a constant real time 3.23 TH with 11580 accepted and 29 rejected while Braiins reports 2.9 TH.
Alright, so the difficulty seems fine on this one, since you are finding a share about every 3-4 seconds on average.
Over which timeframe does Braiins report these 2.9 TH/s? Keep in mind that this is just an estimate based on the average number of shares you submitted within a certain timeframe.
Yes maybe the Lucky miner has a lot rejected.
Maybe... doesn't Braiins show that?
Does Braiins sharing the same block template with other pools mean they cannot be cheating on payouts?
No, this is unrelated. It means that Braiins and the other pools that share the same block template are essentially one big pool. And if you are mining with a big pool, you are contributing to mining pool centralization (at least on stratumv1).
Check how many accepted/rejected shares your miners have. (If the miners show that)
Maybe you just got unlucky and did not find many shares in that one hour period.
If you find shares only very rarely, it might make sense to mine at a lower difficulty.
And btw, Braiins Pool seems to share the same block template with other pools:
https://stratum.work/sankey
Given the data presented in this analysis, there is a reasonable case for deprecating the creation of new P2MS outputs. That is, introducing a soft fork to make the creation of new P2MS outputs invalid by consensus.
Yes!
And should also probably include P2PK.
One turns Bitcoin from decentralized into centralized.
The other is just the usual decentralized consensus forming.
Let's imagine a fork happens and 40% of hash is on the new rules and 60% of hash remains on the old rules.
The chain with the old rules outgrows the one with new rules. (for now)
Let's say at a later point in time more miners switch from the old rules to the new rules. Now 60% of hash is on the new rules, while 40% is on the old rules. In this case the new chain will eventually outgrow the old one. Now the new chain is also the valid one according to the old rules, since it is longer. Thus the blocks on the old chain are replaced by the ones on the new fork.
A 51% attack would be a single entity reorging the chain because they have the majority of the hash rate.
A soft fork does NOT require a 51% attack. We had soft forks in the past. It just requires consensus among at least >50% of the hash rate.
This refers to the shut down Samourai Whirlpool.
But the coordinators listed on https://liquisabi.com/ use the WabiSabi protocol used by Wasabi Wallet which does not share the users xpub.
Are you really checking the policy between Stacker.news and Megalithic.me? When did you check the channel policy? Maybe it changed after you made the payment. Maybe your state of the graph was outdated.