Bitcoin Mining Pool Bitcoin.com

Gridcoin 5.0.0.0-Mandatory "Fern" Release

https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/5.0.0.0
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.

Highlights

Protocol

Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.

GUI

Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.

Blockchain

The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog

Accrual

Changed

Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.

Removed

Beacons

Added

Changed

Removed

Unaltered

As a reminder:

Superblocks

Added

Changed

Removed

Voting

Added

Changed

Removed

Detailed Changelog

[5.0.0.0] 2020-09-03, mandatory, "Fern"

Added

Changed

Removed

Fixed

submitted by jamescowens to gridcoin [link] [comments]

Technical: The Path to Taproot Activation

Taproot! Everybody wants to have it, somebody wants to make it, nobody knows how to get it!
(If you are asking why everybody wants it, see: Technical: Taproot: Why Activate?)
(Pedants: I mostly elide over lockin times)
Briefly, Taproot is that neat new thing that gets us:
So yes, let's activate taproot!

The SegWit Wars

The biggest problem with activating Taproot is PTSD from the previous softfork, SegWit. Pieter Wuille, one of the authors of the current Taproot proposal, has consistently held the position that he will not discuss activation, and will accept whatever activation process is imposed on Taproot. Other developers have expressed similar opinions.
So what happened with SegWit activation that was so traumatic? SegWit used the BIP9 activation method. Let's dive into BIP9!

BIP9 Miner-Activated Soft Fork

Basically, BIP9 has a bunch of parameters:
Now there are other parameters (name, starttime) but they are not anywhere near as important as the above two.
A number that is not a parameter, is 95%. Basically, activation of a BIP9 softfork is considered as actually succeeding if at least 95% of blocks in the last 2 weeks had the specified bit in the nVersion set. If less than 95% had this bit set before the timeout, then the upgrade fails and never goes into the network. This is not a parameter: it is a constant defined by BIP9, and developers using BIP9 activation cannot change this.
So, first some simple questions and their answers:

The Great Battles of the SegWit Wars

SegWit not only fixed transaction malleability, it also created a practical softforkable blocksize increase that also rebalanced weights so that the cost of spending a UTXO is about the same as the cost of creating UTXOs (and spending UTXOs is "better" since it limits the size of the UTXO set that every fullnode has to maintain).
So SegWit was written, the activation was decided to be BIP9, and then.... miner signalling stalled at below 75%.
Thus were the Great SegWit Wars started.

BIP9 Feature Hostage

If you are a miner with at least 5% global hashpower, you can hold a BIP9-activated softfork hostage.
You might even secretly want the softfork to actually push through. But you might want to extract concession from the users and the developers. Like removing the halvening. Or raising or even removing the block size caps (which helps larger miners more than smaller miners, making it easier to become a bigger fish that eats all the smaller fishes). Or whatever.
With BIP9, you can hold the softfork hostage. You just hold out and refuse to signal. You tell everyone you will signal, if and only if certain concessions are given to you.
This ability by miners to hold a feature hostage was enabled because of the miner-exit allowed by the timeout on BIP9. Prior to that, miners were considered little more than expendable security guards, paid for the risk they take to secure the network, but not special in the grand scheme of Bitcoin.

Covert ASICBoost

ASICBoost was a novel way of optimizing SHA256 mining, by taking advantage of the structure of the 80-byte header that is hashed in order to perform proof-of-work. The details of ASICBoost are out-of-scope here but you can read about it elsewhere
Here is a short summary of the two types of ASICBoost, relevant to the activation discussion.
Now, "overt" means "obvious", while "covert" means hidden. Overt ASICBoost is obvious because nVersion bits that are not currently in use for BIP9 activations are usually 0 by default, so setting those bits to 1 makes it obvious that you are doing something weird (namely, Overt ASICBoost). Covert ASICBoost is non-obvious because the order of transactions in a block are up to the miner anyway, so the miner rearranging the transactions in order to get lower power consumption is not going to be detected.
Unfortunately, while Overt ASICBoost was compatible with SegWit, Covert ASICBoost was not. This is because, pre-SegWit, only the block header Merkle tree committed to the transaction ordering. However, with SegWit, another Merkle tree exists, which commits to transaction ordering as well. Covert ASICBoost would require more computation to manipulate two Merkle trees, obviating the power benefits of Covert ASICBoost anyway.
Now, miners want to use ASICBoost (indeed, about 60->70% of current miners probably use the Overt ASICBoost nowadays; if you have a Bitcoin fullnode running you will see the logs with lots of "60 of last 100 blocks had unexpected versions" which is exactly what you would see with the nVersion manipulation that Overt ASICBoost does). But remember: ASICBoost was, at around the time, a novel improvement. Not all miners had ASICBoost hardware. Those who did, did not want it known that they had ASICBoost hardware, and wanted to do Covert ASICBoost!
But Covert ASICBoost is incompatible with SegWit, because SegWit actually has two Merkle trees of transaction data, and Covert ASICBoost works by fudging around with transaction ordering in a block, and recomputing two Merkle Trees is more expensive than recomputing just one (and loses the ASICBoost advantage).
Of course, those miners that wanted Covert ASICBoost did not want to openly admit that they had ASICBoost hardware, they wanted to keep their advantage secret because miners are strongly competitive in a very tight market. And doing ASICBoost Covertly was just the ticket, but they could not work post-SegWit.
Fortunately, due to the BIP9 activation process, they could hold SegWit hostage while covertly taking advantage of Covert ASICBoost!

UASF: BIP148 and BIP8

When the incompatibility between Covert ASICBoost and SegWit was realized, still, activation of SegWit stalled, and miners were still not openly claiming that ASICBoost was related to non-activation of SegWit.
Eventually, a new proposal was created: BIP148. With this rule, 3 months before the end of the SegWit timeout, nodes would reject blocks that did not signal SegWit. Thus, 3 months before SegWit timeout, BIP148 would force activation of SegWit.
This proposal was not accepted by Bitcoin Core, due to the shortening of the timeout (it effectively times out 3 months before the initial SegWit timeout). Instead, a fork of Bitcoin Core was created which added the patch to comply with BIP148. This was claimed as a User Activated Soft Fork, UASF, since users could freely download the alternate fork rather than sticking with the developers of Bitcoin Core.
Now, BIP148 effectively is just a BIP9 activation, except at its (earlier) timeout, the new rules would be activated anyway (instead of the BIP9-mandated behavior that the upgrade is cancelled at the end of the timeout).
BIP148 was actually inspired by the BIP8 proposal (the link here is a historical version; BIP8 has been updated recently, precisely in preparation for Taproot activation). BIP8 is basically BIP9, but at the end of timeout, the softfork is activated anyway rather than cancelled.
This removed the ability of miners to hold the softfork hostage. At best, they can delay the activation, but not stop it entirely by holding out as in BIP9.
Of course, this implies risk that not all miners have upgraded before activation, leading to possible losses for SPV users, as well as again re-pressuring miners to signal activation, possibly without the miners actually upgrading their software to properly impose the new softfork rules.

BIP91, SegWit2X, and The Aftermath

BIP148 inspired countermeasures, possibly from the Covert ASiCBoost miners, possibly from concerned users who wanted to offer concessions to miners. To this day, the common name for BIP148 - UASF - remains an emotionally-charged rallying cry for parts of the Bitcoin community.
One of these was SegWit2X. This was brokered in a deal between some Bitcoin personalities at a conference in New York, and thus part of the so-called "New York Agreement" or NYA, another emotionally-charged acronym.
The text of the NYA was basically:
  1. Set up a new activation threshold at 80% signalled at bit 4 (vs bit 1 for SegWit).
    • When this 80% signalling was reached, miners would require that bit 1 for SegWit be signalled to achive the 95% activation needed for SegWit.
  2. If the bit 4 signalling reached 80%, increase the block weight limit from the SegWit 4000000 to the SegWit2X 8000000, 6 months after bit 1 activation.
The first item above was coded in BIP91.
Unfortunately, if you read the BIP91, independently of NYA, you might come to the conclusion that BIP91 was only about lowering the threshold to 80%. In particular, BIP91 never mentions anything about the second point above, it never mentions that bit 4 80% threshold would also signal for a later hardfork increase in weight limit.
Because of this, even though there are claims that NYA (SegWit2X) reached 80% dominance, a close reading of BIP91 shows that the 80% dominance was only for SegWit activation, without necessarily a later 2x capacity hardfork (SegWit2X).
This ambiguity of bit 4 (NYA says it includes a 2x capacity hardfork, BIP91 says it does not) has continued to be a thorn in blocksize debates later. Economically speaking, Bitcoin futures between SegWit and SegWit2X showed strong economic dominance in favor of SegWit (SegWit2X futures were traded at a fraction in value of SegWit futures: I personally made a tidy but small amount of money betting against SegWit2X in the futures market), so suggesting that NYA achieved 80% dominance even in mining is laughable, but the NYA text that ties bit 4 to SegWit2X still exists.
Historically, BIP91 triggered which caused SegWit to activate before the BIP148 shorter timeout. BIP148 proponents continue to hold this day that it was the BIP148 shorter timeout and no-compromises-activate-on-August-1 that made miners flock to BIP91 as a face-saving tactic that actually removed the second clause of NYA. NYA supporters keep pointing to the bit 4 text in the NYA and the historical activation of BIP91 as a failed promise by Bitcoin developers.

Taproot Activation Proposals

There are two primary proposals I can see for Taproot activation:
  1. BIP8.
  2. Modern Softfork Activation.
We have discussed BIP8: roughly, it has bit and timeout, if 95% of miners signal bit it activates, at the end of timeout it activates. (EDIT: BIP8 has had recent updates: at the end of timeout it can now activate or fail. For the most part, in the below text "BIP8", means BIP8-and-activate-at-timeout, and "BIP9" means BIP8-and-fail-at-timeout)
So let's take a look at Modern Softfork Activation!

Modern Softfork Activation

This is a more complex activation method, composed of BIP9 and BIP8 as supcomponents.
  1. First have a 12-month BIP9 (fail at timeout).
  2. If the above fails to activate, have a 6-month discussion period during which users and developers and miners discuss whether to continue to step 3.
  3. Have a 24-month BIP8 (activate at timeout).
The total above is 42 months, if you are counting: 3.5 years worst-case activation.
The logic here is that if there are no problems, BIP9 will work just fine anyway. And if there are problems, the 6-month period should weed it out. Finally, miners cannot hold the feature hostage since the 24-month BIP8 period will exist anyway.

PSA: Being Resilient to Upgrades

Software is very birttle.
Anyone who has been using software for a long time has experienced something like this:
  1. You hear a new version of your favorite software has a nice new feature.
  2. Excited, you install the new version.
  3. You find that the new version has subtle incompatibilities with your current workflow.
  4. You are sad and downgrade to the older version.
  5. You find out that the new version has changed your files in incompatible ways that the old version cannot work with anymore.
  6. You tearfully reinstall the newer version and figure out how to get your lost productivity now that you have to adapt to a new workflow
If you are a technically-competent user, you might codify your workflow into a bunch of programs. And then you upgrade one of the external pieces of software you are using, and find that it has a subtle incompatibility with your current workflow which is based on a bunch of simple programs you wrote yourself. And if those simple programs are used as the basis of some important production system, you hve just screwed up because you upgraded software on an important production system.
And well, one of the issues with new softfork activation is that if not enough people (users and miners) upgrade to the newest Bitcoin software, the security of the new softfork rules are at risk.
Upgrading software of any kind is always a risk, and the more software you build on top of the software-being-upgraded, the greater you risk your tower of software collapsing while you change its foundations.
So if you have some complex Bitcoin-manipulating system with Bitcoin somewhere at the foundations, consider running two Bitcoin nodes:
  1. One is a "stable-version" Bitcoin node. Once it has synced, set it up to connect=x.x.x.x to the second node below (so that your ISP bandwidth is only spent on the second node). Use this node to run all your software: it's a stable version that you don't change for long periods of time. Enable txiindex, disable pruning, whatever your software needs.
  2. The other is an "always-up-to-date" Bitcoin Node. Keep its stoarge down with pruning (initially sync it off the "stable-version" node). You can't use blocksonly if your "stable-version" node needs to send transactions, but otherwise this "always-up-to-date" Bitcoin node can be kept as a low-resource node, so you can run both nodes in the same machine.
When a new Bitcoin version comes up, you just upgrade the "always-up-to-date" Bitcoin node. This protects you if a future softfork activates, you will only receive valid Bitcoin blocks and transactions. Since this node has nothing running on top of it, it is just a special peer of the "stable-version" node, any software incompatibilities with your system software do not exist.
Your "stable-version" Bitcoin node remains the same version until you are ready to actually upgrade this node and are prepared to rewrite most of the software you have running on top of it due to version compatibility problems.
When upgrading the "always-up-to-date", you can bring it down safely and then start it later. Your "stable-version" wil keep running, disconnected from the network, but otherwise still available for whatever queries. You do need some system to stop the "always-up-to-date" node if for any reason the "stable-version" goes down (otherwisee if the "always-up-to-date" advances its pruning window past what your "stable-version" has, the "stable-version" cannot sync afterwards), but if you are technically competent enough that you need to do this, you are technically competent enough to write such a trivial monitor program (EDIT: gmax notes you can adjust the pruning window by RPC commands to help with this as well).
This recommendation is from gmaxwell on IRC, by the way.
submitted by almkglor to Bitcoin [link] [comments]

hodlmon.sh: a UTXO monitoring methodology and script for true connoisseurs of security, paranoia and BTC maximalism

EDIT:
Disclaimer: the below script is provided for example purposes only. You're responsible for your own security. Don't trust, verify.
tldr: the script is literally just an example wrapper to call "gettxout" on your own node via cron to check if your own utxo has been spent yet
OK, since there are a few questions on security below, let me clarify: this script is only for people who are 1) already running their own nodes and 2) can understand the bash script below. And obviously, don't trust some random person on the internet, always verify. I provided this as an example for a way to monitor your own UTXOs with your existing node. Those of you who understand what the below script does will see it's painfully simple and obviously harmless. Those of you who don't understand it, just ignore this post, or better yet, research what the below means until you do understand it. What's important is the idea of monitoring your own UTXO, and this script is an example of how to do that with gettxout.
ORIGINAL POST:
Submitting this to help strengthen the community, and for review:
hodlmon.sh: a UTXO monitoring methodology and script for true connoisseurs of security, paranoia and BTC maximalism
Monitor canary UTXOs for early detection of compromised private keys BEFORE funds are lost, using your own full node for maximum privacy and trustlessness. Note that you will need to implement your own notification strategy (email, push, sms, etc). This script is intended to run on your full node, but can be run from any machine with RPC access to your full node.
hodlmon.sh is designed to check if a given UTXO (i.e. a specific output of a specific btc transaction) has been spent or not. This can be used for early and proactive detection if a seed phrase or private key has been compromised, so you have time to move your btc before full compromise happens. In order for this to work, a small amount of btc should be sent to an address controlled only by a given seedphrase, with that seedphrase being part of a multisig wallet or a seedphrase+passphrase wallet, and the majority of your funds controlled in the seedphrase+passphrase or multisig wallet. The idea is to leave the small amount of btc (the canary utxo) in the address, so that it never moves unless the seedphrase that controls it has been compromised and all funds in the wallet swept. In this way, you use those compromised sats to buy information about the current security status of your wallet(s).
Example usage:Set up a cron job to run hodlmon.sh every 30 min to check if transaction output at index "0" for transaction with id "123" has been spent already. Use "my_utxo_nickname" as a friendly name for the UTXO (to differentiate between multiple wallets)
*/30 * * * * /path/to/hodlmon.sh 123 0 my_utxo_nickname > /tmp/hodlmon_log 2> /tmp/hodlmon_err_log
Usage scenario #1: Seedphrase (A) + passphrase (A')Majority of funds are held in a wallet controlled by both the seedphrase and passphrase, A and A'. A token amount of btc is controlled only by seedphrase A.
A + A': majority of funds
A: canary UTXO
hodlmon.sh is used to monitor the canary funds locked by A, so that if it is discovered that A has been compromised, the funds locked by A and A' can be moved to a new wallet before the passphrase A' can be cracked and all your funds exfiltrated.
Usage scenario #2: multisig e.g. 2 of 3, with seed phrases A, B and CMajority of funds held in a multisig wallet controlled by 3 seedphrases A, B, and C. 3 small canary UTXOs are held in wallets each controlled by A, B or C, respectively.
A + B + C: majority of funds
A: canary UTXO 1
B: canary UTXO 2
C: canary UTXO 3
One benefit of multisig (e.g. 2 of 3) is that even if 1 key is compromised, your funds are safe, since at least 2 keys are needed to release funds. But how do you that none of the keys has yet been compromised? If you create separate wallets controlled each by only 1 of the individual keys, and use hodlmon.sh to monitor whether those UTXOs have been exfiltrated, then you can detect partial compromise of your setup before a full exfiltration event takes place, so you can move your funds to a new multisig wallet with freshly generated and uncompromised keys.
Example of 3 cronjobs to monitor all 3 canary UTXOs:
*/30 * * * * /path/to/hodlmon.sh 123 0 key1 > /tmp/hodlmon_log_1 2> /tmp/hodlmon_err_log_1
*/30 * * * * /path/to/hodlmon.sh 456 0 key2 > /tmp/hodlmon_log_2 2> /tmp/hodlmon_err_log_2
*/30 * * * * /path/to/hodlmon.sh 789 0 key3 > /tmp/hodlmon_log_3 2> /tmp/hodlmon_err_log_3
​
Example hodlmon script:
#########################################################################
#!/bin/bash
touch /tmp/hodlmon_last_run
echo "Transaction ID: $1"
echo "Output #: $2"
echo "Nickname: $3"
NODE_IP=127.0.0.1 #TODO: use actual value
USER=user#TODO: use actual value
PASS=pass #TODO: use actual value
PORT=8332 #TODO: use actual value
CHECK_CMD="/uslocal/bin/bitcoin-cli -rpcconnect=$NODE_IP -rpcuser=$USER -rpcpassword=$PASS -rpcport=$PORT gettxout $1 $2"
RESULT="$($CHECK_CMD)"
echo "${RESULT}"
if [ "$RESULT" == "" ]
then
echo "UTXO HAS BEEN SPENT! RED ALERT!!"
MSG="The UTXO for $3 from tx $1 output $2 has moved!"
#TODO: ADD YOUR FAVORITE NOTIFICATION STRATEGY E.G. EMAIL, PUSH NOTIFICATION, SMS
else
echo "UTXO is still on ice"
fi
############################################
​
submitted by facepalm5000 to Bitcoin [link] [comments]

What naming convention should I use for a JSON RPC client API designed for multiple languages?

This is the documentation with the original RPC client API specification. The naming convention in the specification is camel case.
Naming conventions might differ in subtle ways for different languages (camel case vs. pascal case), but for some conventions like snake case (Python) or Swift's Fluent Usage API changing the names in the original specification might increase the cognitive load when using the API for those already familiar with the specification.
When searching for different JSON RPC APIs on GitHub, some implementations seem to take advantage of reflection to intercept method calls and pass them to RPC request "as is" so method names for that language are the same as in the original spec. If reflection is not available the names are hardcoded and are mostly the same as the spec, changing only the capitalization of letters for some languages.
Some examples:
Not using Fluent Design in Swift
https://github.com/fanquake/CoreRPC/blob/masteSources/CoreRPC/Blockchain.swift https://github.com/brunophilipe/SwiftRPC/blob/masteSwiftRPC/SwiftRPC+Requests.swift
Not using snake case in Ruby
https://github.com/sinisterchipmunk/bitcoin-client/blob/mastelib/bitcoin-client/client.rb
Changing method names to pascal case in C#
https://github.com/cryptean/bitcoinlib/blob/mastesrc/BitcoinLib/Services/RpcServices/RpcService/RpcService.cs
submitted by rraallvv to learnprogramming [link] [comments]

How to verify if a transaction is correctly signed?

Given an arbitrary signed raw transaction, how can we easily verify if all inputs are correctly signed (admiting all UTXOs are present and fee is higher than zero)? I know there is an RPC command in bitcoin core testmempoolaccept but this will also check if all inputs are available to be spent in the mempool/blockchain and I want to test a transaction that is a child to a parent transaction that has not yet been broadcasted.
The signed transaction instance could have the scriptPubKey of the used utxos stored as metadata (since it needs to know these to sign each input) and use the stored utxos to perform this validation - alternatively, the verification method could ask for the scriptPubKeys of the utxos as input. I was looking for some nice way to do this in python but was surprised how neglected this task is:
EDIT: converting to PSBT is not possible/easy so the last option I mentioned won't work. I have the transactions in serialized 'network' format (what you get from `bitcoin-cli getrawtransaction hex')
EDIT2: escalated to bitcoin stack exchange: https://bitcoin.stackexchange.com/questions/96759/how-to-verify-if-a-transaction-is-correctly-signed
submitted by johnturtle to BitcoinBeginners [link] [comments]

RiB Newsletter #14 – Are We Smart (Contract) Yet?

We’re seeing a bunch of interesting Rust blockchain and crypto projects, so this month the “Interesting Things” section is loaded up with news, papers, and project links.
This month, Elrond, appeared on our radar with the launch of their mainnet. Although not written in Rust, it runs Rust smart contracts on its Arwen WASM VM, which itself is based on the Rust Wasmer VM. Along with NEAR, Nervos, and Enigma (and probably others), this continues an encouraging trend of blockchains enabling smart contracts in Rust. See the “Interesting Things” section for examples of Elrond’s Rust contracts.
Rust continues to be popular for research into zero-knowledge proofs, with Microsoft releasing Spartan, a zk-SNARK system without trusted setup.
In RiB news, we published a late one-year anniversary blog post. It has some reflection on the changes to, and growth of, RiB over the last year.
The Awesome Blockchain Rust project, which is maintained by Sun under the rust-in-blockchain GitHub org, has received a stream of updates recently, and is now published as the Awesome-RiB page on rustinblockchain.org.
It’s a pretty good resource for finding blockchain-related Rust projects, with links to many of the more prominent and mature projects noted in the RiB newsletter. It could use more eyes on it though.
​

Project Spotlight

Each month we like to shine a light on a notable Rust blockchain project. This month that project is…
ethers.rs
ethers.rs is an Ethereum & Celo library and wallet implementation, implemented as a port of the ethers.js library to Rust.
Ethereum client programming is usually done in JavaScript with either web3.js or ethers.js, with ethers.js being the newer of the two. These clients communicate to an Ethereum node, typically via JSON-RPC (or, when in the browser, via an “injected” client provider that follows EIP-1193, like MetaMask).
ethers.rs then provides a strongly-typed alternative for writing software that interacts with the Ethereum network.
As of now it is only suited for non-browser use cases, but if you prefer hacking in Rust to JavaScript, as some of us surely do, it is worth looking into for your next Ethereum project.
The author of ethers.rs, Georgios Konstantopoulos, accepts donations to sponsor their work.
Note that there is also a Rust alternative to web3.js, rust-web3.

Interesting Things

News

Blog Posts

Papers

Projects

Podcasts and Videos

​
Read more: https://rustinblockchain.org/newsletters/2020-08-05-are-we-smart-contract-yet/
submitted by Aimeedeer to rust [link] [comments]

Deep fundamental reasons behind all conflicts with Tezos Foundation

Let's first take a look at two core ideas behind Tezos protocol:
  1. In Bitcoin protocol, there are those who create blocks (miners) and users. Those are two fundamentally different groups. As a result of that they do have fundamentally different interests. When those interests are aligned, it's all work very well. However, sometimes those interests might get misaligned. Miners might want one set of changes in the protocol while users might want another set of changes. Tezos procotol solves this problem via proof of stake's baking mechanism by allowing users of XTZ to become block creators (like miners in Bitcoin protocol). Users/holders of XTZ and block creators are now fundamentally the same group and therefore there is no interest misalignment. Moreover, as a consequence of choosing proof of stake over proof of work, almost anyone can become a baker at low cost. Of course, there is a minimum requirement but it can be easily reduced through voting if price XTZ goes too high;
  2. Although per (1) problem of misalignment between users and miners solved, Tezos protocol make one step further. Namely, there is self-amending mechanisms in protocol. Through of the set of voting rounds, attached bounties (via dillution), there is a deterministic path to resolve disputes in upgrading Tezos protocol. Nobody knows the future, nobody knows how protocol should look like after 5-10-20 years. That's why it's very important to have self-amending procedure. Without deterministic path to protocol upgrade, you will have fork-wars like in Bitcoin. As a result of these fork-wars, you now have Bitcoin, Bitcoin Cash, Bitcoin SV. Also, with built-in bounties via dillution, Tezos protocol guarantees funding for its further development;
There is third core idea behind Tezos protocol. Namely, formal verification friendly, low-level and explicit smart contract language - Michelson. While it's very important feature, it's not relevant for this discussion.
Now imagine you are going back in time when Tezos protocol isn't implemented yet, only draft whitepaper. How would you bring it to life if you were original author?
If there were no crypto-currencies, then all you have to do is to take time and implement minimum viable product (MVP) on your own. May be you might do it with co-founder but it's not really necessary for releasing the first version of protocol in absence of any competition.
However, the field was already crowded and time works against you. It would be necessary for project's survival to be as fast as possible in such dynamic field. You need to raise funds to hire dozen of strong programmers to implement Tezos protocol and on top of that to fund development of ecosystem in Tezos network. Namely, wallets, higher-level languages on top of low-level Michelson, education materials for future smart contract writers, new projects similar to 0x, Maker, Compound, Cryptokitties etc.
Now, I would like you to make a pause and think what is Tezos protocol. It tries to align incentives of parties using game-theoretic constructs! And now, I would like you to make second pause and think what crypto-currencies are all about in broader sense. Crypto-currencies are about eliminating centralization and unnecessary middle-mans. One of the biggest middle-mans is governments and their legal system.
People who are in the space for long time should know how much crypto-currencies influenced by Austrian School of Economics (read Hayek's book "Denationalization Of Money" (1976) and early Satoshi Nakamoto's posts).
With that in mind (spirit behind Tezos and crypto-currencies in general), how would you fund development of Tezos protocol and later its initial ecosystem?
The correct answer is to setup decentralized autonomus organization (DAO). Initial DAO on Ethereum protocol since you don't have any Tezos protocol implementations (remember, we are still back in time!).
This DAO will be used to develop Tezos protocol itself and leverage power of smart contracts to correctly align incentives for development of Tezos protocol. Namely, backers of this DAO would get ERC20 token representing voting and governance power. For example, let's say founders raised 250M USD worth in ETH and all of these money will be locked in smart contract. Only backers can unlock funds from smart contract by tranches as Tezos protocol developers making progress. It would be similar to traditional world - seed round, round A, round B etc. When Tezos mainnet goes live, backers would receive proportional amount of XTZ as their ERC20 voting tokens on Ethereum. Since that initial DAO would still have tons of ETH locked by the time Tezos mainnet released, those proceeds will be used to fund wallet developers, high-language developers, and so on (via voting by backers of course).
In this scenario, I would envision that the first big project after Tezos mainnet launched would be to build trustless, decentralized bridge between Tezos blockchain and Ethereum blockchain. Simply, because it would be good to migrate intial DAO and its ETH funds into Tezos blockchain.
There are only two downsides with this approach:
  1. You can't raise funds in Bitcoin but who cares if it's 100M or even 50M (still huge amount of money);
  2. Many people in crypto-space will make fun of you because you just setup DAO on Ethereum while developing Ethereum competitor;
Neither of these two downsides is important. Ultimate upside is that backers has direct control over how funds are spent because they would be the only ones who can unlock funds by voting for proposals.
On meta-level, you would have beautiful symmetry. Namely, you develop Tezos protocol and its ecosystem, using the similar ideas and spirit as Tezos protocol itself!
But we all know that it was never happened!
We all know drama with Gevers who tried to capture power at Tezos Foundation. We all know that there is no RPC command in Tezos github to vote out Tezos Foundation members ;) We all know that we are not in control of Tezos Foundation. Tezos Foundation is a swiss non-profit organization with its own board and we are not part of it. Tezos Foundation is govern under Swiss law and most of you are not even Swiss citizens.
Here is the question why Breitmans suddently decided to throw away all fundamental principles behind crypto-currencies and just went all-in with traditional world? Why we all got stuck with our own mini-Washington, namely Tezos Foundation? There is one reason why Breitmans decided to throw away all their principles and stick with this strange scheme involving Swiss foundations.
The reason is ... socialism. You might think I'm joking but stay with me. There were roaring 1920s and following 1929 stock market crash (by the way that was actually caused by government creating credit bubble). Republican (but still a socialist) Herbert Hoover created depression from 1929 crash. Franklin Roosevelt made this depression truly great! He imposed price-controls and outright gold confiscation (check "Executive Order 6102"). One of his most terrible pieces of paternalistic socialist legislation was "Securities Act of 1933". And this is the reason why Breitmans tried so hard escape iron hand of Roosevelt's zombie.
The same month as Tezos fundraiser, SEC issued statement about the most famous Ethereum DAO:
https://www.sec.gov/news/press-release/2017-131
https://www.sec.gov/litigation/investreport/34-81207.pdf
Basically, they tried to say that DAO violated their 1933 Securities Act (aka Roosevelt zombie). I'm not claiming that Breitmans anticipated this exact SEC statement about Ethereum DAO. All I'm saying that they are smart enough to understand that SEC might come after them as well. It doesn't matter if SEC had right to do so. It doesn't matter that XTZ is not security at all. Only people outside of hardcore old school crypto-community would believe in such non-sense as rights. The truth is that any government is essentially an army which controls a territory and they (not you!) decide what they think is right or wrong.
Breitmans knew that SEC might chase them with bloody machete, so they decided to play traditional game which many played when Switzerland still had numbered accounts. Namely, using Switzerland as old-style traditional escape from Roosevelt zombies.
Unfortunately, for them they got in hands of people who knew too well how actually Swiss foundations work. We all remember how Gevers tried to exploit Swiss law about foundations to seize control over foundation's assets. Now we have new drama. But fundamentally, it's all because Breitmans choose Swiss law over Ethereum smart-contracts.
Don't get me wrong, I'm not blaming Breitmans. I really think that their fear of Roosevelt zombie with bloody machete led them to setup weird foundation in Switzerland. In normal circumstances, I don't see any rational reason not to setup DAO as I described above.
Zooming out, on the bigger scale, you might see that these two worlds (i.e. traditional government law and crypto) are not compatible at all. You just can't have both of two worlds.
For the same reason, I don't believe in STOs. It's a nice toy, a temporary thing to bootstrap your Defi ecosystem in Tezos but nothing more than that.
Every STO, at some point, rely on some centralized entity which is controlled by law of some jurisdiction. Once government (aka army which control territories and make visibility of its own legitimacy via elections and passing laws) decides that your STO is not compliant, all these STO tokens will be worthless overnight. More on this in my another long post:
https://www.reddit.com/MakerDAO/comments/de0sys/kyc_is_absolutely_not_acceptable_for_makerdao/
Regardless of what's happen with Tezos Foundation, I strongly believe that Tezos protocol will thrive. Mainnet went life and the jinn that can't be put back in the bottle!
Update: Many here criticized my position regarding STOs. That's partly my fault with being too lax with terminology (once I wrote big post, I didn't have much energy to clarify on STOs in the end). By STO, I mean any tokens backed by regulated assets (again, I know it's lax definition). I assumed almost everyone here is for open, borderless finance. As a result of that, I assumed that you want to make these tokens available for everyone and that's why one day government will put pressure on such STO issuers to freeze tokens. However, it's turned out that some people excited for STOs being fully regulated from the start and therefore these tokens wouldn't be available for everyone. Basically, some people see main benefits of STOs as being pro-actively censorship friendly. In other words, they want to move all compliance on blockchain. Whereas, I see very existence of government regulations as root of all problems. Having said that, I'm not against STOs but I'm not very excited about them either. You have to make great mental leap to understand that fully-regulated STOs fundamentally solving wrong problem. You have to build fully censorship resistant technology, not fully censorship friendly. No matter how big market for STOs, it's still several orders of magnitude smaller than potential world of fully-inclusive finance without any borders whatsoever. Tezos is very well equipped for this ambitious task especially with new privacy features coming. Remember, Satoshi Nakamoto didn't ask permission from governments before releasing Bitcoin.
submitted by omgcoin to tezos [link] [comments]

Adding Monero support to a P2P game, need some advice

Hello everyone,
I'm currently in the process of adding Monero support to a peer-to-peer game I've been working on and would like to ask this community for some advice.
The application has a few hard requirements that must be met:
  1. The Monero integration must be done using JavaScript (primarily for Node but browser's okay too).
  2. The application must be able to create addresses and accompanying private keys internally (no CLI or external API). Preferably, these should be derived addresses using a master or main one (like HD wallets in Bitcoin).
  3. The application must be able to generate raw transactions internally -- no CLI or or external API. For this part let's assume that the input UTXOs are going to be available somehow (from a database, for example).
  4. The application must be able to sign raw transactions internally -- no CLI or or external API.
When I say "no CLI", I mean no RPC wallet or daemon; no external API calls either.
Essentially, I should be able to do the above offline, using JavaScript only, and then just post the signed transactions later (this part can be done via CLI or API). These are core requirements for the project otherwise I'd just use RPC or a service and save myself a lot of work.
So my question is: is there a documented JavaScript library that supports all of the above functionality?
I found a project called mymonero-core-js which appears to do what I'd need, but there doesn't seem to be any accompanying documentation (the included unit tests don't offer much information). Does this documentation exist?
There's also an offline wallet generator but it's also undocumented and kinda unwieldy (one huge file).
The game (my project), already supports Bitcoin and Bitcoin Cash using these constraints, and I've done fairly extensive work with Ethereum, smart contracts, and crypto in general (not just cryptocurrencies, I mean), so I shouldn't need much hand-holding.
Thanks muchly in advance!
P.S. It's not my intention to advertise my project so I haven't posted a link but I'll be happy to share if anyone asks.
submitted by monican_agent to Monero [link] [comments]

Wasabi Wallet v1.1.11

https://github.com/zkSNACKs/WalletWasabi/releases
Summary
This major release is the culmination of several efforts that have been a work in progress for a long time.
submitted by yahiheb to Bitcoin [link] [comments]

Wasabi Wallet v1.1.11

https://github.com/zkSNACKs/WalletWasabi/releases

Summary

This major release is the culmination of several efforts that have been a work in progress for a long time.
submitted by yahiheb to WasabiWallet [link] [comments]

Need a mentor for Mastering Bitcoin

I started reading through Mastering Bitcoin and I am a bit stuck on the last part of chapter 03:
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch03.asciidoc#rpc_example
I mean how do we run link:code/rpc_example.py[]
I tried to run it on on terminal, but it didn't work. Also, I couldn't find rpc_example.py inside of repo.
Is there any place where I can find a mentor? some chat or community where I can ask questions?
submitted by craswerr to BitcoinBeginners [link] [comments]

A giant Faucet for HTML5 Canvas JavaScript

​
An example of a pseudo 3d effect using rectangle particles as water droplets
This is a giant Faucet for HTML5 Canvas JavaScript. With a mouse click the faucet will turn on and water particles will start pouring out until it is closed again. When it hits some vertical offset, the water will dissipate outwards with each particle getting slightly bigger as a front perspective view for a pseudo-3d effect. Particle clean-up/removal occurs when reaching the bottom canvas border to keep things running smoothly. Little mists near the spout hole are generated with random vx and vy velocity, with text indication on each side as on/off along with sound effects. The faucet image was modified using Adobe Photoshop.
A use case scenario would be a literal tongue-in-cheek faucet for said crypto-currency. The way you would dispense a set number of coins would require running a server with a full active node in Linux. Then by using a backend script such as a modified variation of bitcoinPHP, python, or nodeJS can be used to validate a user's wallet address by which a set amount can be safely sent with integrated SSL (secure socket layer) protocols via Remote Procedure Calls or RPCs. It's another fun way of 'spicing' up these kinds of projects, if that's your thing.
submitted by Chancellor-Parks to html5 [link] [comments]

Creamcoin 0.18.0.0 – following Bitcoin’s tale

Creamcoin 0.18.0.0 – following Bitcoin’s tale

06/08/2019 3 min read📷216SHARES216VIEWSShare on Twitter
When new Creamcoin was designed, we had in mind not only a coin that would hold parity with any cryptocurrency, but something that would demonstrate the extra-special capabilities of a decentralized ledger, capable to introduce, help and bring it further to the regular people. Blockchain developing is unstoppable complex process with endless possibilities. Integration of applications on such a technology could achieve better, secure pass of value.
0.18.0.0
​
On August 5th, 2019 Creamcoin code was successfully updated to the latest Bitcoin version 0.18.0
https://github.com/creamcoin/cream/
With this latest release, we proved that Creamcoin itself it’s not a sort of a tenant to the Bitcoin. Much easier to apply and to pursue the main purpose of existence and to create further innovations in our Cream Line. The new release brings tremendous performance improvements, as well as integration will be much easier for any platform, exchange or integrator. Wallets are available to Releases tab on github
WALLETS

Multi-wallet support

Cream Core now supports loading multiple, separate wallets. The wallets are completely separated, with individual balances, keys and received transactions. Multi-wallet is enabled by using more than one -wallet argument when starting Creamcoin, either on the command line or in the Cream config file. In Creamcoin-Qt, only the first wallet will be displayed and accessible for creating and signing transactions. GUI selectable multiple wallets will be supported in a future version. This feature will continue to be refined with later updates, as there are still some known issues in using the GUI to access the “multiwallet” command. The most notable is that you can’t use coin control features with multiple wallets loaded, or else you will likely retain the wrong wallet when attempting to switch wallets.
When running Cream Core with multi-wallet, wallet-level RPC methods must specify the wallet for which they’re intended in every request. HTTP RPC requests should be send to the :/wallet// endpoint, for example 127.0.0.1:8332/wallet/wallet1.dat/. bitcoin-cli commands should be run with a -rpcwallet option, for example [bitcoin-cli -rpcwallet=wallet1.dat getbalance] A new node-level [listwallets] RPC method is added to display which wallets are currently loaded. Starting command for both wallets should look like this: [creamd -daemon -wallet=wallet1.dat -wallet=wallet2.dat]

Hardware Wallet native compatibility

With a new release of Cream Core the possibility is added in the form of use hardware wallets (Ledger, Trezor, Digital BitBox, KeepKey, Coldcard), but this process is manual and involves the use of Hardware Wallet Interaction (HWI) tool and it needs HW support and addition of Cream in the future, which is not excluded from roadmap. This is a great news for everyone who use Cream Core, and want extra security. Only applies to those who can use command line/CLI (for now), and when some of Hardware wallets actually supports Cream.

SegWit 4MB limit

SegWit replacing the block size limit with a block “weight” limit, allowing up to 4 megabytes of transaction data, and giving a substantial boost in the transaction capacity of the Cream network.

www.creamcoin.com

In the same with the new code update, Creamcoin Team is doing major shifting power, migrating the marketing and promotion activities, from our news site cream.technology to our main page www.creamcoin.com. We will come up with additional statement in this matter, so our supporters and followers have better perspective of Cream Line and the products of it.
In the meantime we are looking into new ways that developers can enhance the capabilities of the Creamcoin protocol, integration of decentralized exchange functionality, lightning network and number of other options that would allow for different types of conditional sends of Creamcoin assets. We are inviting any individual, platform, exchange or integrator who would like to submit recommendations or feature requests, feel free to contribute to the Creamcoin Github.
By Cream Team
submitted by creamcointeam to u/creamcointeam [link] [comments]

Bitcoin Price Prediction 2020

Bitcoin Price Prediction 2020
Bitcoin is a digital and fully decentralized currency. Decentralization of the network is the main goal of the Bitcoin. The fundamental achievement of bitcoin is its genuine peer-to-peer payment system; no person or even institution was “in charge” of bitcoin.
by StealthEX
Three main ideas were embedded in the Bitcoin code:
• Bitcoin should not be regulated by anyone.
• Its emission should not be infinite.
• The cost of a coin depends on its demand.
The maximum number of bitcoins – 21 million, and the possibility of their extraction were laid in the bitcoin algorithm.
Bitcoin “halving” occurred on 11 May 2020. This means that its miners’ remuneration was halved.

Bitcoin statistics

Source: CoinMarketCap, Data was taken on 19 May 2020.
Current Price $9,672.54
ROI since launch 7,048.96%
Market Cap $177,790,148,642
Market Rank #1
Circulating Supply 18,380,918 BTC
Total Supply 18,380,918 BTC

Bitcoin achievements and future plans

Bitcoin in 2019:

Bitcoin Core released:
• Improved Partially Signed Bitcoin Transaction (PSBT) support and added support for output script descriptors. This allowed it to be used with the first released version of the Hardware Wallet Interface (HWI).
• Implemented the new CPFP carve-out mempool policy, added initial support for BIP158-style compact block filters (currently RPC only), improved security by disabling protocols such as BIP37 bloom filters and BIP70 payment requests by default. It also switches GUI users to bech32 addresses by default.
LND released:
• Support for Static Channel Backups (SCBs) that help users recover any funds settled in their LN channels even if they’ve lost their recent channel state.
• Improved autopilot to help users open new channels, plus built-in compatibility with Lightning Loop for moving funds onchain without closing a channel or using a custodian.
• Added support for using a watchtower to guard your channels when you’re offline.
• Added support for a more extensible onion format, improved backup safety, and improved the watchtower support.
Other:
• Its price has more than doubled.
• For the first time in history Bitcoin was assigned a rating of “A”.
• British court recognized Bitcoin as property.
• The second largest in Germany and ninth in Europe, the Stuttgart Stock Exchange launched Bitcoin spot trading.
• In Russia, for the first time, Bitcoin was added to the authorized capital of a company.
• Bitcoin Named the Best Asset of the Decade by Bank of America Merrill Lynch.

Bitcoin in 2020:

• Focus on the Lightning Network. The continuation of work on c-lightning (Blockstream), Eclair (ACINQ), LND (Lightning Labs) and Rust Lightning to develop the protocol.
• Expectation of the SchnorTaproot softfork in 2020 or 2021 that is improvement in fungibility, privacy, scalability and functionality.
• Bitcoin “halving” occurred on 11 May 2020.
• Amid the general crisis caused by coronavirus pandemic (COVID-19) and the depreciation of money, the Bitcoin value is growing.

Bitcoin Technical Analysis

Source: TradingView, Data was taken on 19 May 2020.

Bitcoin Price Prediction 2020

TradingBeasts BTC price prediction

The Bitcoin price is forecasted to reach $8,681 (-10.25%) by the beginning of June 2020. At the end of 2020 BTC price will be $8,345 (-13.72%).

Wallet investor Bitcoin price prediction

Bitcoin price prediction: maximum price by the end of December 2020 $13,559 (+40.19%), a minimum price $7,886 (-18.47%).

DigitalCoinPrice Bitcoin forecast

There will be a positive trend in the future and the BTC might be good for investing. BTC price will be equal to $22,501 at the end of 2020 (+132.63%).

Crypto-Rating BTC price forecast

Based on historical data Bitcoin price will be at $12,272 (+26.87%) in 1 week and $13,338 (+37.90%) in 1 month. Analysis of the cryptocurrency market shows that Bitcoin price may reach $18,679 (+93.11%) by the 1st of January 2021 driven by the potential interest from large institutional investors and more regulation expected in the field of digital currencies.

Buy Bitcoin at StealthEX

Bitcoin (BTC) is available for exchange on StealthEX with a low fee. Follow these easy steps:
✔ Choose the pair and the amount for your exchange. For example ETH to BTC.
✔ Press the “Start exchange” button.
✔ Provide the recipient address to which the coins will be transferred.
✔ Move your cryptocurrency for the exchange.
✔ Receive your coins.
The views and opinions expressed here are solely those of the author. Every investment and trading move involves risk. You should conduct your own research when making a decision.
Original article was posted on https://stealthex.io/blog/2020/05/19/bitcoin-price-prediction-2020/
submitted by Stealthex_io to u/Stealthex_io [link] [comments]

Solve the "storage, mining pool and exchange centralization", and only generate 1G data every year

The blockheader has two segments with a total length of 64 bit0 (of which blocktime is 64 bits), which strongly prevents the collapse effect of the sha256 operation in the ASIC miner, so that the mining difficulty will not increase indefinitely. The centralization for the high hashrate of the mining pool is strongly restricted. Census and prune the transactions (at most 4 outputs per transaction) whose all outputs are spent，in the block below 1300 depth in batches(i.e. clear up the input and output at the same time, and only keep the version of all-outs-spent transaction on the disk,--not serialize vin and vout). 250 for each batch, 20 block files(one file per block) will be reconstructed for each block received from other nodes, that is to say, 5000 transactions will be pruned at a time. And special mechanism is used to make the synchronization of data from malicious nodes error free. Only 1G data is increased every year. The data it running for 1000 years will be no more than 1T. Block size is 2M, and only 1g data is increased every year without SPV, which strongly prevents the storage of a large number of block data reducing the number of nodes. At the same time, 'four outputs per tx' limit the settlement of the mining pool, and strongly prevent the centralization of the mining pool. For example, the settlement is sent to 4000 miners, which requires 1000 transactions. All currencies are locked in the maturity of 300 blocks (the input can only be used as prevout after 300 blocks), which strongly prevents the frequency of trading speculation, the crash from the online exchange, and prevent the centralization of the biggest online exchange in the world.
This has achieved "absolute decentralization".
At present, the tip height is only 600, and there is no pre-mined. The RPC is stable and reliable same as bitcoin 0.10.2. No segwit but P2SH, a little change based on 0.10.2. Usage: $ /download-directory/bitcoind -addnode =47.114.58.108 (same for Ubuntu) with bitcoin.conf configuration file
Detailed introduction，original text is as follows: github-holyangel250-bitsupercoin
submitted by DangerousDetail8 to BitcoinSerious [link] [comments]

Solve the "storage, mining pool and exchange centralization", and only generate 1G data every year(only pc-miner)

The blockheader has two segments with a total length of 64 bit0 (of which blocktime is 64 bits), which strongly prevents the collapse effect of the sha256 operation in the ASIC miner, so that the mining difficulty will not increase indefinitely. The centralization for the high hashrate of the mining pool is strongly restricted. Census and prune the transactions (at most 4 outputs per transaction) whose all outputs are spent，in the block below 1300 depth in batches(i.e. clear up the input and output at the same time, and only keep the version of all-outs-spent transaction on the disk,--not serialize vin and vout). 250 for each batch, 20 block files(one file per block) will be reconstructed for each block received from other nodes, that is to say, 5000 transactions will be pruned at a time. And special mechanism is used to make the synchronization of data from malicious nodes error free. Only 1G data is increased every year. The data it running for 1000 years will be no more than 1T. Block size is 2M, and only 1g data is increased every year without SPV, which strongly prevents the storage of a large number of block data reducing the number of nodes. At the same time, 'four outputs per tx' limit the settlement of the mining pool, and strongly prevent the centralization of the mining pool. For example, the settlement is sent to 4000 miners, which requires 1000 transactions. All currencies are locked in the maturity of 300 blocks (the input can only be used as prevout after 300 blocks), which strongly prevents the frequency of trading speculation, the crash from the online exchange, and prevent the centralization of the biggest online exchange in the world.
This has achieved "absolute decentralization".
At present, the tip height is only 600, and there is no pre-mined. The RPC is stable and reliable same as bitcoin 0.10.2. No segwit but P2SH, a little change based on 0.10.2. Usage: $ /download-directory/bitcoind -addnode =47.114.58.108 (same for Ubuntu) with bitcoin.conf configuration file
Detailed introduction，original text is as follows: github-holyangel250-bitsupercoin
submitted by DangerousDetail8 to BitcoinMining [link] [comments]

Solve the "storage, mining pool and exchange centralization", and only generate 1G data every year

The blockheader has two segments with a total length of 64 bit0 (of which blocktime is 64 bits), which strongly prevents the collapse effect of the sha256 operation in the ASIC miner, so that the mining difficulty will not increase indefinitely. The centralization for the high hashrate of the mining pool is strongly restricted. Census and prune the transactions (at most 4 outputs per transaction) whose all outputs are spent，in the block below 1300 depth in batches(i.e. clear up the input and output at the same time, and only keep the version of all-outs-spent transaction on the disk,--not serialize vin and vout). 250 for each batch, 20 block files(one file per block) will be reconstructed for each block received from other nodes, that is to say, 5000 transactions will be pruned at a time. And special mechanism is used to make the synchronization of data from malicious nodes error free. Only 1G data is increased every year. The data it running for 1000 years will be no more than 1T. Block size is 2M, and only 1g data is increased every year without SPV, which strongly prevents the storage of a large number of block data reducing the number of nodes. At the same time, 'four outputs per tx' limit the settlement of the mining pool, and strongly prevent the centralization of the mining pool. For example, the settlement is sent to 4000 miners, which requires 1000 transactions. All currencies are locked in the maturity of 300 blocks (the input can only be used as prevout after 300 blocks), which strongly prevents the frequency of trading speculation, the crash from the online exchange, and prevent the centralization of the biggest online exchange in the world.
This has achieved "absolute decentralization".
At present, the tip height is only 600, and there is no pre-mined. The RPC is stable and reliable same as bitcoin 0.10.2. No segwit but P2SH, a little change based on 0.10.2. Usage: $ /download-directory/bitcoind -addnode =47.114.58.108 (same for Ubuntu) with bitcoin.conf configuration file
Detailed introduction，original text is as follows: github-holyangel250-bitsupercoin
submitted by DangerousDetail8 to altcoin_news [link] [comments]

Groestlcoin 6th Anniversary Release

Introduction

Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

Windows
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.
OSX
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), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).

Features

Download

Source

Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.

Features

Download

Windows
Linux :
 pip3 install -r requirements.txt python3 bip39\_gui.py

Source

ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

How to add a Trezor wallet to Bitcoin Core as watch-only

I wanted to use Bitcoin Core to keep an eye on transactions (basically using your own full Bitcoin node to validate, instead of "trusting" Satoshilabs and their webwallet). This doesn't mean there's anything wrong with Satoshilabls' trezor web wallet - it's just a matter of being totally sovereign/independent - if you want that, then using your own Bitcoin Core full node is a must.
Spent some time investigating how to do that, so sharing here in case someone wants it. Feel free to point any ways to do it better.
How-To:
  1. Go to the usual Trezor wallet site, then open the wallet you want to import to Core (don't forget passphrase if needed). Copy the ypub text string.
  2. Convert the ypub to xpub using something like this: https://jlopp.github.io/xpub-converte You can save the page and run it offline/airgapped in something like Tails if you don't trust it. There is no security risk (not a private key) but only privacy risk (with your public keys the site can see all transactions/balances of that wallet)
  3. Put the xpub in a Core RPC importmulti command with this formatting:
    importmulti '[{"range": [0, 1000], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "wpkh([000000f1/84h/0h/0h]your_xpub_goes_here/0/)#7x87wdy3", "internal": false}, {"range": [0, 1000], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "wpkh([000000f1/84h/0h/0h]your_xpub_goes_here/1/)#0jzlnc5f", "internal": true}]'
Then open Bitcoin Core and do these other steps...
  1. In File>Create Wallet, create a wallet with "No Encryption" & "Watch Only" - call it anything you like (TrezorA for example).
  2. Open Window>Console, select the wallet you just created (on the pull-down menu at the top) and then paste the importmulti command where you put your xpub.
  3. Core will complain that the checksum is wrong (the "7x87wdy3" and "wdxy2s2t" parts in my example) replace them with the right ones shown in the message and retry.
  4. You should see the wallet imported with success, but with no transaction history. It is necessary to rescan the chain to index the transactions that wallet made. To save time, you can use the blockheight of the first block where you made a transaction with that trezor, for example: "rescanblockchain 590500".
You can find out the block by putting the hash of your first transfer in a block explorer like https://live.blockcypher.com/, look for "blockheight" If you have no idea which block has your first transaction, you can just rescan the whole chain by typing "rescanblockchain 0" in the console (but Core will take way longer to do it).
That's about it, all transactions made from what wallet should then appear in Core and it will warn every time funds are received or spent. You can be running your own full node and constantly monitoring your wallet, without having to use the Trezor or load Satoshilab's site.
You cannot spend from that wallet in Core, but you can use it to generate receive addresses and send to it (keep in mind that if you generate bech32 addresses in Core, those transfers will not appear at Trezor wallet since it doesn't support it yet :| )
Edit: Forgot change addresses, fixed importmulti example.
submitted by beowulfpt to TREZOR [link] [comments]

A welcome message to developers from Bitcoin.com's Developer Services lead, Gabriel Cardona.

Hi, my name is Gabriel, I lead Developer Services at bitcoin.com. We have a suite of developer tools which should be familiar to an ETH dev.
https://developer.bitcoin.com is the home of all our developer documentation
https://developer.bitcoin.com/bitbox/ is our typescript framework similar to truffle
https://developer.bitcoin.com/slp is for creating, minting, sending and burning tokens. It's also a superset of BITBOX SDK
rest.bitcoin.com - this is the json rpc over http
https://bitdb.bitcoin.com - real time indexer of BCH blockchain in to mongodb collections
https://bitsocket.bitcoin.com - bitbd data in real-time over websockets
https://slpdb.bitcoin.com - entire token graph in mongodb collections
https://slpsocket.bitcoin.com - slpdb data in real-time over websockets
Badger is our fork of MetaMask for BCH:
Cashscript is our smart-contract language inspired by Solidity. It exports an Arifact w/ ABI
CashScript examples as .cash files and needed typescript files to transpile and run them
Testnet Faucet
Any of the above cloud services also works w/ testnet by adding a t to the beginning of the url. For example https://trest.bitcoin.com
We have a developer discord and a telegram room.
I'm @cgcardona and I'm happy to help on-ramp in any way. Cheers 🎩
Source.
submitted by MemoryDealers to btc [link] [comments]

JSON RPC Calls with Bitcoin qt (4 of 6) Bitcoin JSON-RPC Tutorial 6 - JSON Parameters and Errors Bitcoin JSON-RPC Tutorial 2 - VPS Setup Programming Bitcoin-qt using the RPC api (1 of 6)

Python interface to bitcoin's JSON-RPC API. Contribute to jgarzik/python-bitcoinrpc development by creating an account on GitHub. ... Example. from bitcoinrpc. authproxy import AuthServiceProxy, JSONRPCException # rpc_user and rpc_password are set in the bitcoin.conf file rpc_connection = AuthServiceProxy ... Bitcoin Core 0.9.2.1 RPC Calls Extended List (Pastebin/BitcoinSE x-post) I posted Bitcoin Core 0.9.2.1 RPC Calls Extended List over at Bitcoin SE and linked to the full copy/paste at Pastebin There's a few rough formatting issues but I found this hard to find so perhaps it'll help people like myself. Add a nrequired-t Bitcoin-JSON-RPC-Client is a lightweight Java bitcoin JSON-RPC client binding. It does not require any external dependencies. Code Example The JSON-RPC API can be used by other programs to communicate with the Bitcoin client. That could include external mining programs, "e-commerce" software to automatically make and receive payments, or any other software that wants to interact with the Bitcoin network. Running Bitcoin with the -server argument (or running bitcoind) tells it to function as a HTTP JSON-RPC server, but Basic access authentication must be used when communicating with it, and, for security, by default, the server only accepts connections from other processes on the same machine. If your HTTP or JSON library requires you to specify which 'realm' is authenticated, use 'jsonrpc'.

[index] [50075] [31073] [13832] [33631] [46543] [49254] [41298] [33101] [63588] [6873]

JSON RPC Calls with Bitcoin qt (4 of 6)

Bitcoin JSON-RPC tutorial. How to set up bitcoind on a VPS. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U. Bitcoin JSON-RPC tutorial. Handling JSON, entering parameters and receiving error messages. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U. JSON RPC Calls with Bitcoin qt (4 of 6) JSON RPC Calls with Bitcoin qt (4 of 6) Skip navigation Sign in. ... REST API concepts and examples - Duration: 8:53. WebConcepts 4,189,208 views. 8:53. Bitcoin JSON-RPC Tutorial 5 - Your First Calls - Duration: 10:06. m1xolyd1an 11,838 views. 10:06. Building a Blockchain in Under 15 Minutes - Programmer explains - Duration: 14:28.

http://forex-viethnam.mining-season.pw