What LN software were you trying to use?

How can LN be made inherently DDoS resistant? I don't think that's something that can be done on a protocol level. It has to be implemented by the implementors of any network protocol, and that pertains to any software that provides a network service.

With routing, the protocol does allow you to not route payments. AFAIK, the option to not route payments is not exposed on existing software.

Even though it isn't strictly address reuse, you have basically the same problem as address reuse. Once you spend an output, people will see the public key and can link your transactions together. Furthermore, once people know how you are constructing your addresses, it is trivial to pregenerate all of your addresses to see how much money you are receiving.

Also, you will be paying more and more in transaction fees each time you spend as the redeemScript grows larger. You will also be limited to 20 addresses using one key as OP_CHECKMULTISIG only allows up to 20 keys. If you use the Large multisig construction, you could go up to 67 addresses.

This construction is still secure cryptographically. It's the same as reusing addresses.

A point release is for bug fixes or soft fork deployment parameter, not major feature changes. Changing the minimum relay fee rate (and everything else that goes with it) would be a major feature release. It definitely would not be first released as a point release. Just because your favorite change isn't in a point release does not mean it is not going to be in the next release.

And just because you think "it can't be that much to change" does not mean it is not. There are a lot more fee rates than just the minimum relay fee and changing fee rates affects a lot of components.

If you can send $4 without a fee, then I can send 100 million 1 satoshi transactions back to myself without a fee. And I can do this constantly and indefinitely forever flooding the blockchain and the mempool. This kind of spam is detrimental the network and has potential to cause major problems. That's the whole reason there's a transaction fee and a minimum relay fee: to prevent this sort of spam.

---

When changing anything in any of Bitcoin's consensus or transaction relay policies and protocols, you can't just think about the short term and how a change affects just you as a user. This is a distributed and decentralized system where major changes to the protocols affect the whole ecosystem. You have to look at the big picture and see how a change affects the entire ecosystem as a whole, not just the individual.

First of all, BIPs are not roadmaps or plans for things to include in Bitcoin Core. They do not describe how Bitcoin Core works nor does having a BIP mean that it will go into Bitcoin Core. BIPs are just documents that document ideas and technical proposals to be used generally in Bitcoin.

Bitcoin Core does already support HD wallets. All newly created Bitcoin Core wallets are HD wallets. However, currently Bitcoin Core does not allow you to import HD seeds, BIP 39 mnemonics (note that seed and mnemonics are different things), or BIP 32 master private keys. This will be coming in the future but requires a significant wallet rework and overhaul that is currently ongoing.

Right, you need to push the redeemScript.

How P2SH works is that the redeemScript is pushed to the stack. This stack is then duplicated. On one stack, the top stack element (the redeemScript) is popped and its hash160 is pushed to the stack. That is then compared to the hash in the scriptPubKey. If that succeeds, the second stack is used which has the top stack element as the redeemScript. On this stack, the redeemScript is popped off and executed as a script. So for all of this to work, the redeemScript needs to be pushed as a singular stack element in the scriptSig.

You will be able to use all RPCs. However, those that require pulling information from stored block data will not be able to give you data from blocks that have been pruned. For example, getblock will read a block off disk and give it to you decoded. If you use getblock on a block that has been pruned, it will give you an error. For blocks that were not pruned, it will work as expected.

Although pruning deletes old blocks from disk, there is still data kept about them in the chainstate database. This includes the block header so getblockheader will still work.

Indeed. This reduces the number of possibilities to 74382. This is definitely brute forceable in probably a few minutes at most.

What do you mean by "inverted the position of two of those words, two times"? How exactly you did that will affect the number of possibilities (as some orderings could be ruled out).

The upper bound to this is (24 choose 4) * 4! = 255024. (24 choose 4) is the number of ways you can choose 4 items from a set of 24 elements. 4! is the number of ways you can order those 4 elements. This is a multiplication since for each way you can choose 4 items, there are 4! ways you can rearrange them.

The Lightning Network works on any cryptocurrency that has some specific properties. For example, it can be used on both Bitcoin and Litecoin. The chainhash is the hash of the genesis block and is used to indicate which blockchain a particular lightning node is operating on. In a way, the Lightning Network on Bitcoin and Lightning Network on Litecoin are two different networks. However, they are also the same network too.

They are different networks in the sense that there cannot be channels which are shared across both blockchains. All channels are based on one blockchain as channels require modification of a transaction for that blockchain. Since Bitcoin and Litecoin use different blockchains, there can only be Bitcoin channels and Litecoin channels.

However, they can also be viewed as the same network because of cross chain atomic swaps. HTLCs allow people to create a channel on Bitcoin and a similar channel on Litecoin which uses HTLCs with the same hashed secrets. This let people atomically swap Bitcoin for Litecoin. So payments can still be routed over this joint network. If someone wanted to be paid in Litecoin over the Lightning Network but you only have Bitcoin channels, you can (in theory, I don't know if this is implemented) route your payment through a node that has both Bitcoin and Litecoin channels using the same HTLC secrets and it would be totally fine. The only caveat is the exchange rate between Bitcoin and Litecoin which would have to be negotiated with that node doing the bridging between Bitcoin and Litecoin.

Kind of.

No. Miners do not prove that transactions are correct, that's not their job. The process of mining has nothing to do with showing transactions are correct or have correct keys. However a miner will want to still verify transactions are valid (their proof of correctness is contained within the transaction and is produced by their creators, not the miner) so that the block they produce is also valid. A valid block has more than just a valid proof of work, it's contents must also be valid.

What miners do is try to find a block which hashes to less than a target value (you can view this as the hash beginning with some number of 0's). The way that they do this is to increment a value called a nonce. It is just a number which is part of the data that is hashed. So miners are trying to guess a nonce which results in a block hash that has some number of zeroes in front of it. It's a bit more complicated than that, but that's a basic understanding of what miners do to "solve a math problem" (it's not really a math problem).

There's ongoing work on a new standard for signed messages, although it isn't super well developed yet.

Signing messages with any non-legacy address type is not supported. The existing signed message standard in Bitcoin is really only for the legacy P2PKH address type and does not work for Segwit addresses or P2SH addresses.

There are no configuration options for dictating what you accept from other nodes or what you send to other nodes. There is not and never has been such options. You will either need to modify the source code of Bitcoin Core to do this yourself, or you will need some other software which acts as a filter between your node and the rest of the Bitcoin network.

These are updates for a particular software called Bitcoin Core. Bitcoin Core is descended from the original Bitcoin software that Satoshi published. It is just the most popular of the many node software that people can run. The Bitcoin Core software is constantly being updated and changed, but that does not mean that Bitcoin itself changes. While the software may change, the same consensus rules are still being enforced and those do not change.

debug.log file please.

Bitcoin Core version 0.17.1 is now available from:

  <https://bitcoincore.org/bin/bitcoin-core-0.17.1/>

or through BitTorrent:

    magnet:?xt=urn:btih:c56c87ccfaa8e6fbccc90d549121e61efd97cb6f&dn=bitcoin-core-0.17.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969    

This is a new minor version release, with various bugfixes
and performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  <https://github.com/bitcoin/bitcoin/issues>

To receive security and update notifications, please subscribe to:

  <https://bitcoincore.org/en/list/announcements/join/>

How to Upgrade
==============

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

If your node has a txindex, the txindex db will be migrated the first time you run 0.17.0 or newer, which may take up to a few hours. Your node will not be functional until this migration completes.

The first time you run version 0.15.0 or newer, your chainstate database will be converted to a
new format, which will take anywhere from a few minutes to half an hour,
depending on the speed of your machine.

Note that the block database format also changed in version 0.8.0 and there is no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
-------------------

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the `-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==============

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.10+, and Windows 7 and newer (Windows XP is not supported).

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.

From 0.17.0 onwards macOS <10.10 is no longer supported. 0.17.0 is built using Qt 5.9.x, which doesn't
support versions of macOS older than 10.10.

Notable changes
===============

`listtransactions` label support
--------------------------------

The `listtransactions` RPC `account` parameter which was deprecated in 0.17.0
and renamed to `dummy` has been un-deprecated and renamed again to `label`.

When bitcoin is configured with the `-deprecatedrpc=accounts` setting, specifying
a label/account/dummy argument will return both outgoing and incoming
transactions. Without the `-deprecatedrpc=accounts` setting, it will only return
incoming transactions (because it used to be possible to create transactions
spending from specific accounts, but this is no longer possible with labels).

When `-deprecatedrpc=accounts` is set, it's possible to pass the empty string ""
to list transactions that don't have any label. Without
`-deprecatedrpc=accounts`, passing the empty string is an error because returning
only non-labeled transactions is not generally useful behavior and can cause
confusion.

0.17.1 change log
=================

### P2P protocol and network code
- #14685 `9406502` Fix a deserialization overflow edge case (kazcw)
- #14728 `b901578` Fix uninitialized read when stringifying an addrLocal (kazcw)

### Wallet
- #14441 `5150acc` Restore ability to list incoming transactions by label (jnewbery)
- #13546 `91fa15a` Fix use of uninitialized value `bnb_used` in CWallet::CreateTransaction(…) (practicalswift)
- #14310 `bb90695` Ensure wallet is unlocked before signing (gustavonalle)
- #14690 `5782fdc` Throw error if CPubKey is invalid during PSBT keypath serialization (instagibbs)
- #14852 `2528443` backport: [tests] Add `wallet_balance.py` (MarcoFalke)
- #14196 `3362a95` psbt: always drop the unnecessary utxo and convert non-witness utxo to witness when necessary (achow101)
- #14588 `70ee1f8` Refactor PSBT signing logic to enforce invariant and fix signing bug (gwillen)
- #14424 `89a9a9d` Stop requiring imported pubkey to sign non-PKH schemes (sipa, MeshCollider)

### RPC and other APIs
- #14417 `fb9ad04` Fix listreceivedbyaddress not taking address as a string (etscrivner)
- #14596 `de5e48a` Bugfix: RPC: Add `address_type` named param for createmultisig (luke-jr)
- #14618 `9666dba` Make HTTP RPC debug logging more informative (practicalswift)
- #14197 `7bee414` [psbt] Convert non-witness UTXOs to witness if witness sig created (achow101)
- #14377 `a3fe125` Check that a separator is found for psbt inputs, outputs, and global map (achow101)
- #14356 `7a590d8` Fix converttopsbt permitsigdata arg, add basic test (instagibbs)
- #14453 `75b5d8c` Fix wallet unload during walletpassphrase timeout (promag)

### GUI
- #14403 `0242b5a` Revert "Force TLS1.0+ for SSL connections" (real-or-random)
- #14593 `df5131b` Explicitly disable "Dark Mode" appearance on macOS (fanquake)

### Build system
- #14647 `7edebed` Remove illegal spacing in darwin.mk (ch4ot1c)
- #14698 `ec71f06` Add bitcoin-tx.exe into Windows installer (ken2812221)

### Tests and QA
- #13965 `29899ec` Fix extended functional tests fail (ken2812221)
- #14011 `9461f98` Disable wallet and address book Qt tests on macOS minimal platform (ryanofsky)
- #14180 `86fadee` Run all tests even if wallet is not compiled (MarcoFalke)
- #14122 `8bc1bad` Test `rpc_help.py` failed: Check whether ZMQ is enabled or not (Kvaciral)
- #14101 `96dc936` Use named args in validation acceptance tests (MarcoFalke)
- #14020 `24d796a` Add tests for RPC help (promag)
- #14052 `7ff32a6` Add some actual witness in `rpc_rawtransaction` (MarcoFalke)
- #14215 `b72fbab` Use correct python index slices in example test (sdaftuar)
- #14024 `06544fa` Add `TestNode::assert_debug_log` (MarcoFalke)
- #14658 `60f7a97` Add test to ensure node can generate all rpc help texts at runtime (MarcoFalke)
- #14632 `96f15e8` Fix a comment (fridokus)
- #14700 `f9db08e` Avoid race in `p2p_invalid_block` by waiting for the block request (MarcoFalke)
- #14845 `67225e2` Add `wallet_balance.py` (jnewbery)

### Documentation
- #14161 `5f51fd6` doc/descriptors.md tweaks (ryanofsky)
- #14276 `85aacc4` Add autogen.sh in ARM Cross-compilation (walterwhite81)

Credits
=======

Thanks to everyone who directly contributed to this release:

- Andrew Chow
- Chun Kuan Lee
- David A. Harding
- Eric Scrivner
- fanquake
- fridokus
- Glenn Willen
- Gregory Sanders
- gustavonalle
- John Newbery
- Jon Layton
- Jonas Schnelli
- João Barbosa
- Kaz Wesley
- Kvaciral
- Luke Dashjr
- MarcoFalke
- MeshCollider
- Pieter Wuille
- practicalswift
- Russell Yanofsky
- Sjors Provoost
- Suhas Daftuar
- Tim Ruffing
- Walter
- Wladimir J. van der Laan

As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).

---

Not necessarily.

The same reason that it has been for the past several years: a larger UTXO set makes verifying blocks slower and increases node requirements thus making it more expensive for people to run nodes. More transactions in general (which correlates to a larger UTXO set) makes it harder to run a node which means that there will be less nodes and thus less decentralization.

I am not against Bitcoin adoption in general. I am for more people using Bitcoin. However I do not believe that we can support having more people at this time with current technology. Minisketch does not change this fact because it is used for network relay, which is completely unrelated to blocks, consensus, and the UTXO set. Not every new technology in Bitcoin is for making more transaction throughput. In this case, this new technology is to reduce the total bandwidth cost for a node, which is good, but unrelated to transaction throughput.

Let's not turn this thread into another block size argument. That's completely off topic.

Increasing the block size still increases the UTXO set size and the time to sync and validate all blocks. Minisketch does not help with initial sync or with validation, it only reduces the amount of bandwidth you consume for normal transaction relay (i.e. relaying unconfirmed transactions after you have already synced).

This is correct, and that is the function that is used.

Overflow just means that R.x > curve.N. Again, viewing the recid as a bitfield, what this code does is set bit 1 to 1 if it overflows, i.e. R.x > curve.N. It sets the entire recid to the number 2 because 2 is 10 in binary. This sets bit 1. The 0th bit is set by the | (R.Y.IsEven ? 0 : 1). This is because we choose a 0 or 1 for the 0th bit, and Bitwise OR it with the number 2. This will make sure that bit 0 is set, and if bit 1 was set, that will also be included in the final recid.

Sure it does. The first byte is just 27 + recid + compression. Ignoring compression for now (so it's 0), you have 27 + recid. If the recid is 0, then 27 + 0 = 27. A recid of 0 means that there is no overflow (lower X) and y is even (even Y). So 28 = 27 + 1. Recid 1 means low X, odd Y. 29 = 27 + 2. Recid 2 means high X (R.X > curve.N) and even y. Lastly 30 = 27 + 3. Recid 3 means high X and odd y.