I appreciate the bluntness, Jeremy, and agree it's high time folks enjoy the
holiday.
Cheers,
-Yancy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Dear Bitcoin Developers,
There are no current agenda items or technical issues to weed out,
everything has been through the grinder, and Bitcoin Core seems to be on a
roll with getting Release Candidate 1 with Speedy Trial MTP in the pipe.
If anyone is hazy on the details -- it has been a little
Peter, thanks for the links. I'm aware that there are other timestamping
aggregation services that already exist, but I had some different ideas
that integrate into some other services. Also thanks for sending the link
to the single use seal asset transfer. I will take a look at that.
On Sat, Apr
On Sat, Apr 17, 2021 at 03:57:55AM +, Christopher Gilliard via bitcoin-dev
wrote:
> Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
> in the blockchain and it's not feasible to block all of them. That is why
> it's important to, at the same time as limiting the OP_RET
On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev wrote:
> The transition *could* look like this:
> - validating nodes begin to require proof-of-burn, in addition to
> proof-of-work (soft fork)
> - the extra expense makes it more expensive for miners, so POW slowly drops
>
Hi Erik,
Here's a scheme I posted here a few years ago, which smoothly transitions
using geometric mean chain weight / difficulty:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015236.html
On Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.
Yes, transition from Proof of Work to Proof of Something Else is possible in a
soft-fork way. All that is needed is getting miners and users support. Then,
Proof of Work difficulty should drop to one, and the rest would be solved by
Proof of Something Else. Old miners still could use ASIC miners
Indeed, it was 40 then 80 then 40 again and then 80 at the end (or
something like this.. not sure about the exact history!).
Looking forward to the proposal(s).
On Fri, Apr 16, 2021 at 11:12 PM Christopher Gilliard <
christopher.gilli...@gmail.com> wrote:
> Thanks for the feedback. Will update t
Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
in the blockchain and it's not feasible to block all of them. That is why
it's important to, at the same time as limiting the OP_RETURN to one per
block, also propose and implement a layer 2 solution for timestamping
so peopl
