<unnamed>

Public Key

npub1wz8zfl8azn6qfnx5t5d479wwnf69keeq4amvsp590nvzrunqumrqurnuay

Profile Code

nprofile1qqs8pr3yln73faqyen296x6lzh8f5azmvus27akgq6zhekpp7fswd3spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsry74rg

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:40:47 UTC

- reply

📅 Original date posted:2015-06-27
📝 Original message:I wish you were just as prudent when you were recommending full RBF to
mining pools.
On 6/27/15 11:21 AM, Peter Todd wrote:
> It's not a reasonable path forward right now given the lack of testing done with 8MB+ blocks, among many other problems. A way to help make that appear more reasonable would be to setup a 8MB testnet as I suggested, with two years or so of 8MB blocks in history as well as a large UTXO set to test performance characteristics.
--
Randi Joseph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/264e693e/attachment.html>

2023-06-07 15:23:37 UTC

- reply

📅 Original date posted:2014-07-04
📝 Original message:Hi All,
This is a bit tangential to the conversation, but since the genesis of
this conversation is Mike's decentralization blog post, I decided to
post here.
Perhaps the solution to the mining problem lies in the reward structure
rather than in the proof of work/asics.
Is it possible instead to allocate a portion of the reward to " a # of
runner up(s)" even though the runner-up(s) block will be orphaned? For
example, X% of the block reward goes to Y number of runner-ups based on
some type of criteria?
This will appear to be a bit like a tax on the winner, but it could
potentially solve the problem, since a large pool would not want to
split the pool up to solve multiple blocks.
There are some possible downsides, like probably having to keep those
orphaned blocks around in the future, etc.
If this is possible, the question that remains then, what would be the
criteria for the X% payout/allocation?
-Randi