Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Newsletters: add #24 (2018-12-04) #92

Merged
merged 1 commit into from Dec 4, 2018

Conversation

@harding
Copy link
Contributor

harding commented Dec 2, 2018

A slow news week, so I didn't feel bad about some of the topics needing (IMO) a bit of an extended description. Some notes:

  • @jnewbery I think some of the backports going into 0.17.1 are related to your accounts removal work. I haven't followed the details---just reading about the gebalance "*" stuff made me cringe---and so I don't describe anything here, but feel free to add some text to that paragraph about 0.17.1 if you want.

  • I don't really get LND#2081, specifically why you'd want one RPC server to proxy RPCs from an outside server. I think my description of the change is accurate (if dry), but I'm afraid I'm missing something about why this is useful or important (as LND devs seem to think it is), so anyone who wants to take a look at it and see if you can extended the description is quite welcome to try.

Copy link
Contributor

jnewbery left a comment

utACK b2af139. A few nits inline.

I think some of the backports going into 0.17.1 are related to your accounts removal work. I haven't followed the details---just reading about the gebalance "*" stuff made me cringe---and so I don't describe anything here, but feel free to add some text to that paragraph about 0.17.1 if you want.

The gebalance "*" won't make it into 0.17.1. I don't think we need to add details of the backported PRs, but I've added an action item for people to review the list if they intend to take the upcoming maintenance release.

don't really get LND#2081

Me neither. I haven't spent enough time to understand what the motivation is. Your short description seems sufficient.


## News

- **CPFP carve-out:** in order to spend some bitcoins, the transaction

This comment has been minimized.

Copy link
@jnewbery

jnewbery Dec 3, 2018

Contributor

nit: remove 'some'

(CPFP).

CPFP even works for multiple descendant transactions, but the more
relationships that need to be considered, the more work the node

This comment has been minimized.

Copy link
@jnewbery

jnewbery Dec 3, 2018

Contributor

nit: don't describe this as work (readers may confuse the concept with the work in proof-of-work that miners are also doing). Suggest:

" CPFP even works for packages of transactions containing multiple descendant transactions. To make block construction fast for miners, Bitcoin Core limits[^fn-cpfp-limits] the maximum number and size of related transactions in a package."

as being too cheap and so not see the subsequent fee bumps. Whereas
the carve-out policy is probably easy to implement, package relay is
something that's been discussed for a long time without yet being
formally considered or implemented.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Dec 3, 2018

Contributor

nit: s/formally considered or implemented/formally specified or implemented/


The new `desc` fields are not expected to be particularly useful at
the moment as they can currently only be used with the
`scantxoutset` RPC, but they will provide a compact way of providing

This comment has been minimized.

Copy link
@jnewbery

jnewbery Dec 3, 2018

Contributor

I'd soften this from 'they will provide...'. Sipa's been very explicit that he doesn't consider descriptors and interop standard yet, and that they shouldn't be seen as a way to exchange signing information between different wallets.

At some point in future, that may happen, but we shouldn't encourage people to think that descriptors are a standard or that there are any firm plans to make them a standard.

This comment has been minimized.

Copy link
@harding

harding Dec 4, 2018

Author Contributor

I think you misinterpreted this. I'm adding some words to hopefully make that less likely for other readers, but I don't think I suggested that they were meant to be used for interop except between Bitcoin Core's own RPCs (which I do believe is one of Sipa's initial target cases, the other being the wallet's internal data store). From the text (emphasis added):

they will provide a compact way of providing all the information necessary for making addresses solvable to future and upgraded RPCs such as those used for interactions between offline/online (cold/hot) wallets, multisig wallets, coinjoin implementations, and other cases.

To help make it clearer, I'm changing s/RPCs/RPCs for Bitcoin Core/. Feel free to edit more if you still think it's easily misunderstood.

@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented Dec 4, 2018

Pushed a commit; hopefully all nits should be addressed. Thanks @moneyball and @jnewbery!

@jnewbery jnewbery force-pushed the harding:2018-12-04-newsletter branch from 8c12e08 to a29fb34 Dec 4, 2018
@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Dec 4, 2018

Removed one word in the action item I wrote ("Bitcoin Core is preparing for an upcoming maintenance release 0.17.1") and squashed all commits.

ACK a29fb34. Thanks all!

@jnewbery jnewbery merged commit 6c64bb5 into bitcoinops:master Dec 4, 2018
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.