Bitcoin Forum
August 17, 2018, 09:37:57 AM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Btcd Version 0.12.0 Released - Alternative fullnode bitcoin implementation in Go  (Read 1369 times)
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2912
Merit: 1068


I support freedom of choice


View Profile WWW
November 22, 2015, 05:36:40 PM
 #1

Description
Alternative full node bitcoin implementation written in Go

Code:
https://github.com/btcsuite/btcd


https://blog.companyzero.com/2015/11/btcsuite-announcing-btcd-0-12-0-release/

Reddit: https://www.reddit.com/r/Bitcoin/comments/3ttu4k/btcsuite_announcing_btcd_0120_release/


Overview
In addition to announcing the new release, the purpose of this blog is to discuss a few points of the release in more detail. For those of you who are simply looking for the release notes and updated Windows binaries, they are located here.


The most important changes this post will cover are:
CHECKLOCKTIMEVERIFY (CLTV) support (BIP0065)
Enforce LowS signatures for transaction relay
New flag for controlling the minimum relay fee
Bloom filter service bit support (BIP0111)
New signature validation cache
Developer-centric changes:
-Refactored peer package
-New options when querying address index
Under development


CHECKLOCKTIMEVERIFY Support (BIP0065)
This release implements BIP0065 which introduces a new opcode named CHECKLOCKTIMEVERIFY that provides the scripting system a method to guarantee a transaction is unspendable until a specific date, or block height, in the future. While transactions already contained a lock time field, there was no way to enforce it via the scripting system prior to this new opcode.

The deployment of this new opcode is done via a soft fork using the same voting mechanism employed by BIP0034 and BIP0066 and entails adding a new block version 4 which treats the NOP2 opcode as CHECKLOCKTIMEVERIFY and enforces the new lock time restrictions.

In addition, all block templates returned by the getblocktemplate RPC will now be block version 4 compliant. This means solo miners using the getblocktemplate RPC will need to ensure their preferred software is updated to support the new block version and rules. Miners using a pool should follow the instructions provided by their pool operator.


Enforce LowS Signatures For Relay
ECDSA signatures are now required to be encoded with the canonical ‘low-s’ encoding in order to be relayed or accepted into the memory pool. This is useful since it helps reduce the number of malleable transactions relayed across the network and included in blocks.

However, please note that this is only a standardness check as opposed to a consensus change. This is an important distinction because it means it is still possible for miners to include signatures which do not conform to this encoding in blocks and therefore software must not assume old style signatures are impossible.

An important consequence of this change is that old software which creates transaction signatures that do not conform to this rule will need to be updated to produce transactions which are not rejected. That said, there are a wide variety of conforming implementations already available including the btcsuite signing code which has already produced signatures conforming to this encoding since Jul 31, 2014.


New Flag for Controlling the Minimum Relay Fee
As many users have probably noticed, there has recently been an increasing number of low-fee transactions flooding the network which causes the memory pool size to grow tremendously.

As a temporary measure to help mitigate this, a new parameter, --minrelaytxfee, has been added to allow the minimum transaction fee (in BTC/kB) transactions must have before they are allowed to be accepted into the memory and relayed to other nodes to be changed. The default value is 0.00001. Users with memory constrained systems, or who simply desire the memory pool to consume less space, will probably want to raise this to something higher such as 0.00005.

We are aware that this is not the best solution and plans are underway to provide a more robust long-term solution.


Bloom Filter Service Bit Support (BIP0111)
A new service flag which conforms to BIP0111 has been introduced into the peer-to-peer protocol which can be used to signal support for bloom filters. The is accompanied by the protocol version being increased to 70011.

Please note that peers running previous protocol versions that are newer than the version which bloom filters were introduced are assumed to support bloom filters since they were previously required.

To accompany this change, a new --nopeerbloomfilters parameter is now available which can be used to disable support for bloom filters and disable the new service bit accordingly.

A full discussion about why one might or might not want to disable bloom filters is beyond the scope of this post. Suffice it to say there are several issues with them such that many of us in the community would ultimately like to see them replaced. However, it is important to note that the vast majority of SPV implementations currently rely on full nodes having bloom filtering enabled, so we don’t recommend disabling them yet.


New Signature Validation Cache
This release adds a signature cache to the signature validation system which, as the name implies, caches successful signature validations in memory. This typically provides a significant speedup to block processing once the node is fully synced. This is the case because most transactions in new blocks have already been seen and validated by the memory pool and therefore the new blocks can avoid many relatively expensive signature checks by consulting the cache for the ones already known to be valid.

The cache is limited by a configurable number of entries (though future development will likely change this to a target memory size) which is set to 50000 entries by default. A new parameter, --sigcachemaxsize, has been added to allow the cache size to be configured.


Refactored Peer Package
NOTE: This section is aimed more at developers than users, so users may want to skip this section.

This release includes a complete refactoring of the peer code into a peer package which acts a common base for creating and concurrently managing bitcoin network peers. While it doesn’t directly have a huge impact on the current release, we are excited to announce this package because it paves the way for a wide variety of applications that work with the peer-to-peer network. For example, it could be used to easily create robust and more intelligent network seeders, SPV wallets, testing tools, relay nodes, proxies, etc.

As it specifically pertains to btcsuite, btcd has already been updated with this release to use the package. This is significant because it means the peer package will necessarily have to be kept up to date with the latest network and protocol changes that are required by the backbone of the network. Compare this model with having decoupled peer code (such as a 3rd-party library written in Python, node.js, etc) which is for more likely to constantly get out of sync with the latest core network development.


New Options When Querying Address Index
NOTE: This section is aimed more at developers than users, so users may want to skip this section.

The searchrawtransactions RPC which can be used to query the optional address index now include three new parameters:

An optional vinextra parameter which causes the results to include information about the outputs referenced by a transaction inputs
An optional reverse parameter to return the results in reverse order which can be useful in block explorer type of applications
An optional filteraddrs parameter that filters out all transaction inputs and outputs that do not involve the provided addresses. This can significantly reduce the amount of data returned when the transactions involved have a lot of inputs and outputs and your application is only interested in those which involve a specific set of addresses as is typically the case


What’s Under Development?

The following is a quick overview of the major ongoing and future development plans:

Major database restructuring and optimization
We have been keeping a close eye on the performance characteristics of btcd and noticed some areas, particularly in regards to the database, that aren’t scaling as well as we would like. Our goal is to eliminate these bottlenecks.

Add support for concurrent syncing
Currently, all initial block syncing makes use of a single peer. This can lead to wild variance in sync time when the selected sync peer is stalled and/or slow. By making use of multiple peers, the initial sync time can be significantly reduced and other issues related to only having a single sync peer will be eliminated. The peer package introduced in this release was a key piece towards this effort.

Improvements to headers-first syncing
While btcd has already supported headers-first syncing since version 0.5.0-alpha, it currently only uses that mode up until the final checkpoint. Our goal is to extend this capability beyond the final checkpoint.

Refactor the memory pool code into a separate package
The current code which deals with the transaction memory pool is fairly tightly integrated into the main server code. We plan to refactor this out into a separate package which will greatly improve its testability, allow independent benchmarking and profiling, and open up some interesting opportunities for future development related to the memory pool.

Refactor the mining code into a separate package
Much like the memory pool, the current code which deals with providing mining-related functionality, such as generating block templates and creating new blocks, is fairly tightly integrated into the main server and memory pool code. By separating this out into an independent package, many of the same benefits mentioned for the memory pool apply here as well.

Several improvements to the memory pool
The current memory pool is not limited which can lead to it consuming massive amounts of memory. While on the surface it might seem simple to limit it to a specific number of entries, there are several factors that need to taken in account such as priority, fees, dependencies on other transactions, and general fairness to all involved parties.

As many readers following our releases probably have noted, the first three of these were already mentioned in the previous release. They have been repeated here since they are still ongoing and embody the major development efforts.

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1534498677
Hero Member
*
Offline Offline

Posts: 1534498677

View Profile Personal Message (Offline)

Ignore
1534498677
Reply with quote  #2

1534498677
Report to moderator
1534498677
Hero Member
*
Offline Offline

Posts: 1534498677

View Profile Personal Message (Offline)

Ignore
1534498677
Reply with quote  #2

1534498677
Report to moderator
1534498677
Hero Member
*
Offline Offline

Posts: 1534498677

View Profile Personal Message (Offline)

Ignore
1534498677
Reply with quote  #2

1534498677
Report to moderator
Amph
Legendary
*
Offline Offline

Activity: 1960
Merit: 1001



View Profile
November 22, 2015, 06:58:32 PM
 #2

wow, that was fast i was expecting it in a month, at this point it was better to just release this and skip the 0.11.2

Maybe you like to write a lot because of your signature, and this is the reasons that you didn't notice that this isn't Bitcoin Core.

yes you're right but usually those do not belong here, so i was expecting core, and btw has nothing to do with signature, the title simply deceived me

it seems that if you carry a signature you're not permitted to do any error....
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2912
Merit: 1068


I support freedom of choice


View Profile WWW
November 22, 2015, 07:13:11 PM
 #3

Maybe you like to write a lot because of your signature, and this is the reasons that you didn't notice that this isn't Bitcoin Core.

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
Lauda
Legendary
*
Offline Offline

Activity: 1946
Merit: 1570


GUNBOT Licenses -15% with ref. code 'GrumpyKitty'


View Profile WWW
November 22, 2015, 07:17:53 PM
 #4

Maybe you like to write a lot because of your signature, and this is the reasons that you didn't notice that this isn't Bitcoin Core.
Then you've posted in the wrong section and you know it. This is an alternative client. Who are the lead developers of this implementation? They think that they will gain something by releasing the release with the same numbers as the next Core release.   Roll Eyes

.FORTUNE.JACK.
      ▄▄███████▄▄
   ▄████▀▀ ▄ ██████▄
  ████ ▄▄███ ████████
 █████▌▐███▌ ▀▄ ▀█████
███████▄██▀▀▀▀▄████████
█████▀▄▄▄▄█████████████
████▄▄▄▄ █████████████
 ██████▌ ███▀████████
  ███████▄▀▄████████
   ▀█████▀▀███████▀
      ▀▀██████▀▀
         
         █
...FortuneJack.com                                             
...THE BIGGEST BITCOIN GAMBLING SITE
       ▄▄█████████▄▄
    ▄█████████████████▄
  ▄█████████████████████▄
 ▄██
█████████▀███████████▄
██████████▀   ▀██████████
█████████▀       ▀█████████
████████           ████████
████████▄   ▄ ▄   ▄████████
██████████▀   ▀██████████
 ▀██
█████████████████████▀
  ▀██
███████████████████▀
    ▀█████████████████▀
       ▀▀█████████▀▀
#JACKMATE
WIN 1 BTC
▄█████████████████████████▄
███████████████████████████
███████████████████████████
██████████▀█████▀██████████
███████▀░░▀░░░░░▀░░▀███████
██████▌░░░░░░░░░░░░░▐██████
██████░░░░██░░░██░░░░██████
█████▌░░░░▀▀░░░▀▀░░░░▐█████
██████▄░░▄▄▄░░░▄▄▄░░▄██████
████████▄▄███████▄▄████████

███████████████████████████
███████████████████████████
▀█████████████████████████▀
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
November 22, 2015, 07:21:17 PM
 #5

Ha, ha! Too funny! I need to preserve this exchange.

wow, that was fast i was expecting it in a month, at this point it was better to just release this and skip the 0.11.2
Maybe you like to write a lot because of your signature, and this is the reasons that you didn't notice that this isn't Bitcoin Core.
Then you've posted in the wrong section and you know it. This is an alternative client. Who are the lead developers of this implementation? They think that they will gain something by releasing the release with the same numbers as the next Core release.   Roll Eyes

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2912
Merit: 1068


I support freedom of choice


View Profile WWW
November 22, 2015, 07:21:44 PM
 #6

Who are the lead developers of this implementation?
https://github.com/btcsuite/btcd/graphs/contributors

They think that they will gain something by releasing the release with the same numbers as the next Core release.   Roll Eyes
Maybe there will be already another release of this full node at the time of the 0.12.0 of the core.


@2112
Maybe "Alternative fullnode bitcoin implementation in Go" wasn't clear enough Roll Eyes

@Lauda
By my thoughts I think that this should be sticked as the one of the Bitcoin Core, but I know, I'm too old here Roll Eyes

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
LiteCoinGuy
Legendary
*
Offline Offline

Activity: 1148
Merit: 1001


In Satoshi I Trust


View Profile WWW
November 22, 2015, 09:09:42 PM
 #7

that is an altcoin! ban him!

/s

Carlton Banks
Legendary
*
Offline Offline

Activity: 2086
Merit: 1315



View Profile
November 22, 2015, 09:41:45 PM
 #8

Then you've posted in the wrong section and you know it.

It's kind of a harsh policy, but to be fair, bitcointalk mods are at least consistent: all threads about alternative clients are in their own sub, it was that layout/policy when I joined up 3 years ago.

Vires in numeris
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
November 23, 2015, 01:59:58 AM
 #9

I keep trying to laugh at this. Reading bitcointalk.org is very much like reading some theological discussions.

Around 2012 bitcointalk.org was at split between monocoinists and polycoinists.

https://bitcointalk.org/index.php?topic=56912.0

Right now bitcointalk.org is undergoing the further split of monocoinists into at least three doctrinal branches:

1) Catholic Bitcoiners
2) Protestant Bitcoiners
3) Eastern Orthodox Bitcoiners (led by Mircea Popescu in Romania)

What we are observing here is the conflict about the "canon" of Bitcoin, roughly equivalent to the 16th century splits in Christianity:

https://en.wikipedia.org/wiki/Deuterocanonical_books
https://en.wikipedia.org/wiki/Index_Librorum_Prohibitorum

Who are the lead developers of this implementation?
https://github.com/btcsuite/btcd/graphs/contributors

They think that they will gain something by releasing the release with the same numbers as the next Core release.   Roll Eyes
Maybe there will be already another release of this full node at the time of the 0.12.0 of the core.


@2112
Maybe "Alternative fullnode bitcoin implementation in Go" wasn't clear enough Roll Eyes

@Lauda
By my thoughts I think that this should be sticked as the one of the Bitcoin Core, but I know, I'm too old here Roll Eyes
Then you've posted in the wrong section and you know it.

It's kind of a harsh policy, but to be fair, bitcointalk mods are at least consistent: all threads about alternative clients are in their own sub, it was that layout/policy when I joined up 3 years ago.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Pages: [1]
  Print  
 
Jump to:  

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!