On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote:
> Gregory Maxwell via bitcoin-dev
> writes:
> > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
> > wrote:
> >> Hi all,
> >>
> >> I'd like to pick up the discussion from a few months ago, and
Gregory Maxwell via bitcoin-dev writes:
> On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
> wrote:
>> Hi all,
>>
>> I'd like to pick up the discussion from a few months ago, and propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
>
> I
Hello all,
I was working on this project for the last few months, so a user could run his
own Electrum server, with required hardware resources not much beyond those of
a full node (using ideas from ElectrumX [1], Electrum Personal Server [2] and
bitcoincore-indexd [3]).
The code and usage
The bitcoin alert keys are disclosed in this email, followed by a
disclosure of various known vulnerabilities in what was once the alert
system. The bitcoin alert system has been completely retired. The
network is not at risk and this warning may be safely ignored if you
do not have an ancient
On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev
wrote:
> The bit 0 to 3 of hashtype denotes a value between 0 and 15:
>
> • If the value is 1, the signature is invalid.
> • If the value is 3 or below, hashPrevouts is the hash of all input,
> same as defined in
On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
wrote:
> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
I know it seems kind of silly, but I think it's