multiple
> network nodes…check them against one another.
>
Definitely looking at or have implemented this sort of stuff. I cannot get
into detail in public...
--
Je
t;
>> >
>> >
>> >
>> --
>> >
>> >
>> >
>> > ___
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bit
stuff to... what exactly?
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-de
ankian
>
>
> ------
>
> ___
> Bitcoin-deve
in DNS) and rewrite
> the envelope-from to the list's address. Reply-to will be added and set to
> the original sender.
>
That seems to change Reply behavior for those recipients? It would seem to
accidentally direct mail intended to DKIM-user + list to DKIM-user.
--
Jeff Garzik
On Fri, Jun 19, 2015 at 10:48 AM, wrote:
> On 2015-06-19 17:40, Jeff Garzik wrote:
>
>> Making multiple incompatible versions of a spend is a -requirement- of
>> various refund contract protocols.
>>
>
> Is there not a dedicated field in a transaction (nSequ
empt unless shown otherwise?
>
Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.
some feedback:
> >
> > https://github.com/bitcoin/bitcoin/pull/6176
> >
> > Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
> > working on porting it to v0.10.2, and once that's done I'm going to put
> > up a bounty for anyone who can find a DoS attack in the patch. If no-one
> > claims the bounty after a week or
issues to address in the bitcoin ecosystem. It negatively
impacts users to roll out "scorched earth" replace-by-fee given today's
ecosystem.
Yes, zero conf security is poor. An outright attack on zero conf degrades
user security even more.
--
Jeff Garzik
Bitcoin core develop
Replace-by-Fee",
> May 25th 2015, Peter Todd, Bitcoin-development mailing list,
>
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
>
> 6) "Cost savings by using replace-by-fee, 30-90%",
>May 25th 2015, Peter Todd, Bitcoin-d
node #bitcoin-dev and
> talk to warren.
>
> Warren Togami
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
&
On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach
wrote:
> On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik wrote:
>
>>
>> The whole point is getting out in front of the need, to prevent
>> significant negative impact to users when blocks are consistently full.
>>
suming relevant Bitcoin Core standards process is failing, and
proceed with the Bitcoin-XT fork.
As I've said on IRC, the "do nothing, for now" position is untenable.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay
On Thu, Jun 18, 2015 at 9:07 AM, wrote:
> On 2015-06-18 14:53, Jeff Garzik wrote:
>
>> Consensus changes - worded another way - change Bitcoin's Constitution -
>> The Rules that everyone in the system is -forced- to follow, or be ignored
>> by the system.
>&g
from developers who
will not act if the community will disagree with the change.
The users ultimately choose by deciding which software to download, and
that dictates the range of choices available.
--
Jeff Garzik
Bitcoin core developer and open source evangel
facet.
Consensus changes - worded another way - change Bitcoin's Constitution -
The Rules that everyone in the system is -forced- to follow, or be ignored
by the system.
Changing bit
ment mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-
in chain are both
feasible and useful.
That code & future is a ways away from production, so doesn't help us
here. Still, let's not dismiss it as a solution either.
--
Jeff Garzik
Bitcoin core developer and open source eva
Adding - in re pay-to-FOO - these schemes are inherently short term, such
that it is near-impossible for the market to plan for what happens in 12+
months.
On Sun, Jun 14, 2015 at 10:28 PM, Jeff Garzik wrote:
> On Sun, Jun 14, 2015 at 5:23 PM, Adam Back wrote:
>
>> Hi
>&g
Greg Maxwell
>
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html
>
>
> ------
>
g incident
><https://www.phoronix.com/scan.php?page=news_item&px=MTc4Mzg> or GIMP-type
>hijacking <https://lwn.net/Articles/646118/>?
>-
>
>The toughest question would be the appropriateness of auto-importing
>the subscriber list to another list server, as mass imports have a tendency
>to upset people.
>
>
> Thoughts?
&g
15 at 12:06 PM, Mats Henricson
> wrote:
> > Jeff,
> >
> > with all due respect, but I've seen you saying this a few times
> > now, that this decision is oh so difficult and important.
> >
> > But this is not helpful. We all know that. Even I.
> >
>
s oh so difficult and important.
>
> But this is not helpful. We all know that. Even I.
>
> Make a suggestion, or stay out of the debate!
>
> Mats
>
> On 06/14/2015 07:36 AM, Jeff Garzik wrote:
> > The choice is very real and on-point. What should the block size limit
&
should look at the problem much
> more generally. Using false choices doesn’t really help, though ;)
>
> - Eric Lombrozo
>
>
> On Jun 13, 2015, at 10:13 PM, Jeff Garzik wrote:
>
> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo
> wrote:
>
>> 2) BIP100 has direct
fee, what is a proper level of
decentralization, a proper growth factor?
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
___
to do
> BIP100 just like they did BIP34 and BIP66. Shame on you!
>
BIP 100 requires a hard fork to engage. Users proactively opt-in.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.
fees do not provide a great incentive for miners to be in
> agreement with users, and likely won't for some time.
>
> Best,
> Stephen
>
>
>
>
> > On Jun 12, 2015, at 2:11 PM, Peter Todd wrote:
> >
> > Jeff Garzik recently proposed that the upper bl
---
>
>
> --
> ___
> Bitcoin-development mailing
> listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
On Thu, Jun 4, 2015 at 6:02 PM, Daniel Stadulis wrote:
> Off topic and inappropriate
>
Indeed.
Take this somewhere else, Mr. Berg. This is a technical mailing list.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitp
r clients, not Bitcoin. Get the fuck out.
> <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, In
ubsidiary of Dunvegan Space Systems is pursuing
exactly this as a business.
EMail jgar...@dss.co if you want to know more.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
:02 PM, Gregory Maxwell wrote:
> On Tue, May 12, 2015 at 7:38 PM, Jeff Garzik wrote:
> > One general problem is that security is weakened when an attacker can
> DoS a
> > small part of the chain by DoS'ing a small number of nodes - yet the
> impact
> > is a network-w
tcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> --
> One dashboard for servers and applications a
Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> ht
;> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>> !DSPAM:554e4e5450787476022393!
>>
>> --
>>
>> Bitcoin-development mailing list
>> Bit
ume!"
with zero thinking behind that besides "adoption!" Need to actually
project what bitcoin looks like at the desired levels, what network
resources are required to get to those levels -- including traffic to serve
those SPV clients via P2P -- and then work backwards from that
ports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> h
On Thu, May 7, 2015 at 9:40 PM, Tom Harding wrote:
> On 5/7/2015 12:54 PM, Jeff Garzik wrote:
> > 2) Where do you want to go? Should bitcoin scale up to handle all the
> > world's coffees?
>
> Alan was very clear. Right now, he wants to go exactly where Gavin'
ring the economics, forcing fees to remain low in the
hopes of achieving adoption. I'm pro-bitcoin and obviously want to see
bitcoin adoption - but I don't want to sacrifice every decentralized
principle and become a central banker in order to g
ou - rightly -
opened the topic here and now we're discussing it.
Mike and Gavin are due the benefit of doubt because making a change to a
leaderless automaton powered by leaderless open source software is breaking
new ground. I don't focus so much on how we got to this point, but rather,
wh
Dear list,
Apparently my emails are being marked as spam, despite being sent from
GMail's web interface. I've pinged our sysadmin. Thanks for letting
me know.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://
On Thu, May 7, 2015 at 11:33 AM, Justus Ranvier
wrote:
> In summary, I asked a question neither you, nor Peter Todd, want to
> answer and want to actively discourage people from even asking at all.
>
Incorrect; your question included built-in assumptions with which I
disagree.
Bitcoin needs to
ll, then we're in new territory
> entirely. Businesses built on the assumption that Bitcoin could become
> popular will suddenly have their basic assumptions invalidated. Users will
> leave. The technical code change would be zero, but the economic change
> would be significant.
>
--
On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier
wrote:
> To be extremely specific: should Bitcoin development intenionally
> limit the network's capabilities to leave room for other projects, or
> should Bitcoin attempt to be the best system possible and let the
> other projects try to keep up as
l as removing a temporary hack
> Satoshi put in place, then what about bigger challenges?
>
This is absolutely not a trivial change.
It is a trivial *code* change. It is not a trivial change to the economics
of a $3.2B system.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
rceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring
On Thu, May 7, 2015 at 10:38 AM, Justus Ranvier
wrote:
> On 05/07/2015 04:04 PM, Jeff Garzik wrote:
> > - This is a major change to the economics of a $3.2B system. This
> > change picks winners and losers. There is attendant moral hazard.
>
> This is exactly true.
>
I have a lot more written down, a WIP; here are the highlights.
- The 1MB limit is an ancient anti-spam limit, and needs to go.
- The 1MB limit is economically entrenched at this point, and cannot be
removed at a whim.
- This is a major change to the economics of a $3.2B system. This change
pic
ction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
More work per node. Greater opportunity
for algorithmic attacks, races and other shenanigans by attackers.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
BPM Ca
ccept 0-conf transactions as there is little
customer/reputation relationship to leverage. However, that
observation cannot be easily applied to most other businesses.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https:
On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón wrote:
> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik wrote:
>> This isn't some theoretical exercise. Like it or not many use
>> insecure 0-conf transactions for rapid payments. Deploying something
>> that makes 0-conf t
lopment mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>> ------
>> Download BIRT iHub F-Type - The F
conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer
net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.
ip blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.source
hand. (JSON libs are more wildspread and supported than
> protobuf)
>
> 2015-01-28 17:04 GMT+01:00 Jeff Garzik :
>
>> Not to mention the tiresome and error-prone task of writing your own
>> JSON-to-schema marshalling code -- or something equivalent to the protobufs
>> com
rsation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and
ncy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
ompletely compliant.
> http://p.sf.net/sfu/gigenet
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core dev
--
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Incre
me the line is blurred between which of those
> are security considerations vs performance considerations.
>
> Richard
>
> On 19 January 2015 at 19:09, Jeff Garzik wrote:
>
>> Text formats such as XML or JSON are far less deterministic, are more
>> loosely specified, h
wer latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.so
Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourcefor
ought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
>
tcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
---
here.
While recent code movement commits themselves are individually ACK-worthy,
professionally executed and moving towards a positive goal, I think the
project could strike a better balance when it comes to disruptive cosmetic
changes, a balance that better encourages developers to work o
disincentives for working on other
types of patches.
On Mon, Dec 15, 2014 at 4:19 PM, Cory Fields wrote:
>
> On Mon, Dec 15, 2014 at 2:35 PM, Jeff Garzik wrote:
> > On Mon, Dec 15, 2014 at 1:42 PM, Cory Fields
> wrote:
> >>
> >> That's exactly what happened d
cations, followed by data structure work, further patches are easy
to review/apply with less impact on unrelated code.
The flow of patches into the tree over time should be examined. Simply
tagging patches as movement-only does not address the described problem at
all.
--
Jeff Garzik
Bitcoin core dev
and-make-it-pretty-and-do-all-the-work.
Some change is in order, gentlemen.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Download BIRT iHub F-Type - The Free Ent
On Wed, Dec 10, 2014 at 1:47 AM, Wladimir wrote:
> Concept ACK -> agree with the idea and overall direction, but haven't
> reviewed the code changes nor tested it
>
Concept ACK -> like the idea; the code may need rewriting (or haven't
reviewed).
--
Jeff Garzik
Bitcoi
stg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
Bi
e
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.ne
wallets have obtained a reasonable
> user base and are stable.
>
>
>
> ------
>
>
e learn could define a hard fork or a better
>> chain we migrate to as discussed by blockstream.
>>
>> Tamas Blummer
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sour
problems and confusion down the road.
Though I ACK'd the change, my general preference remains to disconnect
TX and block version.
--
Jeff Garzik
Bitcoin core developer and open source evang
gular-Block-Times.html
>
> Thanks,
> Rusty.
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourcefo
; Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
hub.com/jgarzik/rpcsrv
PR #2844 @ https://github.com/bitcoin/bitcoin/pull/2844
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
ment mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
his is unlikely for well informed and
well prepared market participants.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
mailing list anyway, although if I had a different opinion I
>> certainly hope I would still send this message.
>>
>> Thank you.
>>
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507
>
> ------
> ___
> Bitcoin-dev
The whole issue is a troll, and I'm afraid you got sucked in.
There are no plans to add a blacklist to Bitcoin Core.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpa
Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-
We are slowly applying a consistent style to the C++ source, via
clang-format (LLVM) and $repo/src/.clang-format.
If you have a patch that is difficult to apply to the tree due to
reformatting, simply apply clang-format and then rediff.
--
Jeff Garzik
Bitcoin core developer and open source
ot of PGP hating these days but this comment doesn't
> necessarily apply to every situation.
>
>
>
>> On Sep 15, 2014, at 9:08 AM, Jeff Garzik wrote:
>>
>>> On Mon, Sep 15, 2014 at 3:23 AM, Thomas Zander
>>> wrote:
>>> Any and all PGP related howtos wi
nd boring
signed challenge process, for all we know, "sipa" is a supercomputing
cluster of 500 gnomes.
The point is, the "online entity known as Satoshi" is the relevant
fingerprint. That is easily established without any in-person
meetings.
--
Jeff Garzik
Bitcoin core d
ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourcefo
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd wrote:
> On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik wrote:
>>Encryption is of little value if you may deduce the same information
>>by observing packet sizes and timings.
>
> That is simply incorrect. The resources requir
gt; Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _____
-kernel-git-repositories-add-2-factor-authentication
As a first step, one possibility is putting the primary repo on
bitcoin.org somewhere, and simply mirroring that to github for each
push.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com
---
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bi
evelopment mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
---
tware that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sour
saction
publish-to-outside-world time are the same, even though they often
are.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--
Want fast and easy access to al
n do the basic P2P protocol could then be extended with not
> much code to get a multiplexed stream of messages from different clients.
>
> An additional standalone program can then bridge this mechanism to running a
> shell command for particular messages, though given the history of s
nternally. PR #4599 tries to lead by example:
https://github.com/bitcoin/bitcoin/pull/4599
A P2P service would be a slightly different sort of plug-in.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.
placement for jgarzik's proposal.
>
> Something like `getutxos` or this proposal could be implemented as an
> external application or script, instead of having to integrate
> everything into bitcoind.
Seconded. Command plug-ins and such seem like an idea worth exploring.
We don&#x
s.
>
> Additionally, nothing in this spec requires that a local bitcoind be
> running. What stops someone from advertising just NODE_EXTENDED_SERVICES and
> nothing else? I don't think a generic service advertisement mechanism is a
> bad thing to have, by the way, just pointing o
1 - 100 of 412 matches
Mail list logo
