Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

Is there an issue with the current difficulty adjustment algorithm? It's worked very well as far as I can tell. Introducing a new one seems pretty risky, what would the benefit be? On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Bitcoin

Re: [bitcoin-dev] Introducing a POW through a soft-fork

Just going to throw in my support for a POW change, not any particular implementation, but the idea. Bitcoin is technically owned by China now. That's not acceptable. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Oct 31, 2017, at 10:48

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

Whatever their failings from their previous code or their adversarial nature, they got this code right and I'm only presenting it as a real and excellent solution for the impending threat to bitcoin. As a big core fan, I really wanted to delete the word Cash from my post because I was afraid

[bitcoin-dev] Introducing a POW through a soft-fork

Hi all, Feedback is welcome on the draft below. In particular, I want to see if there is interest in further development of the idea and also interested in any attack vectors or undesirable dynamics. (Formatted version available here:

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev wrote: > Bitcoin cash will hard fork on Nov 13 to implement a new difficulty > algorithm. Bitcoin itself might need to hard fork to employ a similar > algorithm. It's about as good as they come

[bitcoin-dev] Bitcoin Cash's new difficulty algorithm

Bitcoin cash will hard fork on Nov 13 to implement a new difficulty algorithm. Bitcoin itself might need to hard fork to employ a similar algorithm. It's about as good as they come because it followed the "simplest is best" route. Their averaging window is probably significantly too long (N=144).

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

On Thu, Nov 2, 2017 at 11:53 PM, Scott Roberts wrote: > Whatever their failings from their previous code or their adversarial > nature, they got this code right and I'm only presenting it as a real and > excellent solution for the impending threat to bitcoin. As a big core

[bitcoin-dev] Electrum 3.0 release

Electrum 3.0 was tagged and released yesterday night. Release notes: # Release 3.0 - Uncanny Valley (November 1st, 2017) * The project was migrated to Python3 and Qt5. Python2 is no longer supported. If you cloned the source repository, you will need to run "python3 setup.py install"

Re: [bitcoin-dev] Simplicity proposal - Jets?

Hi Jose, Jets are briefly discussed in section 3.4 of https://blockstream.com/simplicity.pdf The idea is that we can recognize some set of popular Simplicity expressions, and when the Simplicity interpreter encounters one of these expressions it can skip over the Simplicity interpreter and

Re: [bitcoin-dev] Introducing a POW through a soft-fork

I am also concerned. However, this proposal allows two POWs to coexist and allows for gradual transitions. This is hopefully a less disruptive approach since it allows cooperative miners to migrate over time. And of course, as a soft-fork it keeps backwards compatibility with existing software.

Re: [bitcoin-dev] Simplicity proposal - Jets?

Hi everyone, I agree that the paper could use some more details on the rationale behind "jets". After a couple of reads, I think I can "ELI5 them": As far as I understand, jets are a smart optimization that makes complex Simplicity contracts way cheaper to compute (ideally, comparable to Script

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

You launched the political football by coming here with a verbose 'recommendation'. Without a code submission in form of pull request to the core repo on github this was never a technical discussion. On Thu, 2017-11-02 at 19:53 -0400, Scott Roberts via bitcoin-dev wrote: > Whatever their failings