On Thu, May 10, 2018 at 5:59 AM, Bradley Denby via bitcoin-dev
wrote:
> Hi all,
>
> ...
>
> This iteration of Dandelion has been tested on our own small network, and we
> would like to get the implementation in front of a wider audience. An
> updated
> BIP document with further details on motivati
Really like that you're moving forward with this. A few months ago I was
working on something similar as it seemed like nobody else was interested.
In regards to the specific proposal, would it make sense to offer a tx
subscription endpoint in addition to TRANSACTION_DATA_REQUEST? Such an
endp
It isn't being discussed atm (but was discussed 1 year ago when the BIP
draft was originally published), as we're in the process of removing items
or filters that aren't absolutely necessary. We're now at the point where
there're no longer any items we can remove w/o making the filters less
general
On Fri, Jun 01, 2018 at 02:53:01AM +0800, Johnson Lau via bitcoin-dev wrote:
> I’ve made a PR to add a new policy to disallow using SIGHASH_SINGLE without
> matched output:
>
> https://github.com/bitcoin/bitcoin/pull/13360
>
> Signature of this form is insecure, as it commits to no output while
On Tue, Jun 05, 2018 at 07:17:52PM -0500, Chris Stewart via bitcoin-dev wrote:
> Do you have any thoughts on expanding this to SIGHASH_NONE? Perhaps someone
> else on the dev list can enlighten me, but is there a current use case for
> SIGHASH_NONE that would suffer from it being non standard?
SIG
Do you have any thoughts on expanding this to SIGHASH_NONE? Perhaps someone
else on the dev list can enlighten me, but is there a current use case for
SIGHASH_NONE that would suffer from it being non standard?
-Chris
On Thu, May 31, 2018 at 1:53 PM, Johnson Lau via bitcoin-dev <
bitcoin-dev@list
Been working on this one for a while, so its already been through a few
rounds of feeback (thanks to all those who already have provided feedback)!
At a high level, this meets a few goals:
1) Replace getblocktemplate with something that is both more performant
(no JSON encoding, no full transacti
On Tue, Jun 5, 2018 at 1:08 AM, Jim Posen via bitcoin-dev
wrote:
> hesitant to make the complexity tradeoff for bandwidth savings due to a
> behavior that is actively discouraged.
As an important point of clarification here. If scripts are used to
identify inputs and outputs, then no use is requi
>
> I don't understand this comment. The bandwidth gains are not from
> address reuse, they are from the observed property that false
> positives are independent between two filters. I.e. clients that
> connect once a day will probably download 2-3 filters at most, if they
> had nothing relevant in
On 30/05/18 12:17 PM, Darren Weber via bitcoin-dev wrote:
>
> Apologies for brevity, noob here and just throwing out an idea in case
> it's useful (probably already covered somewhere, but I haven't got
> time to do all the necessary background research).
>
> From https://github.com/bitcoin/bitcoin/
10 matches
Mail list logo
