Randi Joseph [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-07-04 to 2015-06-27
💬 Posted a total of 3 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:40:47

- 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:38

- reply

📅 Original date posted:2014-07-06
📝 Original message:Thanks Mike.
Indeed, I am aware of current approach, which is why I was suggesting
this as an alternative.
I haven't thought about it enough, and perhaps it was too radical a
rethinking - just wanted to see what the smarter minds thought.
Thanks again.
-Randi
On 7/5/14, 4:43 AM, Mike Hearn wrote:
>
> 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?
>
>
> There's really no concept of a "runner up" because hashing is progress
> free. It's unintuitive and often trips people up. There's no concept
> that everyone is 95% of the way to finding a solution and then someone
> pips you to the post. It's more like playing the lottery over and over
> again. Doesn't matter how many times you did it before, the next time
> your chances are the same.
>
> A better concept is of rewarding "near miss" solutions which is what
> we already do of course, via pools, which pay you for shares which
> don't quite meet the difficulty target but almost do. So the question
> is how can we implement pools which have this reward structure (which
> obviously works well) without miners simultaneously giving up their
> right to block creation either due to technical problems or sheer
> lazyness.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140706/1936adfc/attachment.html>

2023-06-07 15:23:37

- 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