Bitcoin Forum
February 16, 2019, 10:36:40 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 53 54 55 56 57 58 59 60 61 62 63 ... 551 »
241  Bitcoin / Development & Technical Discussion / Re: Satoshi's sendalert.cpp on: July 03, 2018, 07:43:17 AM
Wladimir has actually had a version of this code on his github gists for several years now:
242  Bitcoin / Development & Technical Discussion / Re: How is the target value (PoW) determined? on: July 03, 2018, 07:37:56 AM
The process of mining uses hashing. It really isn't solving a problem or answering a question. It is just doing work. The data that is hashed is the block header. The block header is 80 bytes and contains multiple fields: a version number, the previous block hash, the merkle root (hash of all of the transactions in the block), a timestamp, a nonce, and a compact representation of the target value. A miner's goal is to modify this block header until they are able to find a hash that, when interpreted as a 256 bit integer, is less than some target value.

In order to do this, miners will modify as much data in the block header as possible. You can really imagine this process as simply constructing a block (complete with block header), computing the hash of the block header, and comparing it with the target. Then doing this over and over with different blocks (done by tweaking some values within the block itself) until one is found that has a block header hash that is less than the target.

Miners can change a lot of things in the block header in order to get different hashes. First and foremost is the nonce. The nonce is specifically designed to be changed in order to get different block headers. However the nonce is fairly small, only 4 billion possible values. Thus something else needs to be changed. Miners can then change the timestamp and the merkle root. Miners change the merkle root by including different transactions in their trial blocks. They can also permute the order of transactions. Miners can also change the data within the coinbase transaction such as adding extra data as a extraNonce.

The target value that miners compare their block hashes to is calculated from the original target value from the genesis block. The target value changes every 2016 blocks. So the target value can be known and calculated simply by looking at the blockchain and computing the targets for every 2016 blocks. Since the target uses the timestamp, all data necessary to compute the target is available to anyone who has the complete blockchain. It is important to note that the difficulty adjustment is actually the target adjustment. The difficulty is simply the inverse of the target and is not actually part of the blockchain or consensus rules. Only the target is.
243  Bitcoin / Development & Technical Discussion / Alert Keys and Alert System Vulnerabilities Disclosure on: July 02, 2018, 11:15:02 PM
The bitcoin alert keys are disclosed in this post, followed by a description of the purpose of this information and its history. The bitcoin alert system has been completely retired. The network is not at risk and this warning may be safely ignored if you do not have an ancient node (running v0.12.x or older) using the deprecated bitcoin alert system or its public keys.

mainnet public key: 04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db2 2209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284

mainnet private key: 30820113020101042053cdc1e0cfac07f7e1c312768886f4635f6bceebec0887f63a9d37a26a92e 6b6a081a53081a2020101302c06072a8648ce3d0101022100ffffffffffffffffffffffffffffff fffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a0629 5ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b4 48a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03 bbfd25e8cd0364141020101a14403420004fc9702847840aaf195de8442ebecedf5b095cdbb9bc7 16bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd 68284

testnet public key: 04302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf81 7d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a

testnet private key: 308201130201010420474d447aa6f46b4f45f67f21180a5de2722fc807401c4c4d95fdae64b3d6c 294a081a53081a2020101302c06072a8648ce3d0101022100ffffffffffffffffffffffffffffff fffffffffffffffffffffffffefffffc2f300604010004010704410479be667ef9dcbbac55a0629 5ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b4 48a68554199c47d08ffb10d4b8022100fffffffffffffffffffffffffffffffebaaedce6af48a03 bbfd25e8cd0364141020101a14403420004302390343f91cc401d56d68b123028bf52e5fca1939d f127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200c a2b0a

These are openssl-serialized private keys.

In 2016, a plan was proposed for the completion of the retirement of the bitcoin alert system which included the idea of revealing the alert system private keys. The proposal still contains good information regarding the purpose and intention of alert system retirement and motivation for the disclosure of the private keys. Additionally, an overview of the alert system retirement and its timeline is available on the web. This disclosure was recently discussed in an IRC meeting. A media site also recently discussed this topic.

One of the reasons for disclosure of the keys is to mitigate the effects of unknown dissemination and proliferation of the keys. By broadcasting the values to make them available to everyone, the value
of the keys is intended to be to be eliminated, since now everyone could feasibly sign messages, the value of the signed messages becomes zero.

Vulnerabilities in the Bitcoin Alert system


The Alert System previously utilized by Bitcoin has several issues (some of which may be classified as vulnerabilities). These issues no longer exist in Bitcoin as of network protocol version 700013 which was released with Bitcoin Core 0.13.0. Many altcoins and Bitcoin client implementations were notified of the Alert System's removal and have since removed the alert system themselves or transitioned to using an Alert system that does not share an Alert Key with Bitcoin.

All of the issues described below allow an attacker in possession of the Alert Key to perform a Denial of Service attack on nodes that still support the Alert system. These issues involve the exhaustion of memory which causes node software to crash or be killed due to excessive memory usage.

Many of these issues were not known until the Alert System was removed as developers inspected the code for vulnerabilities prior to releasing the Alert Key. Due to these issues, the publication of the Alert Key was delayed and affected altcoins and software were notified.

As of this writing, less than 4% of Bitcoin nodes are vulnerable. Furthermore, the Bitcoin Core developers have created a "final alert" which is a maximum ID number alert which overrides all previous alerts and displays a fixed "URGENT: Alert key compromised, upgrade required" message on all vulnerable software. The Bitcoin Core developers believe that so few vulnerable nodes are present on the network, and risks to those nodes so minor, that it is safe to publish the Alert Key.

An Alert contains these fields:

int32_t nVersion;
int64_t nRelayUntil;      // when newer nodes stop relaying to newer nodes
int64_t nExpiration;
int32_t nID;
int32_t nCancel;
std::set<int32_t> setCancel;
int32_t nMinVer;            // lowest version inclusive
int32_t nMaxVer;            // highest version inclusive
std::set<std::string> setSubVer;  // empty matches all
int32_t nPriority;

Alerts are also identified by their SHA256 hash. The above fields can be freely modified to generate alerts with differing hashes.

Infinitely Sized Map (CVE-2016-10724)

The Alert System was designed to support multiple Alerts simultaneously. As such, Alerts were stored in memory in a map. However, there is no limit on how large this map can be, thus an attacker with the Alert Key can send a large number of Alerts to a node. Eventually, the map containing all of the Alerts will be so large that the node runs out of memory and crashes, thus causing a Denial of Service attack.

The infinitely sized map is the basis for which the Alert system can be used to cause Denial of Service attacks.

Infinitely Sized Alerts

Although the infinitely sized map is what causes the crash itself, an attacker can also send very large Alerts. Alerts themselves are not limited in size explicitly, they are only limited by the maximum network message size. This maximum network message size has varied between versions. At times in the past, it has been 32 MB. For Bitcoin Core 0.12.0 (the most recent version of Bitcoin Core with the alert system enabled by default), the maximum message size is 2 MB.

Although large Alerts do not directly cause a Denial of Service by themselves, combined with the infinitely sized map, large Alerts can more quickly cause a node to run out of memory.

* The `setCancel` field has no length limit (besides the maximum message size) and is a std::set of 32-bit integers. Given that it has no size constraints, an attacker can use this field to create a very large Alert by filling the set with many integers.
* The `setSubVer` field, like `setCancel`, has no length limit and is a std::set. However instead of integers it has std::strings. These strings do not have a length limit themselves and can thus be arbitrarily long to produce an Alert that is arbitrarily large.
* Bitcoin Core versions prior to 0.10.0 did not have a limit on the length of the `strComment`, `strStatusBar`, and `strReserved` fields. These strings can have an arbitrary length.

The Final Alert

To protect against attackers abusing the Alert key following its publication, the Bitcoin Core developers constructed a "final alert". This final alert is a maximum ID alert which overrides all previous alerts. All Bitcoin Core versions since and including Bitcoin Core 0.14.0 contain the final alert and will send it to any node which is vulnerable. However this protection is not enough to protect those nodes as a few issues were found with the final alert itself.

Final alerts are those which meet the following conditions:

nExpiration == maxInt &&
nCancel == (maxInt-1) &&
nMinVer == 0 &&
nMaxVer == maxInt &&
setSubVer.empty() &&
nPriority == maxInt &&
strStatusBar == "URGENT: Alert key compromised, upgrade required"

`maxInt` is the maximum signed integer as defined by `std::numeric_limits<int>::max()`.

Multiple Final Alerts

The definition for a final alert does not include a few fields. Because alerts are identified by their hashes, changing the ommitted fields allows an Alert to be classified as a final alert but still be an alert that is added to the infinitely sized map.

- Since `setCancel` is not required to be empty for an alert to be a final alert, the `setCancel` field can contain different integers to produce alerts that have different hashes and are thus different alerts. Combined with the infinitely sized map and the infinitely sized `setCancel` issues, many final alerts can be created which are large, fill the map, and cause a node to run out of memory.
- The `strComment` field, while having a maximum length of 65536 bytes, is not required to be a particular string in order for an alert to be a final alert. Thus multiple final alerts can be crafted which have different hashes by using different values for `strComment`
- The`strReserved` field, while having a maximum length of 256 bytes, is not required to be a particular string in order for an alert to be a final alert. Thus multiple final alerts can be crafted which have different hashes by using different values for `strReserved`.
- The `nVersion` field is also not required to be a particular value. Thus this can be used to construct final alerts with different hashes by having different values for `nVersion`.
- `nRelayUntil` field is also not required to be a particular value. Thus this can be used to construct final alerts with different hashes by having different values for `nRelayUntil`.

Final Alert Cancellation (CVE-2016-10725)
Although the final alert is supposed to be uncancellable, it unfortunately is cancellable due to the order of actions when processing an alert. Alerts are first processed by checking whether they cancel any existing alert. Then they are checked whether any of the remaining alerts cancels it. Because of this order, it is possible to create an alert which cancels a final alert before the node checks whether that alert is canceled by the final alert. Thus an attacker can cancel a final alert with another alert allowing a node to be vulnerable to all of the aforementioned attacks.

Protecting Against DoS Attacks from the Alert System

Fixing these issues is relatively easy. The first and most obvious solution is to simply remove the Alert system entirely. As nodes upgrade to versions without the Alert system, fewer nodes will be vulnerable to attack should the Alert keys become public. This is the option that Bitcoin has taken. However, because Bitcoin has retired the Alert system entirely, the Alert key will also be published to reduce the risk that the Alert Key is mistakenly depended upon in the future.

Should altcoins wish to continue using the Alert system but with a different Alert Key, a few very simple fixes will safeguard nodes from the aforementioned issues. Limiting the number of alerts, the size of `setCancel` and `setSubVer`, and only allowing one final alert altogether fix the above issues. This patch, on top of Bitcoin Core 0.11 (a vulnerable version), fixes the aforementioned issues. Altcoins that still use the Alert system are recommended to port this patch to their software. Outdated node software is still vulnerable.

This disclosure was authored primarily by Bryan Bishop (kanzure) and Andrew Chow (achow101). Special thanks to reviewers. Also, a interesting proposal was floated to not disclose the private keys in WIF format-- one is that this is not how the original values were received, and second (more importantly) to prevent users from importing the key into their wallet and reusing it in their wallet key circulation.

244  Other / Meta / Re: Mod, please check new plagiarism: Reporting copy/pasting, please permban on: July 02, 2018, 12:50:52 AM
They're all clearly spam bots who plagiarized the same post.
This isn't just plagiarism, it's spamming and phishing. The link in the post is a phishing link.
245  Bitcoin / Bitcoin Technical Support / Re: Can't connect to my node on: July 01, 2018, 06:55:41 PM
The RPC port is different from the network port. Make sure that you are forwarding the RPC port which is 8332 by default.

Additionally, you need to make sure that the correct IP address(es) are set for rpcallowip.

Lastly, run bitcoind with -debug=rpc and your debug.log file may contain some additional information about why you are unable to connect.
246  Bitcoin / Development & Technical Discussion / Re: Is gossip protocol in Bitcoin perfect? on: July 01, 2018, 06:41:06 PM
There is no such guarantee that your transaction will reach all nodes, nor is it possible to really measure the time it takes nor is it possible to really check whether a transaction has reached all nodes.

Nodes come online and offline continuously, so some nodes that just came online probably do not have your transaction. Other nodes may be configured in such a way that your transaction is not relayed by them, so they don't have your transaction (not relaying directly implies not accepting it into their mempool).
247  Bitcoin / Development & Technical Discussion / Re: cpuminer requires at least two bitcoin nodes to run on: June 25, 2018, 07:38:03 AM
No, that is unrelated to the consensus algorithm. It is simply part of how the getblocktemplate RPC command works. It must be connected to the network before you can use the RPC call (and thus mine). So you must have at least one connection to another node.
248  Bitcoin / Development & Technical Discussion / Re: How to achieve fastest node -- 2 minutes delay on block reception on: June 24, 2018, 05:09:33 PM
The timestamp on the block is not guaranteed to to be the correct time that the block was actually found. Miners can manipulate the block time quite a bit, so it doesn't reliably tell you when a block was found.

Propagation can also take a long time depending on how far away from the miners you are.

Note: I've already heard about FIBRE, but I'd like to achieve this without it. Also afaik FIBRE is about compact blocks and I'd also like to receive txns as fast as possible.
FIBRE is not really what you are looking for. You already are using compact blocks as that is in Bitcoin Core. Compact blocks is unrelated to transaction relay times.
249  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.1 Released on: June 23, 2018, 07:56:48 AM
Thank you for the explanation.  Would it be of any help if I load it on my GPU mining machine?  I have an off-line machine I use to generate wallets, so I wouldn't be using it for that.
Help in what way? By running Bitcoin Core on any machine, you are helping the Bitcoin network.
250  Bitcoin / Bitcoin Technical Support / Re: dump public key from bitcoin-cli on: June 22, 2018, 08:00:21 AM
For each address, you can get the public key by using the validateaddress command. Note that this functionality has been moved to a new getaddressinfo command for Bitcoin Core 0.17.0 and beyond.
251  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.1 Released on: June 20, 2018, 06:15:08 AM
Pardon my ubernoobiness, but what is this for?

I have plenty of room on my mining rig's D drive, should I install it there?  If it's adventitious to the community, I'm happy to help.
Bitcoin Core is a full node software that powers the Bitcoin network. It receives, verifies, and relays all blocks and transactions broadcast to the Bitcoin network. It is also a wallet software.
252  Bitcoin / Development & Technical Discussion / Re: Different sites report different blockchain sizes? on: June 18, 2018, 11:24:02 PM
I run the same version of Bitcoin Core on both of my nodes and one has a significantly bigger blocks directory (~20 GB more).
Do you maybe know where these transaction index data is being stored, since this node with a bigger blocks folder is also the one with transaction index enabled?
The block and transaction indexes are stored in the blocks folder.
253  Bitcoin / Bitcoin Technical Support / Re: Where is the code that convert public key to address? on: June 18, 2018, 02:45:27 AM
The addresses are encoded here: The specific functions that do the encoding are and
254  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.1 Released on: June 18, 2018, 02:41:15 AM
Too bad #11658 didn't make it into this version.
That isn't a bug fix or a critical change, so it isn't eligible for a minor release anyways.
255  Bitcoin / Development & Technical Discussion / Re: Looking for an linux (or windows) offline SHA-256 binary calculator on: June 17, 2018, 06:33:01 PM
You can use OpenSSL's hashing command. Or you can write your bytes to a file (with a hex editor or something) and hash the file using sha256sum which comes standard in most linux distributions.
256  Bitcoin / Development & Technical Discussion / Re: Daemon encryption not work? on: June 17, 2018, 04:41:57 AM
This is supposed to happen. The daemon is supposed to stop when encrypting the wallet to ensure that nothing sensitive remains unenecrypted. You have to restart it after it stops.
257  Bitcoin / Bitcoin Technical Support / Re: How can P2SH outputs be spent? Non multisig. on: June 16, 2018, 06:46:54 PM
My mistake, thank you.  Carla makes the redeemScript and gives the hashed result, her address , to Bob.

Still, my point is that Carla needs the same redeemScript to send to Josh. After she does sends to Josh, Josh is not spending that TX just yet. In the meantime someone else, Nigel, looks at the TX Carla executed and sees the redeemScript. He can then spend the TXO and leave Josh empty handed. This is my theory, and what I am trying to reproduce on testnet.
Presumably Josh has his own redeemScript and does not share one with Carla so his redeemScript is unknown unless he has used it before. Furthermore, once Carla's transaction is confirmed, no one can spend that output.

You mentioned that redeemScripts are not retrieved from previous Tx's. I'm assuming you're not referring to P2SH addresses? From your explanation it sounds like a typical P2PKH where only the owner of the private key, associated with the public key of the address can spend the TX.
I misunderstood what you meant by "retrieving redeemScripts from previous transactions". You can retrieve a redeemScript for a previous transaction. However when a transaction is validated, redeemScripts are not retrieved from previous transactions (which is what I thought you meant).

My claim is this: If you are spending an UTXO of type P2SH that encapsulates the hash of an OP_TRUE, you can create a P2SH raw transaction with code that spends (conditioned on not being multisig) by using the redeemScript which was revealed in the previous TX.
That is true.

However, no one who legitimately wants to receive money would give someone else an address for an OP_TRUE script. With P2SH, they can specify any script they want, and most scripts that people use still have a public key and a signature. Additionally, well known scripts such as an OP_TRUE have known addresses and people have bots that actively look for transactions sending to an OP_TRUE address and sweeping the funds immediately.

I have a few questions please.

Q1: The redeemScript became visible on the blockchain after some amount was spent from TX, correct? How can we know it was supposed to correspond to
? Just by looking at [3 5 4]?
The script itself is the
part which is expanded into the script. You can decode this as a script and you will get that script.

Q2: In your example, clearly the recipient of tx is a P2PKH address
. That's simply because it happened to be the case that the owner of
knew how to solve the the redeemScript and just executed a tx in code, correct?
Not necessarily. It could be anyone who knew the redeemScript (by having generated it himself at some point) who created the transaction and sent it to 1GWdcSNAYdq3eG6YR4tb9YWiRvuC8k7J6V. It doesn't have to be the owner of that address.

What if let's say it was a P2SH address instead, and the TX resulted in a further unspent. Would anyone be (again) able to see the redeemScript and solve it even further? So unless the chain of TX's stops with a multisig or a P2PKH address, it can be further spent over and over again by anyone who can see and use this type of redeemScript?
No, it depends on the redeemScript. Not all redeemScripts are anyone-can-spend. You can specify anything you want, and most P2SH scripts that people use still require a signature.

Q3: Would I be able to reproduce such a transaction in Node and let's say bitcore-lib? I don't see why not but I am still trying to find specific details on github.
I don't think bitcore-lib allows you to create and spend from non-standard scripts (which is what you want) unless you make raw transactions yourself and construct the scriptSig and redeemScript manually.
258  Bitcoin / Development & Technical Discussion / Re: Different sites report different blockchain sizes? on: June 16, 2018, 12:11:12 AM
There are many reasons the reported sizes may be different. It depends on what they are actually measuring as "blockchain size".

A naive way of measuring would be to just take the size of the datadir for a bitcoind instance. However, this is going to include a bunch of extra data which is not actually the blockchain. This would include data like log files, wallet files, the UTXO set database, the block index, and the transaction index if that is enabled.

There may also be a discrepancy if one site does not run a segwit enabled node. Since a Segwit block is physically larger than the stripped block that a non-segwit node would receive, sites that support Segwit will report a larger blockchain.

Additionally, a site may receive more orphan blocks than another site which means that they are storing more blocks on disk. They may be measuring this as well which will cause the reported blockchain size to differ from sites that have received different orphan blocks.
259  Bitcoin / Bitcoin Technical Support / Re: How can P2SH outputs be spent? Non multisig. on: June 16, 2018, 12:06:12 AM

Bob sends 0.5 BTC to Carla, who is the owner of a P2SH address of the form 3xxxxxx.

For Carla to spend the 0.5 BTC and pay Josh, who also has a 3xxxxxx P2SH address, she needs the redeemScript from Bob.
No, this is incorrect. Carla does not need the redeemScript from Bob, she already has the redeemScript. In order for Bob to send Bitcoin to Carla, he has to have received an address from Carla to send to. Bob cannot just make up an address that Carla can theoretically spend and say he paid her. Rather Carla needs to create the address and give the address to Bob. So Carla would have to create the redeemScript, hash it and Base58 Check encode that to get the address. Then she gives the address to Bob so he can pay here. Thus Carla has the redeemScript and can spend the coins.

RedeemScripts are not retrieved from previous transactions.
260  Bitcoin / Development & Technical Discussion / Re: Getting connected to the Bitcoin Lightning network on: June 16, 2018, 12:00:26 AM
Have a read of It explains the steps for the testnet. The mainnet version is not ready yet.

There is no need to sync the blockchain or run LND by yourself. The Lighting App handles all of that for you. Furthermore, it uses a BIP 158 (Neutrino) light client so there is no need to sync the entire blockchain at all.
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 53 54 55 56 57 58 59 60 61 62 63 ... 551 » 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!