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
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 o
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.
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 instea
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
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
someon
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 fan, I
> really wanted t
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 ca
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 because it followed the
This is the bit
Hi,
I am trying to follow this Simplicity proposal and I am seeing all over
references to ‘jets’, but I haven’t been able to find any good reference to it.
Can anyone give me a brief explanation and or a link pointing to this feature?
Thanks
> On 31 Oct 2017, at 22:01, bitcoin-dev-requ...@lists.
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).
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:
https://github.com/devrandom/btc-papers/blob/master/aux-pow.m
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" i
13 matches
Mail list logo
