Bitcoin Forum
September 25, 2018, 06:22:34 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
  Home Help Search Donate Login Register  
  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 ... 544 »
81  Bitcoin / Development & Technical Discussion / Re: Bitcoin RPC send error code -3 - Invalid Amount on: July 05, 2018, 10:04:47 PM
no, amount in float is > 0
That error code and string occur in only 4 places in the code, with each one protected by an if branch checking whether the amount given is <= 0. If you are getting this error, then your amount is being interpreted as being <= 0, regardless of what you intended it to be.
I don't think it is because the value is <= 0.
According to OP, there is a value > 0 (at least thats what it looks like according to the output to the screen):

print 'res = cc.sendtoaddress(addr, amo - txfee)', amo - txfee
res = cc.sendtoaddress(addr, amo - txfee) 0.14297412
I assume it is a type error. Thats what status code -3 should be for:
Quote
RPC_TYPE_ERROR = -3, //!< Unexpected type was passed as parameter
from: https://github.com/bitcoin/bitcoin/blob/v0.15.0.1/src/rpc/protocol.h#L50
Every RPC error comes with an error code and a message. The message was "Invalid amount for send". As I said earlier, this only appears in 4 places and is guarded by only a check for negative or 0 values. This error can only be triggered by having a negative or 0 amount. This is still a type error, but type error can still mean many things. In this case, the type is "positive decimal" which is not what is being provided.
82  Bitcoin / Development & Technical Discussion / Re: Generating addresses for accepting payments on: July 05, 2018, 07:56:27 PM
The derivation path is way out there. Instead of 2147.. something you should use 0. That part can only be 0 for external addresses and 1 for change addresses.
That's just another way to write the derivation path for 1'. Hardened derivation are indexes beginning at 2147483648, but for simplicity we use ' or h to indicate this.
83  Bitcoin / Development & Technical Discussion / Re: Bitcoin RPC send error code -3 - Invalid Amount on: July 05, 2018, 07:52:40 PM
no, amount in float is > 0
That error code and string occur in only 4 places in the code, with each one protected by an if branch checking whether the amount given is <= 0. If you are getting this error, then your amount is being interpreted as being <= 0, regardless of what you intended it to be.
84  Bitcoin / Development & Technical Discussion / Re: Alert Keys and Alert System Vulnerabilities Disclosure on: July 05, 2018, 07:10:11 PM
But it's not sufficient, sendalert system let all users to be informed about an event or critical issue at the same moment ... this system is really required for Bitcoin and it's not made for nothing in the firsts versions.

If we focus on online medias, you must notice that peoples not follow the same one, and time to publish news about an event differs from media to another, there even peoples that not follow news or read them ... there many peoples interested on Bitcoin, even those who don't speak English, and since almost all the news medias are in english, this exclude them aswell.
There are many Bitcoin media sites in non-english languages. There are also many forums in non-english languages. From previous events, we know that these things get reported on fairly quickly and the news spreads around fairly quickly. There isn't any need for the alert system.

The other reasons for removing the alert system were its centralization and insecurity. No one knew exactly who held the alert key. Anyone who did could send an alert and this poses a security risk. Furthermore, there was some talk previously about using the alert key for non-alert things and rather as a way for developers to force changes in a centralized manner. This is completely undesirable, and combined with the fact that we had no idea who had the alert key, it needed to be removed.

Since we are on a decentralized solution, and there a way for an improvement or create new similar alert system based on new algorythm or architecture, why not ?
Sure, that's something that has been discussed. But there is no urgent need for one, and we believe that existing news and media are sufficient for getting information out to everyone.

And to push things further, why not a decentralized self updating system ?
Automatic updates (and updates in general) are inherently centralized. You need to get the binaries from a centralized distribution source.

But what if we follow the majority ? just like mining system (A 51% Update)
That's not at all how mining works. It isn't just "follow the majority".

... blockchain detect the most used version of Bitcoin Core (Keeping all this decentralized) and update the other clients automatically in case of critical security alert. Or atleast notify the other clients instead of auto update them.
There is no way to detect reliably what version clients are running. It is easy to spoof the version you are using and it is impossible for a third party to verify that you are running that version. If an attacker compromises the distribution server, they can easily spin up fake nodes for their new compromised version and then people with the auto updater will then update to the compromised version. Any sort of auto updating feature has the same problem. Additionally, the Bitcoin Core developers do not want to force people to use specific versions; it is up to the node operators to update at their own convenience.
85  Bitcoin / Development & Technical Discussion / Re: Generating addresses for accepting payments on: July 05, 2018, 06:50:14 AM
The address format is incorrect for testnet. Your addresses should start with m or n, not 1.

the receiver wallet does not get the funds. What am I doing wrong?
How did you determine that it did not receive the funds? Are you checking a testnet block explorer or are you expecting some sort of notification from the library that there was a transaction?
86  Bitcoin / Development & Technical Discussion / Re: walletnotify possible options? on: July 05, 2018, 02:11:20 AM
No, there is not.
87  Bitcoin / Bitcoin Technical Support / Re: Can I delete my wallet.dat without problems ? on: July 04, 2018, 11:08:56 PM
My question is, when I delete the wallet.dat, will Bitcoin Core generate a new one for me or will there be thousands of error messages ?
Bitcoin Core automatically creates a new wallet file if one does not already exist.
88  Bitcoin / Development & Technical Discussion / Re: Clarification on Off-chain Atomic Swap Lighting Network on: July 04, 2018, 04:21:34 AM
If that is the case, how is it that the lighting network website mentions that this cross chain atomic swap is feasible as long as both blockchain support the same cryptographic function?

It's on the fourth point under Transaction for the Future.
https://lightning.network/
There are multiple cryptographic hash functions used in different places in Bitcoin (and other cryptocurrencies) and in the Lightning Network. What that section is specifically talking about is the scripting language and that the scripting language must support the same hash functions. The hash functions in the scripting language are completely separate from the hash functions used in the PoW.

The Lightning Network operates solely on transactions and scripts which are independent of block related consensus rules, including the Proof of Work.
89  Bitcoin / Bitcoin Technical Support / Re: Redeem coins from Time-locked address on: July 04, 2018, 12:10:33 AM
That error means that the signature is invalid. coinb.in has, for quite a while now, been known to have issues with their signer which results in invalid signatures.

Looking at the transaction, it is actually incomplete. It is completely missing the redeemScript.
90  Bitcoin / Development & Technical Discussion / Re: Bitcoin RPC send error code -3 - Invalid Amount on: July 04, 2018, 12:08:12 AM
The error has nothing to do with the wallet.

Error code -3 means that there was a type error. With the error message "invalid amount for send", the amount that was specified was less than or equal to 0. This means that your code probably has a bug in it where amo is too small.
91  Bitcoin / Development & Technical Discussion / Re: Clarification on Off-chain Atomic Swap Lighting Network on: July 04, 2018, 12:02:52 AM
No, the hash function for the PoW is irrelevant to the Lightning Network. It does not matter if they are the same or if they are different.
92  Bitcoin / Bitcoin Technical Support / MOVED: P2PUBKEY in witness program on: July 03, 2018, 11:59:46 PM
This topic has been moved to Trashcan.

Duplicate thread
93  Bitcoin / Development & Technical Discussion / Re: Alert Keys and Alert System Vulnerabilities Disclosure on: July 03, 2018, 11:58:44 PM
But is there any study about a risk of Buffer Overflow Attack ? This will result in a big losses if some hackers manage to exploit it (Of course if exploitable, hence my question).
No buffer overflow attacks were found. All known attacks were described in this post. With the C++ standard library, it's actually kind of hard to get a buffer overflow.

How the sendalert key disclosed ? is it owned by you before ? Are you satoshi nakamoto or he passed it to you when he is retired from the project ?
The alert key was owned by numerous people; the full list is actually unknown because it is impossible to know whether someone passed the alert key to someone else and simply did not say so. The alert key was created by Satoshi and passed to others, including gmaxwell, sipa, kanzure, wumpus, theymos, etc. Kanzure (Bryan Bishop) who co-authored this text, had the alert key and he was the one to disclose it.

Why not fixing it ? Isn't it benifical for bitcoin core ? How you will manage to inform peoples about potential risk in the futur ?
Because we want to get rid of the alert system. It has already been removed from Bitcoin Core for several years. There are already sufficient media outlets and sites where people get their news about Bitcoin. If there is a network event in the future, people can easily get information about it from those places.
94  Bitcoin / Development & Technical Discussion / Re: How is the target value (PoW) determined? on: July 03, 2018, 06:59:50 PM
I am confused about miners being able to modify timestamp data within the header. I thought the only modifiable piece of data within the header was the nonce. I understand changing the Merkle root, through different transactions being included in a trial block, but how are timestamps modifiable?
It is impossible to enforce that the timestamp be exactly a specific time due to network latency and the imprecision of clocks in computers. So the timestamp in a block just has to be within a range of times that goes from the median time of the last 11 blocks to a few hours ahead of current time. A miner can modify the timestamp as long as it fits within this range of time.

I thought the timestamps where reliant upon the sender, and when they pushed their transaction, is this incorrect?
No. Transactions do not have timestamps and their times have no effect on the block's timestamp.

Now I'm wondering what happened if/when SHA-256 becomes compromised to some degree.
There are two forms of "compromised" for hash functions: a preimage attack and a collision attack. A preimage attack allows the attacker to determine the data that a given hash came from. Basically a preimage attack allows you to reverse a hash. This kind of attack is difficult, and AFAIK, no known preimage attack has been found for any hash function, even ones considered broken. If a preimage attack were found on SHA256, it may allow miners to simply mine blocks faster. Depending on how the attack works. this could mean that blocks are found at a constant time regardless of the difficulty. But such attacks are unlikely, and even if one existed, it may not even result in finding a valid block header since, technically, there are infinitely many pieces of data that hash to a given hash.

Collision attacks are a different story. Collision attacks are much easier to find and possibly more problematic than a preimage attack. All broken hash functions are broken because of collision attacks. A collision attack is where two pieces of data can be found that hash to the same thing. Although technically there exists infinitely many pieces of data that hash to the same thing, finding those pieces of data is incredibly hard and there are so many possible hashes that finding a collision through brute force would take a very very long time. However, a collision attack allows someone to find two colliding pieces of data in a practical time frame (e.g. several years). If someone were able to find another valid block which has a hash that matches one of another existing block (so a collision), then there would be a lot of problems since the hashes would match but the transaction history could be different.
95  Bitcoin / Bitcoin Technical Support / Re: Does lightning actually work? on: July 03, 2018, 07:45:44 AM
It does actually work, and many people have made and received many payments. All of the software for the Lightning Network are still in beta and actively being worked on. What you are experiencing are just the issues that come with using prerelease software.
96  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: https://gist.github.com/laanwj/0e689cfa37b52bcbbb44
97  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.
98  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


Background

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:

Code:
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:

Code:
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.

From https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016189.html
99  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.
100  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.
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 ... 544 »
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!