Connect with us
[crypto-donation-box]

Blockchain

Litecoin Core v0.18.1 Release Candidate

Republished by Plato

Published

on

Adrian Gallagher

Follow our Twitter for the latest dev news.

We are pleased to release Litecoin Core 0.18.1 release candidate. This is a new major version release, including new features, various bug fixes, performance improvements and updated translations.

It is recommended for power users to upgrade to this version. After sufficient testing, Litecoin Core 0.18.1 final will be released and is recommended for all users 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/Litecoin-Qt (on Mac) or litecoind/litecoin-qt (on Linux).

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 or later. Upgrading directly from 0.7.x and earlier without redownloading the blockchain is not supported. However, as usual, old wallet versions are still supported.

Litecoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not recommended to use Litecoin Core on unsupported systems.

Litecoin Core should also work on most other Unix-like systems but is not as 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. Additionally, Litecoin Core does not yet change appearance when macOS “dark mode” is activated.

In addition to previously-supported CPU platforms, this release’s pre-compiled distribution also provides binaries for the RISC-V platform.

Wallet GUI

For advanced users who have both (1) enabled coin control features, and (2) are using multiple wallets loaded at the same time: The coin control input selection dialog can erroneously retain wrong-wallet state when switching wallets using the dropdown menu. For now, it is recommended not to use coin control features with multiple wallets loaded.

Mining

  • Calls to getblocktemplate will fail if the segwit rule is not specified. Calling getblocktemplate without segwit specified is almost certainly a misconfiguration since doing so results in lower rewards for the miner. Failed calls will produce an error message describing how to enable the segwit rule.

Configuration option changes

  • A warning is printed if an unrecognized section name is used in the configuration file. Recognized sections are [test], [main], and [regtest].
  • Four new options are available for configuring the maximum number of messages that ZMQ will queue in memory (the “high water mark”) before dropping additional messages. The default value is 1,000, the same as was used for previous releases. See the ZMQ documentation for details.
  • The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration. If you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:9332:9332 (this is an extra :9332 over the normal Docker port specification).
  • The rpcpassword option now causes a startup error if the password set in the configuration file contains a hash character (#), as it’s ambiguous whether the hash character is meant for the password or as a comment.
  • The whitelistforcerelay option is used to relay transactions from whitelisted peers even when not accepted to the mempool. This option now defaults to being off, so that changes in policy and disconnect/ban behavior will not cause a node that is whitelisting another to be dropped by peers. Users can still explicitly enable this behavior with the command line option (and may want to consider contacting the Litecoin Core project to let us know about their use-case, as this feature could be deprecated in the future).

When creating a transaction with a fee above -maxtxfee (default 0.1 LTC), the RPC commands walletcreatefundedpsbt and fundrawtransaction will now fail instead of rounding down the fee. Beware that the feeRate argument is specified in LTC per kilobyte, not litoshi per byte.

  • A new short document about the JSON-RPC interface describes cases where the results of an RPC might contain inconsistencies between data sourced from different subsystems, such as wallet state and mempool state. A note is added to the REST interface documentation indicating that the same rules apply.
  • Further information is added to the JSON-RPC documentation about how to secure this interface.
  • A new document about the litecoin.conf file describes how to use it to configure Litecoin Core.
  • A new document introduces Litecoin Core’s BIP174 Partially-Signed Litecoin Transactions (PSBT) interface, which is used to allow multiple programs to collaboratively work to create, sign, and broadcast new transactions. This is useful for offline (cold storage) wallets, multisig wallets, coinjoin implementations, and many other cases where two or more programs need to interact to generate a complete transaction.
  • The output script descriptor documentation has been updated with information about new features in this still-developing language for describing the output scripts that a wallet or other program wants to receive notifications for, such as which addresses it wants to know received payments. The language is currently used in multiple new and updated RPCs described in these release notes and is expected to be adapted to other RPCs and to the underlying wallet structure.
  • A new --disable-bip70 option may be passed to ./configure to prevent Litecoin-Qt from being built with support for the BIP70 payment protocol or from linking libssl. As the payment protocol has exposed Litecoin Core to libssl vulnerabilities in the past, builders who don’t need BIP70 support are encouraged to use this option to reduce their exposure to future vulnerabilities.
  • The minimum required version of Qt (when building the GUI) has been increased from 5.2 to 5.5.1 (the depends system provides 5.9.7)
  • getnodeaddresses returns peer addresses known to this node. It may be used to find nodes to connect to without using a DNS seeder.
  • listwalletdir returns a list of wallets in the wallet directory (either the default wallet directory or the directory configured by the -walletdir parameter).
  • getrpcinfo returns runtime details of the RPC server. At the moment, it returns an array of the currently active commands and how long they’ve been running.
  • deriveaddresses returns one or more addresses corresponding to an output descriptor.
  • getdescriptorinfo accepts a descriptor and returns information about it, including its computed checksum.
  • joinpsbts merges multiple distinct PSBTs into a single PSBT. The multiple PSBTs must have different inputs. The resulting PSBT will contain every input and output from all of the PSBTs. Any signatures provided in any of the PSBTs will be dropped.
  • analyzepsbt examines a PSBT and provides information about what the PSBT contains and the next steps that need to be taken in order to complete the transaction. For each input of a PSBT, analyzepsbt provides information about what information is missing for that input, including whether a UTXO needs to be provided, what pubkeys still need to be provided, which scripts need to be provided, and what signatures are still needed. Every input will also list which role is needed to complete that input, and analyzepsbt will also list the next role in general needed to complete the PSBT. analyzepsbt will also provide the estimated fee rate and estimated virtual size of the completed transaction if it has enough information to do so.
  • utxoupdatepsbt searches the set of Unspent Transaction Outputs (UTXOs) to find the outputs being spent by the partial transaction. PSBTs need to have the UTXOs being spent to be provided because the signing algorithm requires information from the UTXO being spent. For segwit inputs, only the UTXO itself is necessary. For non-segwit outputs, the entire previous transaction is needed so that signers can be sure that they are signing the correct thing. Unfortunately, because the UTXO set only contains UTXOs and not full transactions, utxoupdatepsbt will only add the UTXO for segwit inputs.

Note: some low-level RPC changes mainly useful for testing are described in the Low-level Changes section below.

  • getpeerinfo now returns an additional minfeefilter field set to the peer’s BIP133 fee filter. You can use this to detect that you have peers that are willing to accept transactions below the default minimum relay fee.
  • The mempool RPCs, such as getrawmempool with verbose=true, now return an additional “bip125-replaceable” value indicating whether the transaction (or its unconfirmed ancestors) opts-in to asking nodes and miners to replace it with a higher-feerate transaction spending any of the same inputs.
  • settxfee previously silently ignored attempts to set the fee below the allowed minimums. It now prints a warning. The special value of “0” may still be used to request the minimum value.
  • getaddressinfo now provides an ischange field indicating whether the wallet used the address in a change output.
  • importmulti has been updated to support P2WSH, P2WPKH, P2SH-P2WPKH, and P2SH-P2WSH. Requests for P2WSH and P2SH-P2WSH accept an additional witnessscript parameter.
  • importmulti now returns an additional warnings field for each request with an array of strings explaining when fields are being ignored or are inconsistent, if there are any.
  • getaddressinfo now returns an additional solvable boolean field when Litecoin Core knows enough about the address’s scriptPubKey, optional redeemScript, and optional witnessScript in order for the wallet to be able to generate an unsigned input spending funds sent to that address.
  • The getaddressinfo, listunspent, and scantxoutset RPCs now return an additional desc field that contains an output descriptor containing all key paths and signing information for the address (except for the private key). The desc field is only returned for getaddressinfo and listunspent when the address is solvable.
  • importprivkey will preserve previously-set labels for addresses or public keys corresponding to the private key being imported. For example, if you imported a watch-only address with the label “cold wallet” in earlier releases of Litecoin Core, subsequently importing the private key would default to resetting the address’s label to the default empty-string label (“”). In this release, the previous label of “cold wallet” will be retained. If you optionally specify any label besides the default when calling importprivkey, the new label will be applied to the address.
  • See the Mining section for changes to getblocktemplate.
  • getmininginfo now omits currentblockweight and currentblocktx when a block was never assembled via RPC on this node.
  • The getrawtransaction RPC & REST endpoints no longer check the unspent UTXO set for a transaction. The remaining behaviors are as follows: 1. If a blockhash is provided, check the corresponding block. 2. If no blockhash is provided, check the mempool. 3. If no blockhash is provided but txindex is enabled, also check txindex.
  • unloadwallet is now synchronous, meaning it will not return until the wallet is fully unloaded.
  • importmulti now supports importing of addresses from descriptors. A “desc” parameter can be provided instead of the “scriptPubKey” in a request, as well as an optional range for ranged descriptors to specify the start and end of the range to import. Descriptors with key origin information imported through importmulti will have their key origin information stored in the wallet for use with creating PSBTs. More information about descriptors can be found here.
  • listunspent has been modified so that it also returns witnessScript, the witness script in the case of a P2WSH or P2SH-P2WSH output.
  • createwallet now has an optional blank argument that can be used to create a blank wallet. Blank wallets do not have any keys or HD seed. They cannot be opened in software older than 0.18. Once a blank wallet has a HD seed set (by using sethdseed) or private keys, scripts, addresses, and other watch only things have been imported, the wallet is no longer blank and can be opened in 0.17.x. Encrypting a blank wallet will also set a HD seed for it.
  • signrawtransaction is removed after being deprecated and hidden behind a special configuration option in version 0.17.0.
  • The ‘account’ API is removed after being deprecated in v0.17. The ‘label’ API was introduced in v0.17 as a replacement for accounts. See the release notes from v0.17 for a full description of the changes from the ‘account’ API to the ‘label’ API.
  • addwitnessaddress is removed after being deprecated in version 0.16.0.
  • generate is deprecated and will be fully removed in a subsequent major version. This RPC is only used for testing, but its implementation reached across multiple subsystems (wallet and mining), so it is being deprecated to simplify the wallet-node interface. Projects that are using generate for testing purposes should transition to using the generatetoaddress RPC, which does not require or use the wallet component. Calling generatetoaddress with an address returned by the getnewaddress RPC gives the same functionality as the old generate RPC. To continue using generate in this version, restart litecoind with the -deprecatedrpc=generate configuration option.
  • Be reminded that parts of the validateaddress command have been deprecated and moved to getaddressinfo. The following deprecated fields have moved to getaddressinfo: ismine, iswatchonly, script, hex, pubkeys, sigsrequired, pubkey, embedded, iscompressed, label, timestamp, hdkeypath, hdmasterkeyid.
  • The addresses field has been removed from the validateaddress and getaddressinfo RPC methods. This field was confusing since it referred to public keys using their P2PKH address. Clients should use the embedded.address field for P2SH or P2WSH wrapped addresses, and pubkeys for inspecting multisig participants.
  • A new /rest/blockhashbyheight/ endpoint is added for fetching the hash of the block in the current best blockchain based on its height (how many blocks it is after the Genesis Block).
  • A new Window menu is added alongside the existing File, Settings, and Help menus. Several items from the other menus that opened new windows have been moved to this new Window menu.
  • In the Send tab, the checkbox for “pay only the required fee” has been removed. Instead, the user can simply decrease the value in the Custom Feerate field all the way down to the node’s configured minimum relay fee.
  • In the Overview tab, the watch-only balance will be the only balance shown if the wallet was created using the createwallet RPC and the disable_private_keys parameter was set to true.
  • The launch-on-startup option is no longer available on macOS if compiled with macosx min version greater than 10.11 (use CXXFLAGS=”-mmacosx-version-min=10.11″ CFLAGS=”-mmacosx-version-min=10.11″ for setting the deployment sdk version)
  • A new litecoin-wallet tool is now distributed alongside Litecoin Core’s other executables. Without needing to use any RPCs, this tool can currently create a new wallet file or display some basic information about an existing wallet, such as whether the wallet is encrypted, whether it uses an HD seed, how many transactions it contains, and how many address book entries it has.

This section describes planned changes to Litecoin Core that may affect other Litecoin software and services.

  • Since version 0.16.0, Litecoin Core’s built-in wallet has defaulted to generating P2SH-wrapped segwit addresses when users want to receive payments. These addresses are backwards compatible with all widely-used software. Starting with Litecoin Core 0.20 (expected about a year after 0.18), Litecoin Core will default to native segwit addresses (bech32) that provide additional fee savings and other benefits. Currently, many wallets and services already support sending to bech32 addresses, and if the Litecoin Core project sees enough additional adoption, it will instead default to bech32 receiving addresses in Litecoin Core 0.20. P2SH-wrapped segwit addresses will continue to be provided if the user requests them in the GUI or by RPC, and anyone who doesn’t want the update will be able to configure their default address type. (Similarly, pioneering users who want to change their default now may set the addresstype=bech32 configuration option in any Litecoin Core release from 0.16.0 up.)
  • BIP 61 reject messages are now deprecated. Reject messages have no use case on the P2P network and are only logged for debugging by most network nodes. Furthermore, they increase bandwidth and can be harmful for privacy and security. It has been possible to disable BIP 61 messages since v0.17 with the -enablebip61=0 option. BIP 61 messages will be disabled by default in a future version, before being removed entirely.

This section describes RPC changes mainly useful for testing, mostly not relevant in production. The changes are mentioned for completeness.

  • The submitblock RPC previously returned the reason a rejected block was invalid the first time it processed that block, but returned a generic “duplicate” rejection message on subsequent occasions it processed the same block. It now always returns the fundamental reason for rejecting an invalid block and only returns “duplicate” for valid blocks it has already accepted.
  • A new submitheader RPC allows submitting block headers independently from their block. This is likely only useful for testing.
  • The signrawtransactionwithkey and signrawtransactionwithwallet RPCs have been modified so that they also optionally accept a witnessScript, the witness script in the case of a P2WSH or P2SH-P2WSH output. This is compatible with the change to listunspent.
  • For the walletprocesspsbt and walletcreatefundedpsbt RPCs, if the bip32derivs parameter is set to true but the key metadata for a public key has not been updated yet, then that key will have a derivation path as if it were just an independent key (i.e. no derivation path and its master fingerprint is itself).
  • The -usehd configuration option was removed in version 0.16. From that version onwards, all new wallets created are hierarchical deterministic wallets. This release makes specifying -usehd an invalid configuration option.
  • This release allows peers that your node automatically disconnected for misbehavior (e.g. sending invalid data) to reconnect to your node if you have unused incoming connection slots. If your slots fill up, a misbehaving node will be disconnected to make room for nodes without a history of problems (unless the misbehaving node helps your node in some other way, such as by connecting to a part of the Internet from which you don’t have many other peers). Previously, Litecoin Core banned the IP addresses of misbehaving peers for a period of time (default of 1 day); this was easily circumvented by attackers with multiple IP addresses. If you manually ban a peer, such as by using the setban RPC, all connections from that peer will still be rejected.
  • The key metadata will need to be upgraded the first time that the HD seed is available. For unencrypted wallets this will occur on wallet loading. For encrypted wallets this will occur the first time the wallet is unlocked.
  • Newly encrypted wallets will no longer require restarting the software. Instead such wallets will be completely unloaded and reloaded to achieve the same effect.
  • A sub-project of Litecoin Core now provides Hardware Wallet Interaction (HWI) scripts that allow command-line users to use several popular hardware key management devices with Litecoin Core. See their project page for details.
  • This release changes the Random Number Generator (RNG) used from OpenSSL to Litecoin Core’s own implementation, although entropy gathered by Litecoin Core is fed out to OpenSSL and then read back in when the program needs strong randomness. This moves Litecoin Core a little closer to no longer needing to depend on OpenSSL, a dependency that has caused security issues in the past. The new implementation gathers entropy from multiple sources, including from hardware supporting the rdseed CPU instruction.
  • On macOS, Litecoin Core now opts out of application CPU throttling (“app nap”) during initial blockchain download, when catching up from over 100 blocks behind the current chain tip, or when reindexing chain data. This helps prevent these operations from taking an excessively long time because the operating system is attempting to conserve power.

To download, please visit the download page here. Alternatively, you can view the download folder here.

Please use GPG to verify the integrity of the release binaries. This ensures that the binary you have downloaded has not been tampered with. Linux, MacOS and Win32 cygwin command line GPG instructions are available here. Please also note that we GPG sign the binaries as a convenience to you, the ultimate way to verify the integrity of the builds is to build them yourself using Gitian. Instructions on how to perform these builds, can be found here.

For this release, the binaries have been signed with key identifier FE3348877809386C (thrasher’s key).

Despite this version being heavily tested, this version may still contain bugs. Always backup your wallet.dat file before upgrading. If you encounter any issues, please let us know by posting to the bug reporting section below.

The master branch contains the latest commits to the next stable releases of Litecoin Core.

Build instructions for Linux can be found here.

Build instructions for OSX can be found here.

Builds instructions for Windows can be found here.

Submit any issues you encounter here and one of the Litecoin developers will assist you.

Sign up for announcements only or development discussion.

These are the SHA-256 hashes of the released files:

b8a118e94703e84128bec31a99a59b91af54edb1b0470b970cec3809fc8753ae litecoin-0.18.1-aarch64-linux-gnu.tar.gz
7a47b11065c86a661eec3eb5ba8d157d65ac7e16930fbd381e519d4dcbf86574 litecoin-0.18.1-arm-linux-gnueabihf.tar.gz
58be96c96f7579f05acb3b544698a3e1cd8ede8fb10874ccc7ce1ee9de4f3fc0 litecoin-0.18.1-i686-pc-linux-gnu.tar.gz
8798e030235e2099a456f06a8488a5567641058885965da03036538fa57df0a6 litecoin-0.18.1-osx64.tar.gz
68f4348cb9aa913845a94bcc93718b83b593999ed41e245cdfed0477ec1a9631 litecoin-0.18.1rc1-osx.dmg
7b7f78588340d26b222ff927c7bbfa5eafa68d80b8408d1835f537361a4d9123 litecoin-0.18.1rc1-win32-setup.exe
b76f31c9e7341ffb21f655cfa217ee50b9cde4e10f117eba7167aff85a57e769 litecoin-0.18.1rc1-win64-setup.exe
00e05c776d57443127ed4a75c5a27b3789f8f7bbf01edb668bfa75ac138a49d3 litecoin-0.18.1-riscv64-linux-gnu.tar.gz
6dfa71ccf059463f0a304f85ff1ca8b88039d63e93269d6f056ab24915be936d litecoin-0.18.1.tar.gz
4aea854431c495f43bf3665fc6c0e18f2e6a0caf2b5c4682b8aca4875650c5ad litecoin-0.18.1-win32.zip
fa47ab17be61a924ac5dcba251cbea919aef7ff2dabe7803a6b3af402ef1fe75 litecoin-0.18.1-win64.zip
3c8d2cd2cc06645fc553ced8361c6951eef50e09dc2334268625902bcdb18f76 litecoin-0.18.1-x86_64-linux-gnu.tar.gz

Thanks to everyone who directly contributed to this release:

  • The Bitcoin Core Developers
  • Adrian Gallagher
  • aunyks
  • coblee
  • cryptonexii
  • EP1JUNE
  • gabrieldov
  • jmutkawoa
  • Loshan
  • Martin Smith
  • NeMO84
  • OlegKozhemiakin
  • ppm0
  • romanornr
  • shaolinfry
  • spl0i7
  • stedwms
  • ultragtx
  • VKoskiv
  • voidmain
  • wbsmolen
  • xinxi

Source: https://blog.litecoin.org/litecoin-core-v0-18-1-release-candidate-22bfdc95a65a?source=rss—-d41bceeb173b—4

Blockchain

Bitcoin Proponents Against Elon Musk Following Heated Dogecoin vs Bitcoin Tweets

Republished by Plato

Published

on

Last week, Elon Musk and Tesla shocked the entire crypto industry following an announcement that the electric car company will no longer accept bitcoin payments for “environmental reasons.”

A Hard Pill For Bitcoin Maximalists

Giving its reasons, Tesla argued that Bitcoin mining operation requires massive energy consumption, which is generated from fossil fuel, especially coal, and as such, causes environmental pollution.

The announcement caused a market dip which saw over $4 billion of both short and long positions liquidated as the entire capitalization lost almost $400 billion in a day.

For Bitcoin maximalists and proponents, Tesla’s decision was a hard pill to swallow, and that was evident in their responses to the electric car company and its CEO.

While the likes of Max Keiser lambasted Musk for his company’s move, noting that it was due to political pressure, others like popular YouTuber Chris Dunn were seen canceling their Tesla Cybertruck orders.


ADVERTISEMENT

Adding more fuel to the fire, Musk also responded to a long Twitter thread by Peter McCormack, implying that Bitcoin is not actually decentralized.

Musk Working With Dogecoin Devs

Elon Musk, who named himself the “Dogefather” on SNL, created a Twitter poll, asking his nearly 55 million followers if they want Tesla to integrate DOGE as a payment option.

The poll, which had almost 4 million votes, was favorable for Dogecoin, as more than 75% of the community voted “Yes.”

Following Tesla’s announcement, the billionaire tweeted that he is working closely with Dogecoin developers to improve transaction efficiency, saying that it is “potentially promising.”

Tesla dropping bitcoin as a payment instrument over energy concerns, with the possibility of integrating dogecoin payments, comes as a surprise to bitcoiners since the two cryptocurrencies use a Proof-of-Work (PoW) consensus algorithm and, as such, face the same underlying energy problem.

Elon Musk: Dogecoin Wins Bitcoin

Despite using a PoW algorithm, Elon Musk continues to favor Dogecoin over Bitcoin. Responding to a tweet that covered some of the reasons why Musk easily chose DOGE over BTC, the billionaire CEO agreed that Dogecoin wins Bitcoin in many ways.

Comparing DOGE to BTC, Musk noted that “DOGE speeds up block time 10X, increases block size 10X & drops fee 100X. Then it wins hands down.”

Max Keiser: Who’s The Bigger Idiot?

As Elon Musk continues his lovey-dovey affair with Dogecoin, Bitcoin proponents continue to criticize the Dogefather.

Following Musk’s comments on Dogecoin today, popular Bitcoin advocate Max Keiser took to his Twitter page to ridicule the Tesla boss while recalling when gold bug Peter Schiff described Bitcoin as “intrinsically worthless” after he lost access to his BTC wallet.

“Who’s the bigger idiot?” Keiser asked.

Aside from Keiser, other Bitcoin proponents such as Michael Saylor replied to Tesla’s CEO:

SPECIAL OFFER (Sponsored)

Binance Futures 50 USDT FREE Voucher: Use this link to register & get 10% off fees and 50 USDT when trading 500 USDT (limited offer).

PrimeXBT Special Offer: Use this link to register & enter POTATO50 code to get 50% free bonus on any deposit up to 1 BTC.

You Might Also Like:


Coinsmart. Beste Bitcoin-Börse in Europa
Source: https://cryptopotato.com/bitcoin-proponents-against-elon-musk-following-heated-dogecoin-vs-bitcoin-tweets/

Continue Reading

Blockchain

Tesla CEO Elon Musk Explains Why ‘Bitcoin Is Actually Highly Centralized’

On Sunday (May 16), Tesla and Space X CEO Elon Musk attacked Bitcoin (BTC) for being highly centralized after podcaster Peter McCormack criticized Musk for supporting Dogecoin (DOGE) and for spreading misinformation about Bitcoin. As you probably already know, on May 12, Tesla and SpaceX CEO Elon Musk shocked the world by complaining about Bitcoin mining’s […]

Republished by Plato

Published

on

On Sunday (May 16), Tesla and Space X CEO Elon Musk attacked Bitcoin (BTC) for being highly centralized after podcaster Peter McCormack criticized Musk for supporting Dogecoin (DOGE) and for spreading misinformation about Bitcoin.

As you probably already know, on May 12, Tesla and SpaceX CEO Elon Musk shocked the world by complaining about Bitcoin mining’s high usage of fossil fuels and saying that for this reason Tesla would not be accepting Bitcoin as a form of payment until “mining transitions to more sustainable energy.”

The next day, Musk revealed that has been working with Dogecoin developers to reduce the power consumption of mining of the meme-based cryptocurrency.

In fact, as Decrypt reported on May 14, according to Ross Nicoll, one of the part-time Dogecoin developers Decrypt talked to, Musk “started talking to the developers in 2019, he has ‘encouraged them to improve the higher transaction throughput,’ provided ‘lots of advice and input,’ and shared his vast Rolodex of contacts.”

Nicoll also said (1) that the dev team he is part of is hoping to reuce Dogecoin’s power consumption; (2) Musk has been with Dogecoin’s dev team since April 2019 (when he said that Dogecoinmight be his favortie cryptocurrency); and (3) that Musk had offered to fund the team, but his offer of financial support had been rejected (just as with offers they had received from other wealthy potential backers).

Yesterday, Dogecoin supporter “@itsALLrisky” said on Twitter explained why he thinks that Dogecoin, which Musk has referred to as “people’s crypto”, is better than Bitcoin. Musk said Dogecoin would beat Bitcoin “hands down” if its developers made three improvements: 10X faster block production time, 10X larger block size, and 100X lower transaction fees.

Well, today, McCormack criticized Musk for supporting meme-based Dogecoin, which he thinks could potentially result in ill-informed investors in $DOGE suffering big losses, as well as causing harm to Bitcoin’s reputation and its ecosystem.

McCormack’s accusations angered Musk, who seemingly warned that he might just “go all in on Doge.”

Musk then went on to explain why he believes that Bitcoin is highly centralized.

DISCLAIMER

The views and opinions expressed by the author, or any people mentioned in this article, are for informational purposes only, and they do not constitute financial, investment, or other advice. Investing in or trading cryptoassets comes with a risk of financial loss.

Coinsmart. Beste Bitcoin-Börse in Europa
Source: https://www.cryptoglobe.com/latest/2021/05/tesla-ceo-elon-musk-explains-why-bitcoin-is-actually-highly-centralized/

Continue Reading

Blockchain

ETH Developers Calculated How To Defuse The Difficulty Bomb

Republished by Plato

Published

on

ADVERTISEMENT

ETH developers calculated how to defuse the difficulty bomb because if they leave it untreated, they will slow down the network as we can see more in our Ethereum news today.

Ethereum’s encoded difficulty bomb is set to explode this summer and James Hancock as well as Tim beiko said that the ETH developers calculated the time needed to delay the bomb and this could the last time the developers need to take that action. Ethereum developers agreed on Friday how to delay the difficulty bomb ad if that is left untreated, the entire network could be slowed down. The difficulty bomb is an old piece of code that makes mining on ETH slower and less profitable over time by increasing the lag between the production of blocks.

Ethereum 2.0 switches the network from proof of work as a way of validating transactions with powerful mining computers to Proo of Stake which rewards the ones that pledge the coins to the network. It takes an average of 13 seconds to mine a block on ETH right now and without delaying the bomb, it could take more than 20 seconds to validate the block by the end of the year. Ethereum developers agreed on how many blocks were quite necessary to delay the bomb until December. The calculation for the delay was proposed by the ETH core developers James Hancock as he said:

ADVERTISEMENT

“The bomb’s always there, and we defuse it by turning the blocktime back just for the bomb.”

block time
The block time chart on Etherscan. Annotated by James Hancock for Decrypt.

He later said that the proposal will delay the bomb by 9,700,000 blocks. Tim Beiko, the ETH core developer also said that the developers dismissed a proposal to delay the bomb next spring but that won’t be necessary. The developers expected that by December, the network will update to allow the ETH 1.0 the network that relies on PoW to communicate with ETH 2.0 as the new network relies on PoS and this is known as the Merge:

“If the Merge is ready by December, we won’t need to do anything about the bomb because we will move away from mining entirely.”

If the merge plans remain unimplemented, the Shanghai fork is expected to go live and will delay the bomb once again. The Bomb has been delayed three times so far.

DC Forecasts is a leader in many crypto news categories, striving for the highest journalistic standards and abiding by a strict set of editorial policies. If you are interested to offer your expertise or contribute to our news website, feel free to contact us at [email protected]

Coinsmart. Beste Bitcoin-Börse in Europa
Source: https://www.dcforecasts.com/ethereum-news/eth-developers-calculated-how-to-defuse-the-difficulty-bomb/

Continue Reading
Blockchain5 days ago

Billionaire Druckenmiller says ledger-based system could replace USD worldwide

Blockchain4 days ago

First Spot: Coinbase’s App Surpassed TikTok, Instagram, and Facebook on iOS in the US

Blockchain4 days ago

Raze Network Kicks Off Testnet Phase With UI Community Voting

Blockchain4 days ago

dotmoovs Raises $840,000 From Strategic Investors and Partners

Blockchain5 days ago

The challenges with designing a CBDC, explained

Blockchain4 days ago

Casper Network’s CSPR Spot Trading Now Open on OKEx

Blockchain4 days ago

How did Internet Computer (ICP) become a top-10 cryptocurrency overnight?

Blockchain4 days ago

When dollars meet the hype: The biggest NFT hits from celebrities

Blockchain5 days ago

Uniswap flips Bitcoin on daily revenue… and it’s more impressive than you think

Blockchain4 days ago

PARSIQ Integrated Into Polkadot For Smart Triggers Across the Relay Chain

Blockchain3 days ago

US Investment Bank Cowen to Offer Crypto Custody Services

Blockchain5 days ago

Polkadot, Cosmos, Bitcoin Cash Price Analysis: 11 May

Blockchain4 days ago

From cypherpunk to state contracts: the changing face of blockchain

Blockchain4 days ago

DeFi lending platform Aave reveals “private pool” for institutions

Blockchain5 days ago

TA: Ethereum Overcame Odds With New High, Here’s Why ETH Could Test $4.5K

Blockchain4 days ago

MoneyGram to Enable Users to Buy Bitcoin and Withdraw it From Birck-and-Mortar Locations

Blockchain4 days ago

Griff Green: Doge-loving hippy hacker steals crypto before bad guys can

Blockchain4 days ago

Here are the Top DeFi Tokens With The Largest Price Jumps This Week

Blockchain4 days ago

As Elon Musk’s SpaceX Literally Sends Dogecoin To The Moon, Justin Sun Craves For Tron to Tag Along

Blockchain4 days ago

Gaming Giant Kinguin Taps Immutable X for NFT Offering

Trending