Bitcoin Forum
January 16, 2019, 07:34:59 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 ... 549 »
21  Bitcoin / Development & Technical Discussion / Re: Question about finding a block on: December 31, 2018, 05:35:35 AM
Not sure i understand this but would be grateful if someone could help.

This is what I understand.

1.Finding a block means guessing a number.
Kind of.

2.That number involves showing that the transaction involves the right keys and then ..putting it through some meth equation?  Is that right?
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).
22  Bitcoin / Armory / Re: segwit and mining pool on: December 28, 2018, 01:31:57 AM
I'll just not spend from that address until done mining.  Will there ever be a way to sign, other then switching back to legacy addresses?
There's ongoing work on a new standard for signed messages, although it isn't super well developed yet.
23  Bitcoin / Armory / Re: segwit and mining pool on: December 27, 2018, 10:29:56 PM
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.
24  Bitcoin / Development & Technical Discussion / Re: How to configure inbound/outbound connections of bitcoind ? on: December 26, 2018, 04:31:44 PM
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.
25  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.17.1 Released on: December 25, 2018, 07:22:05 PM
Apologize if I'm wrong. I was told that bitcoin is not controlled by anyone, but updates are coming out. As it turned out, he has no developers .  How do updates happen ?) Thanks for the reply.
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.
26  Bitcoin / Bitcoin Technical Support / Re: Core node is constantly re-indexing? on: December 25, 2018, 04:25:08 PM
debug.log file please.
27  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.17.0 Released on: December 25, 2018, 04:10:16 PM
BItcoin Core 0.17.1 has been released
28  Bitcoin / Bitcoin Discussion / Bitcoin Core 0.17.1 Released on: December 25, 2018, 04:09:05 PM
Bitcoin Core version 0.17.1 is now available from:


or through BitTorrent:


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:


To receive security and update notifications, please subscribe to:


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.


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

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 `` (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 (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 `` 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 `` (jnewbery)

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


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](

Hash: SHA256

5659c436ca92eed8ef42d5b2d162ff6283feba220748f9a373a5a53968975e34  bitcoin-0.17.1-aarch64-linux-gnu.tar.gz
aab3c1fb92e47734fadded1d3f9ccf0ac5a59e3cdc28c43a52fcab9f0cb395bc  bitcoin-0.17.1-arm-linux-gnueabihf.tar.gz
b1e1dcf8265521fef9021a9d49d8661833e3f844ca9a410a9dd12a617553dda1  bitcoin-0.17.1-i686-pc-linux-gnu.tar.gz
6aa567381b95a20ac96b0b949701b04729a0c5796c320481bfa1db22da25efdb  bitcoin-0.17.1-osx64.tar.gz
e3d785d800b71d277959d15b2c2b33d44dd72c1288e559928a40488dd935c949  bitcoin-0.17.1-osx.dmg
3e564fb5cf832f39e930e19c83ea53e09cfe6f93a663294ed83a32e194bda42a  bitcoin-0.17.1.tar.gz
e9245e682126ef9fa4998eabbbdd1c3959df811dc10df60be626a5e5ffba9b78  bitcoin-0.17.1-win32-setup.exe
fa1e80c5e4ecc705549a8061e5e7e0aa6b2d26967f99681b5989d9bd938d8467  bitcoin-0.17.1-win64-setup.exe
53ffca45809127c9ba33ce0080558634101ec49de5224b2998c489b6d0fc2b17  bitcoin-0.17.1-x86_64-linux-gnu.tar.gz
Version: GnuPG v1.4.11 (GNU/Linux)

29  Bitcoin / Development & Technical Discussion / Re: [SCALING] Minisketch on: December 21, 2018, 12:01:20 AM
Increased UTXO size means increased user base, doesn't it?
Not necessarily.

And you think it is infeasible to have a UTXO an order of magnitude bigger? Why?
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.
30  Bitcoin / Development & Technical Discussion / Re: [SCALING] Minisketch on: December 20, 2018, 08:20:36 PM
While some devs thought Minisketch could be used to connect to more nodes, IMO increase block size is more viable as current block size simply not enough if Bitcoin if mass adopted (and almost everyone use LN)
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).
31  Bitcoin / Development & Technical Discussion / Re: What is the first byte in message signature result? on: December 20, 2018, 08:14:16 PM
Method 2 (Finding recId during signing or from R which is the point, and s which is the integer):
I still don't understand what the mathematical logic behind this is yet.
During signing when R is produced (multiplication result of k * G), we use R.y and the value of s to get the recId. Here is the c# code:
int recid = ((R.X > curve.N) ? 2 : 0) | (R.Y.IsEven ? 0 : 1);
recid = (s > curve.N / 2) ? recid ^1 : recid;

* This is a more complete version of the link posted above by @darosior since it is considering the rare case of R.X being bigger than curve order.
* This seems to be working but I am not sure.
* I believe this is the function in bitcoin core that is responsible for signing messages (recoverable sigs) but I am not sure if I understood it correctly specially the overflow part!
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.

* Additionally there is this comment by Pieter Wuille which doesn't make any sense
27 = lower X even Y. 28 = lower X odd Y. 29 = higher X even Y. 30 = higher X odd Y.
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.
32  Bitcoin / Bitcoin Technical Support / Re: Bitcoin core v0.17.0 Masterkey on: December 20, 2018, 08:05:24 PM
in Bitcoin core v0.17.0 is the masterkey represents a sufficient backup? (taken with the dumpwallet command)
No, it is not. The master private key cannot be restored to a wallet at this time. Everything is derived from the hdseed instead (the seed is used to get the master private key, which is then used to derive all of the private keys used). You can get the hdseed from dumpwallet and use that. That is sufficient to get all of your private keys, but restoring just that to a wallet may not necessarily get you all of the transactions that you have received. The seed can be restored using the sethdseed command.
33  Bitcoin / Development & Technical Discussion / Re: What is the first byte in message signature result? on: December 19, 2018, 05:05:18 PM
That doesn't quite answer my question though. I understand that it is a "recovery ID" but I am trying to figure out how that number is obtained.
For example to sign "123" with the key to this address "muRAUfvSXQKXJm9sPsAbPsxDTMsMJoDQes"
I add 0 * n to r (first iteration of first loop)
Calculate Q with R, (first iteration of second loop) it is invalid
Calculate Q with -R, (second iteration of second loop) it is valid

The byte should be 32 meaning only 1 is added (27 + 4 + 1). Trying to figure out why 1 was chosen based on above operation?
You can think of the recovery id being a bit field of length two. Bit 0 indicates whether you should use R or -R. Bit 1 indicates whether R.x overflows n. So in this case, you have the bitfield be 01 = 1. Bit 1 is 0 because you do not overflow n (x=x, not x=x+n). Bit 0 is 1 because you are using -R.

Furthermore, this does in fact correspond to the loop. If instead of counting the number of operations that you do, count the number of Q's that you generate. If you put each Q into a list in the order that you generate them (including invalid ones), the recovery id is the index of the correct Q. In this case, Q[0] was invalid, Q[1] is the one you want. So the recovery id is 1.

Another way to look at this is to say the outer for loop is j from 0 to h (h=1 for secp256k1) and the inner loop is k from 0 to 1 (instead of 1 to 2 used in sec1). Then you add j and k together to get the recovery id. In this example, j = 0, and k = 1, so the recovery id is 1.
34  Bitcoin / Development & Technical Discussion / Re: What is the first byte in message signature result? on: December 19, 2018, 06:11:44 AM
Signed messages use a thing called public key recovery to get the public key and then get the address to compare that against the address provided. In this way, the public key does not need to be provided in the signature which makes it much shorter. However, public key recovery will result in multiple public keys, up to 4 of them. The first byte encodes a number 0 to 3 which is the recovery id. This number is used to determine which of those 4 public keys is the actual public key. There's some mathematical properties in the recovery id which can be used to calculate the actual public key without the use of a loop. And the recovery id can be calculated at signing time due to the same properties.

The first byte also encodes the compression.

I'm pretty sure that the 27 is just a random number that Pieter decided to use when implementing this.
35  Bitcoin / Development & Technical Discussion / Re: Is it possible to sign/create a transaction without specifying inputs? on: December 19, 2018, 01:55:07 AM
I'm not sure I understand what you want to do.

Are you trying to have a presigned transaction where the outputs are unknown. Then you can add outputs afterwards without having to sign again?

If so, that is not possible and is unsafe. If this were possible, anyone could just change the output to whatever they want, so anyone can change the outputs to give them money and not the person you wanted to pay. Furthermore, you cannot use opcodes to restrict the recipients because opcodes cannot inspect other inputs and outputs of the transaction they are in.
36  Bitcoin / Bitcoin Technical Support / Re: [initial connection] Some questions at the start of designing a bitcoin client on: December 17, 2018, 05:14:21 PM
Is version and block height the same?
No. There are protocol version numbers which indicate support for various features. Block height is completely unrelated as the p2p protocol is not related to consensus state. A list of protocol version numbers and their descriptions is available here:

Does the user_agent have an unlimited size or should I check the source code? Hypothetically as this will all be in one network packet, it can have an unlimited size I just wanted to check.
It's unlimited but there are size constraints on messages. Don't make it super long.

What's service number?
I assume you mean service bits. Service bits are used to indicate what services a node supports. These include things like NODE_NETWORK (bit 0) which indicates that you support sending the complete blockchain. A list of service bits and their descriptions is found in the code

Finally, as field size is bits and some of the fields are bigger than what is allowed for, do we just take the end of the values? I.E the nonce is 8 bits but the uint64 is obviously 64 (or are those values in bytes)?
The field size is in bytes. 8 bytes is 64 bits. No field has a type that is larger than it's field size or vice versa.
37  Bitcoin / Development & Technical Discussion / MOVED: Help to Windows compile for my crypto. on: December 17, 2018, 12:40:12 AM
This topic has been moved to Trashcan.

38  Bitcoin / Development & Technical Discussion / Re: Answer to a tx message on: December 16, 2018, 07:51:03 PM
A node may send a reject message if they reject the transaction. However, there is no required or guaranteed response to a tx message.
39  Bitcoin / Development & Technical Discussion / Re: Difference from Electrum HD wallet to Core HD wallet.dat file on: December 16, 2018, 04:22:56 AM
In terms of convenience, Electrum wins Core with no questions. Electrum allows the user to export the keys and to store a physical copy of the seeds thus giving them the reliability of physical backups. It's not possible with wallet.dat.
While it is inconvenient to do, it is possible to get the seed value (not a mnemonic, which many people, including you, confuse for being the seed) from Bitcoin Core and back that up. The seed value can be gotten using the dumpwallet command and the seed value will be there in WIF format. You can use that with sethdseed to restore the seed value to a new wallet.

In terms of security, Core would win. Core allows the user to encrypt their wallet and thus giving them a better security.
You can encrypt Electrum wallets too.

While Core allows the user to export its HD key, the wallet still has to be backed-up relatively frequently whenever the password is changed. It does seem more of a hassle to manage the wallet.dat.
That is untrue. The seed does not change when the password is changed. It is only changed when the wallet is first encrypted.

Which are the security differences comparing the Electrum HD wallet which has an exportable seed to the HD wallet.dat from Bitcoin Core software?
Besides the seed, there are other security concerns with the derivation of private keys themselves. Electrum uses a derivation path with non-hardened derivation nodes since it follows BIP 44. There is an inherent security risk to this because it is possible to retrieve the private key of the parent of a non-hardened node if you have the private key of that non-hardened node, and the extended public key (xpub) of the parent. With hardened derivation, this is not possible. Bitcoin Core uses exclusively hardened derivation paths. Unfortunately this makes public derivation impossible so it is more annoying to use as you have to import addresses to watch.

I would trust Bitcoin Core more in general.
40  Bitcoin / Development & Technical Discussion / Re: Question about Bitcoin Digital signatures on: December 15, 2018, 10:53:11 PM
Thank you for answering guys Smiley

So if I get it right,

- The transaction is signed with Bob's private key + ECDSA (if you know the process or have an article about it, I would be interested)
Close. The transaction is signed with Bob's private key using ECDSA. ECDSA is an algorithm. You can read about how it works on Wikipedia

- Alice can decode the signature with Bob's public key.
Alice verifies the signature with Bob's public key (provided in the transaction). She does not just decode it, but decoding (interpreting the values in a piece of data) is necessary to get the values inside of the signature.

- So,  if the transaction is not hashed, how can Alice know if the transaction has been modified ?
Part of ECDSA is hashing the message to be signed. In this case, that is the transaction. The message hash itself is not included anywhere. However, because the message is provided (it's the transaction), we can easily compute the hash of it in order to verify the signature. if the transaction were modified, the hash would not match the hash that was used to create the signature, so the signature would not validate to true. Thus the transaction would be invalid.
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 ... 549 » is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!