John Newbery [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-12-23 to 2021-04-27
💬 Posted a total of 14 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:00:06

- reply

📅 Original date posted:2020-05-05
📝 Original message:
There doesn't seem to be anything in the original email that's specific to
BIP 157. It's a restatement of the arguments against light clients:
- light clients are a burden on the full nodes that serve them
- if light clients become more popular, there won't be enough full nodes to
serve them
- people might build products that depend on altruistic nodes serving data,
which is unsustainable
- maybe at some point in the future, light clients will need to pay for
services
The choice isn't between people using light clients or not. People already
use light clients. The choice between whether we offer them a light client
technology that is better or worse for privacy and scalability.
The arguments for why BIP 157 is better than the existing light client
technologies are available elsewhere, but to summarize:
- they're unique for a block, which means they can easily be cached.
Serving a filter requires no computation, just i/o (or memory access for
cached filter/header data) and bandwidth. There are plenty of other
services that a full node offers that use i/o and bandwidth, such as
serving blocks.
- unique-for-block means clients can download from multiple sources
- the linked-headers/filters model allows hybrid approaches, where headers
checkpoints can be fetched from trusted/signed nodes, with intermediate
headers and filters fetched from untrusted sources
- less possibilities to DoS/waste resources on the serving node
- better for privacy
> The intention, as I understood it, of putting BIP157 directly into
bitcoind was to essentially force all `bitcoind` users to possibly service
BIP157 clients
Please. No-one is forcing anyone to do anything. To serve filters, a node
user needs to download the latest version, set `-blockfilterindex=basic` to
build the compact filters index, and set `-peercfilters` to serve them over
P2P. This is an optional, off-by-default feature.
Regards,
John
On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning ariard and luke-jr
>
>
> > > Trust-minimization of Bitcoin security model has always relied first
> and
> > > above on running a full-node. This current paradigm may be shifted by
> LN
> > > where fast, affordable, confidential, censorship-resistant payment
> services
> > > may attract a lot of adoption without users running a full-node.
> >
> > No, it cannot be shifted. This would compromise Bitcoin itself, which for
> > security depends on the assumption that a supermajority of the economy is
> > verifying their incoming transactions using their own full node.
> >
> > The past few years has seen severe regressions in this area, to the point
> > where Bitcoin's future seems quite bleak. Without serious improvements
> to the
> > full node ratio, Bitcoin is likely to fail.
> >
> > Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> > and should be actively avoided. BIP 157 improves privacy of fn-less
> usage,
> > while providing no real benefits to full node users (compared to more
> > efficient protocols like Stratum/Electrum).
> >
> > For this reason, myself and a few others oppose merging support for BIP
> 157 in
> > Core.
>
> BIP 157 can be implemented as a separate daemon that processes the blocks
> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>
> The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly service
> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
> fullnode to get BIP157 service.
> This is supposed to improve to the situation relative to e.g. Electrum,
> where there are far fewer Electrum servers than fullnodes.
>
> Of course, as ariard computes, deploying BIP157 could lead to an effective
> DDoS on the fullnode network if a large number of BIP157 clients arise.
> Though maybe this will not occur very fast? We hope?
>
> It seems to me that the thing that *could* be done would be to have
> watchtowers provide light-client services, since that seems to be the major
> business model of watchtowers, as suggested by ariard as well.
> This is still less than ideal, but maybe is better than nothing.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200505/be23bd38/attachment-0001.html>

2023-06-09 12:45:30

- reply

📅 Original date posted:2015-12-23
📝 Original message:
Hi all,
I've created a gist describing this idea here:
https://gist.github.com/jonnynewbs/a8ac4d7d27cb74c5b486 with images.
I recently watched Joseph Poon's presentation at the scaling bitcoin HK
conference. He argued that there's a natural tendency *away* from hubs and
centralization in lightning network, because a hub needs to hold bitcoin in
reserve for each payment channel:
image 1:
https://gist.githubusercontent.com/jonnynewbs/a8ac4d7d27cb74c5b486/raw/839cf9152630ee8c5596b55e206b6f7f42121c61/zHub1.jpg
In this example Hector has tied up 40 bitcoin in order to open channels
with 4 nodes. He needs to place his bitcoin in those channels in order to
have enough liquidity to route payments through the channels. If all the
bitcoin in the channel had been fronted by the nodes, he wouldn't be able
to route payments.
In this example Alice tries to pay Bob through Hector, but Hector's channel
to Bob is depleted on Hector's side so he can't pay:
image 2:
https://gist.githubusercontent.com/jonnynewbs/a8ac4d7d27cb74c5b486/raw/839cf9152630ee8c5596b55e206b6f7f42121c61/zHub2.jpg
The velocity of money through each of those channels is going to be low, so
Hector's profit opportunity to charge transfer fees on those channels is
low compared to the time that he's tying up his assets.
I started thinking about why it was that Hector would actually need to tie
up those funds. A properly-functioning hub should always have a net balance
of zero - all outflows from the hub are matched by inflows from another
node, so if the hub is working properly, it should always be solvent. Why
then does it necessarily need to hold a reserve for each node it connects
to?
Imagine someone wanted to create a hub in lightning *without* tying up
funds in lots of channels. One way he might start thinking about it:
1. Create some metatoken/coloured coin on top of bitcoin. Lets call it
Hectorcoin.
2. Open channels to different nodes, where the node provides the bitcoin
for the channel, and the hub provides Hectorcoins in the other direction.
The hub would only need to provide a negligable amount of actual bitcoin
value with Hectorcoins encoded on top of that small input.
3. If the channel gets closed and the node is net positive (ie in the
channel the bitcoin they initially provided plus some Hectorcoin), the node
can 'sell' the Hectorcoin back to the hub for bitcoin.
Hector's network would initially look like this. Bitcoin are in black,
Hectorcoin are in bold green:
image 3:
https://gist.githubusercontent.com/jonnynewbs/a8ac4d7d27cb74c5b486/raw/839cf9152630ee8c5596b55e206b6f7f42121c61/zHub3.jpg
Transactions flow through the hub, and eventually Alice is 10 'bitcoin' up.
Hector hasn't sent her 10 real bitcoin through the channel, but 10
Hectorcoin. The network now might look like this:
image 4:
https://gist.githubusercontent.com/jonnynewbs/a8ac4d7d27cb74c5b486/raw/839cf9152630ee8c5596b55e206b6f7f42121c61/zHub4.jpg
Note that Hector's balace of (Bitcoin + Hectorcoin) always remains 40.
Alice now wants to cash out her channel. She closes the channel as normal,
and then presents the Hectorcoin to Hector in exchange for actual bitcoin.
At this point either:
- Hector is holding enough bitcoin in reserve to pay out to Alice; or
- Hector doesn't hold enough bitcoin in reserve (In this scenario Hector
has a temporary *liquidity* issue, but remains *solvent*). He therefore
needs to close down his channels to Dan and Claire to free up his bitcoin
tied up in those channels.
This basic example requires counterparty trust in Hector. That's because
there's no way to prove that he actually holds enough bitcoin in his
reserves/channels to pay out in exchange for Hectorcoin *unless* those
coins are provable locked up somewhere (eg a multisig), which defeats the
whole purpose - he's trying to avoid tying up value. However, many people
might consider the efficiency and connectedness of dealing with a hub to be
a worthwhile trade-off on balance.
Hector might think about improving his hub by:
- somehow providing a proof that his net position is zero and so he's
provably solvent. That would eliminate the risk of a hub going rogue,
extracting coins from the network and becoming insolvent
- Having some way for Alice to automatically exchange Hectorcoin for that
value without asking Hector's permission.
Both of those things feel like they're possible, but perhaps someone
smarter than I am can comment on whether they actually are.
I'm not suggesting that this is the way we want to go, but thought it was
interesting enough to share. Interested to hear people's thoughts.
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151223/2f9e7486/attachment.html>

2023-06-07 22:52:13

- reply

📅 Original date posted:2021-04-27
📝 Original message:ACK. These seem like very reasonable next steps.
On Mon, Apr 26, 2021 at 8:43 PM David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > In general, I think its time we all agree the BIP process has simply
> failed
> > and move on. Luckily its not really all that critical and proposed
> protocol
> > documents can be placed nearly anywhere with the same effect.
>
> I recommend:
>
> 1. We add additional BIP editors, starting with Kalle Alm (if there are
> no continuing significant objections).
>
> 2. We seek Luke Dashjr's resignation as BIPs editor.
>
> 3. We begin treating protocol documents outside the BIPs repository as
> first-class BIP documentation.
>
> The first recommendation permits continued maintenance of existing BIPs
> plus gives the additional maintainers an opportunity to rebuild the
> credibility of the repository.
>
> The second recommendation addresses the dissatisfaction of many BIP
> authors and potential authors with the current editor, which I think
> will discourage many of them from making additional significant
> contributions to the repository. It also seems to me to be a better use
> of Luke's talents and interests for him to focus on protocol research
> and review rather than procedurally checking whether a bunch of
> documents are well formed.
>
> The third recommendation provides an escape hatch for anyone, such as
> Matt, who currently thinks the process has failed, or for anyone who
> comes to that same conclusion in the future under a different editing
> team. My specific recommendations there are:
>
> a. Anyone writing protocol documentation in the spirit of the BIP
> process can post their idea to this mailing list like we've always
> done and, when they've finished collecting initial feedback, they can
> assign themselves a unique decentralized identifier starting with
> "bip-". They may also define a shorter alias that they encourage
> people to use in cases where the correct document can be inferred
> from context. E.g.,
>
> bip-wuille-taproot (bip-taproot)
> bip-towns-versionbits-min-activation-height (bip-vbmah)
> bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
>
> b. The author then publishes the document to any place they'd like,
> although
> they are strongly encouraged to make any document source available
> under an open license to ensure others can create their own
> modifications.
>
> c. Implementations of BIPs, whether original repository BIPs or
> decentralized BIPs, link to the BIPs they implement to ensure
> researchers and developers can find the relevant protocol
> documentation. E.g.,
>
> https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
>
> (It may also be advisable for implementations to mirror copies of
> the BIPs they implement so later modifications to the document
> don't confuse anyone. For this reason, extremely liberal
> licensing of BIP documents is encouraged.)
>
> d. To help maintain quality and consistency between documentation, the
> BIP editors provide a BIP document template, guidelines similar to
> the existing BIP2, and an easy-to-run format linter.
>
> I think this decentralized BIPs alternative also helps address some
> longstanding problems with the BIPs system: that many casual Bitcoin
> users and developers think of documents in the BIPs repo as
> authoritative and that there are some development teams (such as for LN)
> that have already abandoned the BIPs process because, in part, they want
> complete control over their own documentation.
>
> The recommendations above were developed based on conversations I had
> with a few stakeholders in the BIPs process, but I did not attempt a
> comprehensive survey and I certainly don't claim to speak for anyone
> else. I hope the recommendations are satisfactory and I look forward to
> your feedback.
>
> Thanks,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210427/274ceb28/attachment.html>

2023-06-07 22:52:03

- reply

📅 Original date posted:2021-04-23
📝 Original message:ACK adding Kalle.
On Fri, Apr 23, 2021 at 4:36 AM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> ACK adding Kalle.
>
> Kalle is a qualified reviewer / editor and well suited for this role.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Thu, Apr 22, 2021 at 7:09 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
>> assist in merging PRs into the bips git repo.
>>
>> Since there is no explicit process to adding BIP editors, IMO it should
>> be
>> fine to use BIP 2's Process BIP progression:
>>
>> > A process BIP may change status from Draft to Active when it achieves
>> > rough consensus on the mailing list. Such a proposal is said to have
>> > rough consensus if it has been open to discussion on the development
>> > mailing list for at least one month, and no person maintains any
>> > unaddressed substantiated objections to it.
>>
>> A Process BIP could be opened for each new editor, but IMO that is
>> unnecessary. If anyone feels there is a need for a new Process BIP, we
>> can go
>> that route, but there is prior precedent for BIP editors appointing new
>> BIP
>> editors, so I think this should be fine.
>>
>> Please speak up soon if you disagree.
>>
>> Luke
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210423/8b232111/attachment.html>

2023-06-07 18:24:19

- reply

📅 Original date posted:2020-05-05
📝 Original message:There doesn't seem to be anything in the original email that's specific to
BIP 157. It's a restatement of the arguments against light clients:
- light clients are a burden on the full nodes that serve them
- if light clients become more popular, there won't be enough full nodes to
serve them
- people might build products that depend on altruistic nodes serving data,
which is unsustainable
- maybe at some point in the future, light clients will need to pay for
services
The choice isn't between people using light clients or not. People already
use light clients. The choice between whether we offer them a light client
technology that is better or worse for privacy and scalability.
The arguments for why BIP 157 is better than the existing light client
technologies are available elsewhere, but to summarize:
- they're unique for a block, which means they can easily be cached.
Serving a filter requires no computation, just i/o (or memory access for
cached filter/header data) and bandwidth. There are plenty of other
services that a full node offers that use i/o and bandwidth, such as
serving blocks.
- unique-for-block means clients can download from multiple sources
- the linked-headers/filters model allows hybrid approaches, where headers
checkpoints can be fetched from trusted/signed nodes, with intermediate
headers and filters fetched from untrusted sources
- less possibilities to DoS/waste resources on the serving node
- better for privacy
> The intention, as I understood it, of putting BIP157 directly into
bitcoind was to essentially force all `bitcoind` users to possibly service
BIP157 clients
Please. No-one is forcing anyone to do anything. To serve filters, a node
user needs to download the latest version, set `-blockfilterindex=basic` to
build the compact filters index, and set `-peercfilters` to serve them over
P2P. This is an optional, off-by-default feature.
Regards,
John
On Tue, May 5, 2020 at 9:50 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning ariard and luke-jr
>
>
> > > Trust-minimization of Bitcoin security model has always relied first
> and
> > > above on running a full-node. This current paradigm may be shifted by
> LN
> > > where fast, affordable, confidential, censorship-resistant payment
> services
> > > may attract a lot of adoption without users running a full-node.
> >
> > No, it cannot be shifted. This would compromise Bitcoin itself, which for
> > security depends on the assumption that a supermajority of the economy is
> > verifying their incoming transactions using their own full node.
> >
> > The past few years has seen severe regressions in this area, to the point
> > where Bitcoin's future seems quite bleak. Without serious improvements
> to the
> > full node ratio, Bitcoin is likely to fail.
> >
> > Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> > and should be actively avoided. BIP 157 improves privacy of fn-less
> usage,
> > while providing no real benefits to full node users (compared to more
> > efficient protocols like Stratum/Electrum).
> >
> > For this reason, myself and a few others oppose merging support for BIP
> 157 in
> > Core.
>
> BIP 157 can be implemented as a separate daemon that processes the blocks
> downloaded by an attached `bitcoind`, i.e. what Wasabi does.
>
> The intention, as I understood it, of putting BIP157 directly into
> bitcoind was to essentially force all `bitcoind` users to possibly service
> BIP157 clients, in the hope that a BIP157 client can contact any arbitrary
> fullnode to get BIP157 service.
> This is supposed to improve to the situation relative to e.g. Electrum,
> where there are far fewer Electrum servers than fullnodes.
>
> Of course, as ariard computes, deploying BIP157 could lead to an effective
> DDoS on the fullnode network if a large number of BIP157 clients arise.
> Though maybe this will not occur very fast? We hope?
>
> It seems to me that the thing that *could* be done would be to have
> watchtowers provide light-client services, since that seems to be the major
> business model of watchtowers, as suggested by ariard as well.
> This is still less than ideal, but maybe is better than nothing.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200505/be23bd38/attachment-0001.html>

2023-06-07 18:21:14

- reply

📅 Original date posted:2019-10-18
📝 Original message:> Is there a NODE_* bit we can use to pick peers that support this (useful!)
feature?
No. BIP 61 has no mechanism for advertising that a node will send REJECT
messages.
On Wed, Oct 16, 2019 at 12:43 PM John Newbery <john at johnnewbery.com> wrote:
> Following discussion on this mailing list, support for BIP 61 REJECT
> messages was not removed from Bitcoin Core in V0.19. The behaviour in that
> upcoming release is that REJECT messages are disabled by default and can be
> enabled using the `-enablebip61` command line option.
>
> Support for REJECT messages will be removed entirely in Bitcoin Core
> V0.20, expected for release in mid 2020. The PR to remove support was
> merged into Bitcoin Core's master branch this week.
>
> Adoption of new Bitcoin Core versions across reachable nodes generally
> takes several months. https://bitnodes.earn.com/dashboard/?days=365 shows
> that although v0.18 was released in May 2019, there are still several
> hundred reachable nodes on V0.17, V0.16, V0.15 and earlier software.
> Software that currently use REJECT messages from public nodes for
> troubleshooting issues therefore have plenty of time to transition to one
> of the methods listed by Marco in the email above.
>
> John
>
> On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Bitcoin Core may send "reject" messages as response to "tx", "block" or
>> "version" messages from a network peer when the message could not be
>> accepted.
>>
>> This feature is toggled by the `-enablebip61` command line option and has
>> been
>> disabled by default since Bitcoin Core version 0.18.0 (not yet released
>> as of
>> time of writing). Nodes on the network can not generally be trusted to
>> send
>> valid ("reject") messages, so this should only ever be used when
>> connected to a
>> trusted node. At this time, I am not aware of any software that requires
>> this
>> feature, and I would like to remove if from Bitcoin Core to make the
>> codebase
>> slimmer, easier to understand and maintain. Let us know if your
>> application
>> relies on this feature and you can not use any of the recommended
>> alternatives:
>>
>> * Testing or debugging of implementations of the Bitcoin P2P network
>> protocol
>> should be done by inspecting the log messages that are produced by a
>> recent
>> version of Bitcoin Core. Bitcoin Core logs debug messages
>> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
>> (`-debuglogfile=<debug.log>`).
>>
>> * Testing the validity of a block can be achieved by specific RPCs:
>> - `submitblock`
>> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
>> potentially invalid POW
>>
>> * Testing the validity of a transaction can be achieved by specific RPCs:
>> - `sendrawtransaction`
>> - `testmempoolaccept`
>>
>> * Wallets should not use the absence of "reject" messages to indicate a
>> transaction has propagated the network, nor should wallets use "reject"
>> messages to set transaction fees. Wallets should rather use fee
>> estimation
>> to determine transaction fees and set replace-by-fee if desired. Thus,
>> they
>> could wait until the transaction has confirmed (taking into account the
>> fee
>> target they set (compare the RPC `estimatesmartfee`)) or listen for the
>> transaction announcement by other network peers to check for
>> propagation.
>>
>> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless
>> there are
>> valid concerns about its removal.
>>
>> Marco
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191018/947d583d/attachment-0001.html>

2023-06-07 18:21:13

- reply

📅 Original date posted:2019-10-16
📝 Original message:Following discussion on this mailing list, support for BIP 61 REJECT
messages was not removed from Bitcoin Core in V0.19. The behaviour in that
upcoming release is that REJECT messages are disabled by default and can be
enabled using the `-enablebip61` command line option.
Support for REJECT messages will be removed entirely in Bitcoin Core V0.20,
expected for release in mid 2020. The PR to remove support was merged into
Bitcoin Core's master branch this week.
Adoption of new Bitcoin Core versions across reachable nodes generally
takes several months. https://bitnodes.earn.com/dashboard/?days=365 shows
that although v0.18 was released in May 2019, there are still several
hundred reachable nodes on V0.17, V0.16, V0.15 and earlier software.
Software that currently use REJECT messages from public nodes for
troubleshooting issues therefore have plenty of time to transition to one
of the methods listed by Marco in the email above.
John
On Tue, Mar 5, 2019 at 10:28 PM Marco Falke via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be
> accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has
> been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as
> of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected
> to a
> trusted node. At this time, I am not aware of any software that requires
> this
> feature, and I would like to remove if from Bitcoin Core to make the
> codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended
> alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network
> protocol
> should be done by inspecting the log messages that are produced by a
> recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee
> estimation
> to determine transaction fees and set replace-by-fee if desired. Thus,
> they
> could wait until the transaction has confirmed (taking into account the
> fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless
> there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191016/4664e5b3/attachment.html>