Bitcoin core wallet RPC console commands - Bitcoin-qt ...

Bitcoin Developers

For programmers and developers interested in asking questions, submitting tutorials, providing notices, etc. about the technical aspects of Bitcoin.
[link]

Can anyone run RPC commands on my full node if I run bitcoind or bitcoin-qt connected to the internet?

Is RPC completely disabled if I don't include bitcoin.conf in my bitcoin directory, and if it's there, does bitcoind open ports automatically that allow anyone to RPC on my node?
submitted by sonkeypop to Bitcoin [link] [comments]

Can anyone run RPC commands on my full node if I run bitcoind or bitcoin-qt connected to the internet? /r/Bitcoin

Can anyone run RPC commands on my full node if I run bitcoind or bitcoin-qt connected to the internet? /Bitcoin submitted by HiIAMCaptainObvious to BitcoinAll [link] [comments]

Generating a new address via RPC "getnewaddress" and its not showing up in bitcoin QT

when I generate a new address via rpc by calling "getnewaddress", new addresses don't show up in the qt GUI. Why not? How to get them to show up?
submitted by Konjikuru to Bitcoin [link] [comments]

RPC "getnewaddress" and qt GUI app -- an address doesn't show up /r/Bitcoin

RPC submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Generating a new address via RPC "getnewaddress" and its not showing up in bitcoin QT /r/Bitcoin

Generating a new address via RPC submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Tutorial: Using Bitcoin-QT as a JSON RPC Server (C# sample but could be used with any language)

submitted by 100acrewood to BitcoinCode [link] [comments]

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]

Power of the Command Line (bitcoin-cli, hwi, electrum, trezorctl)

I think some of the console tools available with HW wallets today are greatly under utilized. Here's a quick write-up on how to create and sign a TXN very similar to 43d27...1fc06 found on the SLIP-14 wallet. I'll be using TrezorCTL, Electrum, and HWI for the signing. I won't go much into the setup or install, but feel free to ask if you have questions about it. Note, you don't have to use all three of these. Any one will produce a valid signed TXN for broadcast. I just showed how to do it three ways. Whats more some of the Electrum and HWI steps are interchangeable.
ColdCard also has a utility called ckcc that will do the sign operation instead of HWI, but in many ways they are interchangeable. KeepKey and Ledger both have libraries for scripted signing but no one-shot, one-line console apps that I know of. But HWI and Electrum of course work on all four.

TrezorCTL

This is the what most would think of to use to craft and sign TXNs, and is definitely very simple. The signing uses a script called build_tx.py to create a JSON file that is then used by the btc sign-tx command. The whole process is basically:
  1. tools/build_tx.py | trezorctl btc sign-tx -
This just means, take the output of build_tx and sign it. To copy 43d27...1fc06, I wrote a small script to feed build_tx, so my process looks like:
  1. ~/input.sh | tools/build_tx.py | trezorctl btc sign-tx -
But it's all very simple. Note... I used TrezorCTL v0.12.2 but build_tx.py version 0.13.0 1.

input.sh

```

!/bin/bash

secho() { sleep 1; echo $*}
secho "Testnet" # coin name secho "tbtc1.trezor.io" # blockbook server and outpoint (below) secho "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00:0" secho "m/84'/1'/0'/0/0" # prev_out derivation to signing key secho "4294967293" # Sequence for RBF; hex(-3) secho "segwit" # Signature type on prev_out to use secho "" # NACK to progress to outs secho "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" # out[0].addr secho "10000000" # out[1].amt secho "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu" # out[1].addr secho "20000000" # out[1].amt secho "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x" # out[2].addr secho "99999694" # out[2].amt secho "" # NACK to progress to change secho "" # NACK to skip change secho "2" # txn.version secho "0" # txn.locktime ```

Electrum

Electrum is one of the better GUI wallets available, but it also has a pretty good console interface. Like before you need your Trezor with the SLIP-14 wallet loaded and paired to Electrum. I'll assume Electrum is up and running with the Trezor wallet loaded to make things simple.
Like with TrezorCTL, Electrum feeds on a JSON file, but unlike TrezorCTL it needs that JSON squished into the command line. This is a simple sed command, but I won't bore you with the details, but just assume that's done. So the process in Electrum (v4.0.3) looks like:
  1. electrum serialize (create psbt to sign)
  2. electrum --wallet signtransaction (sign said psbt)
Still pretty simple right! Below is the JSON I smushed for #1

txn.json

{ "inputs": [{ "prevout_hash":"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "prevout_n": 0, "value_sats": 129999867 }], "outputs": [{ "address": "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3", "value_sats": 10000000 },{ "address": "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu", "value_sats": 20000000 },{ "address": "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x", "value_sats": 99999694 }]}

HWI

HWI is an unsung hero in my book. It's a very small clean and simple interface between HW wallets and Bitcoin Core. It currently supports a good range of HW wallets. It keeps itself narrowly focused on TXN signing and offloads most everything else to Bitcoin Core. Again, I'll assume you've imported your Trezor keypool into Core and done the requisite IBD and rescan. And if you don't have the RPC enabled, you can always clone these commands into the QT-console.
To sign our TXN in HWI (v1.1.2), we will first need to craft (and finalize) it in Bitcoin Core (0.21.1). Like in Electrum, we will have to use simple sed to smush some JSON into command arguments, but I'll assume you have that covered. It will take an inputs.json and an outputs.json named separately.
  1. bitcoin-cli createpsbt (create psbt)
  2. bitcoin-cli -rpcwallet= walletprocesspsbt (process psbt)
  3. hwi -f signtx (sign psbt)
  4. bitcoin-cli -rpcwallet= finalizepsbt (get a signed TXN from psbt)
A little more involved, but still nothing too bad. Plus this gives you the full power of Bitcoin Core including integrations with LND (lightning).

inputs.json

[{ "txid": "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "vout": 0 }]

outputs.json

[{ "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3": 0.10000000 },{ "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu": 0.20000000 },{ "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x": 0.99999694 }]

Conclusion

This may all seem like very low level coding, but is surprisingly simple once you get a knack for it. Whats more, all these platforms support testnet which allows you to practice with valueless coins until you get the hang of it. And, like many things in bitcoin, this is all (mostly) python, which is one of the easier languages to learn.
Enjoy
Footnotes
1 - https://github.com/trezotrezor-firmware/issues/1296
submitted by brianddk to Bitcoin [link] [comments]

txindex=1 server=1 question (node, rpc)

Edit: solved! Just needed to wait for indexing to catch up
Hi all I'm trying to use btc-rpc-explorer
https://github.com/janoside/btc-rpc-explorer
I have a full node via bitcoin qt. Can I use qt for block explorer?
I launch block explorer and I'm getting rpc error. The webpage states "check rpc connection info"
The github project states I need server=1 and txindex=1. Can I make qt run with these settings? I tried adding them to the .conf but how can I confirm qt is running with these options, in console somehow?
In case I can't use qt for this I downloaded bitcoind. It looks like I can start the daemon with txindex=1 and server=1 but still getting same connection problem with btc-rpc-explorer.
Do I have to do -reindex=1? Can I do that within qt? If not and I use bitcoin cli will it disrupt qt in any way?
Thanks
Edit: this is on Ubuntu
submitted by redditor157b to Bitcoin [link] [comments]

Power of the Command Line (bitcoin-cli, hwi, electrum, trezorctl)

I think some of the console tools available with HW wallets today are greatly under utilized. Here's a quick write-up on how to create and sign a TXN very similar to 43d27...1fc06 found on the SLIP-14 wallet. I'll be using TrezorCTL, Electrum, and HWI for the signing. I won't go much into the setup or install, but feel free to ask if you have questions about it. Note, you don't have to use all three of these. Any one will produce a valid signed TXN for broadcast. I just showed how to do it three ways. Whats more some of the Electrum and HWI steps are interchangeable.

TrezorCTL

This is the what most would think of to use to craft and sign TXNs, and is definitely very simple. The signing uses a script called build_tx.py to create a JSON file that is then used by the btc sign-tx command. The whole process is basically:
  1. tools/build_tx.py | trezorctl btc sign-tx -
This just means, take the output of build_tx and sign it. To copy 43d27...1fc06, I wrote a small script to feed build_tx, so my process looks like:
  1. ~/input.sh | tools/build_tx.py | trezorctl btc sign-tx -
But it's all very simple. Note... I used TrezorCTL v0.12.2 but build_tx.py version 0.13.0 1.

input.sh

```

!/bin/bash

secho() { sleep 1; echo $*}
secho "Testnet" # coin name secho "tbtc1.trezor.io" # blockbook server and outpoint (below) secho "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00:0" secho "m/84'/1'/0'/0/0" # prev_out derivation to signing key secho "4294967293" # Sequence for RBF; hex(-3) secho "segwit" # Signature type on prev_out to use secho "" # NACK to progress to outs secho "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3" # out[0].addr secho "10000000" # out[1].amt secho "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu" # out[1].addr secho "20000000" # out[1].amt secho "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x" # out[2].addr secho "99999694" # out[2].amt secho "" # NACK to progress to change secho "" # NACK to skip change secho "2" # txn.version secho "0" # txn.locktime ```

Electrum

Electrum is one of the better GUI wallets available, but it also has a pretty good console interface. Like before you need your Trezor with the SLIP-14 wallet loaded and paired to Electrum. I'll assume Electrum is up and running with the Trezor wallet loaded to make things simple.
Like with TrezorCTL, Electrum feeds on a JSON file, but unlike TrezorCTL it needs that JSON squished into the command line. This is a simple sed command, but I won't bore you with the details, but just assume that's done. So the process in Electrum (v4.0.3) looks like:
  1. electrum serialize (create psbt to sign)
  2. electrum --wallet signtransaction (sign said psbt)
Still pretty simple right! Below is the JSON I smushed for #1

txn.json

{ "inputs": [{ "prevout_hash":"e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "prevout_n": 0, "value_sats": 129999867 }], "outputs": [{ "address": "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3", "value_sats": 10000000 },{ "address": "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu", "value_sats": 20000000 },{ "address": "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x", "value_sats": 99999694 }]}

HWI

HWI is an unsung hero in my book. It's a very small clean and simple interface between HW wallets and Bitcoin Core. It currently supports a good range of HW wallets. It keeps itself narrowly focused on TXN signing and offloads most everything else to Bitcoin Core. Again, I'll assume you've imported your Trezor keypool into Core and done the requisite IBD and rescan. And if you don't have the RPC enabled, you can always clone these commands into the QT-console.
To sign our TXN in HWI (v1.1.2), we will first need to craft (and finalize) it in Bitcoin Core (0.21.1). Like in Electrum, we will have to use simple sed to smush some JSON into command arguments, but I'll assume you have that covered. It will take an inputs.json and an outputs.json named separately.
  1. bitcoin-cli createpsbt (create psbt)
  2. bitcoin-cli -rpcwallet= walletprocesspsbt (process psbt)
  3. hwi -f signtx (sign psbt)
  4. bitcoin-cli -rpcwallet= finalizepsbt (get a signed TXN from psbt)
A little more involved, but still nothing too bad. Plus this gives you the full power of Bitcoin Core including integrations with LND (lightning).

inputs.json

[{ "txid": "e294c4c172c3d87991b0369e45d6af8584be92914d01e3060fad1ed31d12ff00", "vout": 0 }]

outputs.json

[{ "2MsiAgG5LVDmnmJUPnYaCeQnARWGbGSVnr3": 0.10000000 },{ "tb1q9l0rk0gkgn73d0gc57qn3t3cwvucaj3h8wtrlu": 0.20000000 },{ "tb1qejqxwzfld7zr6mf7ygqy5s5se5xq7vmt96jk9x": 0.99999694 }]

Conclusion

This may all seem like very low level coding, but is surprisingly simple once you get a knack for it. Whats more, all these platforms support testnet which allows you to practice with valueless coins until you get the hang of it. And, like many things in bitcoin, this is all (mostly) python, which is one of the easier languages to learn.
Enjoy
Footnotes
1 - https://github.com/trezotrezor-firmware/issues/1296
submitted by brianddk to TREZOR [link] [comments]

Syscoin Platform’s Great Reddit Scaling Bake-off Proposal

Syscoin Platform’s Great Reddit Scaling Bake-off Proposal

https://preview.redd.it/rqt2dldyg8e51.jpg?width=1044&format=pjpg&auto=webp&s=777ae9d4fbbb54c3540682b72700fc4ba3de0a44
We are excited to participate and present Syscoin Platform's ideal characteristics and capabilities towards a well-rounded Reddit Community Points solution!
Our scaling solution for Reddit Community Points involves 2-way peg interoperability with Ethereum. This will provide a scalable token layer built specifically for speed and high volumes of simple value transfers at a very low cost, while providing sovereign ownership and onchain finality.
Token transfers scale by taking advantage of a globally sorting mempool that provides for probabilistically secure assumptions of “as good as settled”. The opportunity here for token receivers is to have an app-layer interactivity on the speed/security tradeoff (99.9999% assurance within 10 seconds). We call this Z-DAG, and it achieves high-throughput across a mesh network topology presently composed of about 2,000 geographically dispersed full-nodes. Similar to Bitcoin, however, these nodes are incentivized to run full-nodes for the benefit of network security, through a bonded validator scheme. These nodes do not participate in the consensus of transactions or block validation any differently than other nodes and therefore do not degrade the security model of Bitcoin’s validate first then trust, across every node. Each token transfer settles on-chain. The protocol follows Bitcoin core policies so it has adequate code coverage and protocol hardening to be qualified as production quality software. It shares a significant portion of Bitcoin’s own hashpower through merged-mining.
This platform as a whole can serve token microtransactions, larger settlements, and store-of-value in an ideal fashion, providing probabilistic scalability whilst remaining decentralized according to Bitcoin design. It is accessible to ERC-20 via a permissionless and trust-minimized bridge that works in both directions. The bridge and token platform are currently available on the Syscoin mainnet. This has been gaining recent attention for use by loyalty point programs and stablecoins such as Binance USD.

Solutions

Syscoin Foundation identified a few paths for Reddit to leverage this infrastructure, each with trade-offs. The first provides the most cost-savings and scaling benefits at some sacrifice of token autonomy. The second offers more preservation of autonomy with a more narrow scope of cost savings than the first option, but savings even so. The third introduces more complexity than the previous two yet provides the most overall benefits. We consider the third as most viable as it enables Reddit to benefit even while retaining existing smart contract functionality. We will focus on the third option, and include the first two for good measure.
  1. Distribution, burns and user-to-user transfers of Reddit Points are entirely carried out on the Syscoin network. This full-on approach to utilizing the Syscoin network provides the most scalability and transaction cost benefits of these scenarios. The tradeoff here is distribution and subscription handling likely migrating away from smart contracts into the application layer.
  2. The Reddit Community Points ecosystem can continue to use existing smart contracts as they are used today on the Ethereum mainchain. Users migrate a portion of their tokens to Syscoin, the scaling network, to gain much lower fees, scalability, and a proven base layer, without sacrificing sovereign ownership. They would use Syscoin for user-to-user transfers. Tips redeemable in ten seconds or less, a high-throughput relay network, and onchain settlement at a block target of 60 seconds.
  3. Integration between Matic Network and Syscoin Platform - similar to Syscoin’s current integration with Ethereum - will provide Reddit Community Points with EVM scalability (including the Memberships ERC777 operator) on the Matic side, and performant simple value transfers, robust decentralized security, and sovereign store-of-value on the Syscoin side. It’s “the best of both worlds”. The trade-off is more complex interoperability.

Syscoin + Matic Integration

Matic and Blockchain Foundry Inc, the public company formed by the founders of Syscoin, recently entered a partnership for joint research and business development initiatives. This is ideal for all parties as Matic Network and Syscoin Platform provide complementary utility. Syscoin offers characteristics for sovereign ownership and security based on Bitcoin’s time-tested model, and shares a significant portion of Bitcoin’s own hashpower. Syscoin’s focus is on secure and scalable simple value transfers, trust-minimized interoperability, and opt-in regulatory compliance for tokenized assets rather than scalability for smart contract execution. On the other hand, Matic Network can provide scalable EVM for smart contract execution. Reddit Community Points can benefit from both.
Syscoin + Matic integration is actively being explored by both teams, as it is helpful to Reddit, Ethereum, and the industry as a whole.

Proving Performance & Cost Savings

Our POC focuses on 100,000 on-chain settlements of token transfers on the Syscoin Core blockchain. Transfers and burns perform equally with Syscoin. For POCs related to smart contracts (subscriptions, etc), refer to the Matic Network proposal.
On-chain settlement of 100k transactions was accomplished within roughly twelve minutes, well-exceeding Reddit’s expectation of five days. This was performed using six full-nodes operating on compute-optimized AWS c4.2xlarge instances which were geographically distributed (Virginia, London, Sao Paulo Brazil, Oregon, Singapore, Germany). A higher quantity of settlements could be reached within the same time-frame with more broadcasting nodes involved, or using hosts with more resources for faster execution of the process.
Addresses used: 100,014
The demonstration was executed using this tool. The results can be seen in the following blocks:
612722: https://sys1.bcfn.ca/block/6d47796d043bb4c508d29123e6ae81b051f5e0aaef849f253c8f3a6942a022ce
612723: https://sys1.bcfn.ca/block/8e2077f743461b90f80b4bef502f564933a8e04de97972901f3d65cfadcf1faf
612724: https://sys1.bcfn.ca/block/205436d25b1b499fce44c29567c5c807beaca915b83cc9f3c35b0d76dbb11f6e
612725: https://sys1.bcfn.ca/block/776d1b1a0f90f655a6bbdf559ff5072459cbdc5682d7615ff4b78c00babdc237
612726: https://sys1.bcfn.ca/block/de4df0994253742a1ac8ac9eec8d2a8c8b0a6d72c53d6f3caa29bb6c171b0a6b
612727: https://sys1.bcfn.ca/block/e5e167c52a9decb313fbaadf49a5e34cb490f8084f642a850385476d4ef10d70
612728: https://sys1.bcfn.ca/block/ab64d989edc71890e7b5b8491c20e9a27520dc45a5f7c776d3dae79057f59fe7
612729: https://sys1.bcfn.ca/block/5e8b7ecd0e36f99d07e4ea6e135fc952bf7ec30164ab6f4d1e98b0f2d405df6d
612730: https://sys1.bcfn.ca/block/d395df3d31dde60bbb0bece6bd5b358297da878f0beb96be389e5f0e043580a3
It is important to note that this POC is not focused on Z-DAG. The performance of Z-DAG has been benchmarked within realistic network conditions: Whiteblock’s audit is publicly available. Network latency tests showed an average TPS around 15k with burst capacity up to 61k. Zero-latency control group exhibited ~150k TPS. Mainnet testing of the Z-DAG network is achievable and will require further coordination and additional resources.
Even further optimizations are expected in the upcoming Syscoin Core release which will implement a UTXO model for our token layer bringing further efficiency as well as open the door to additional scaling technology currently under research by our team and academic partners. At present our token layer is account-based, similar to Ethereum. Opt-in compliance structures will also be introduced soon which will offer some positive performance characteristics as well. It makes the most sense to implement these optimizations before performing another benchmark for Z-DAG, especially on the mainnet considering the resources required to stress-test this network.

Cost Savings

Total cost for these 100k transactions: $0.63 USD
See the live fee comparison for savings estimation between transactions on Ethereum and Syscoin. Below is a snapshot at time of writing:
ETH price: $318.55 ETH gas price: 55.00 Gwei ($0.37)
Syscoin price: $0.11
Snapshot of live fee comparison chart
Z-DAG provides a more efficient fee-market. A typical Z-DAG transaction costs 0.0000582 SYS. Tokens can be safely redeemed/re-spent within seconds or allowed to settle on-chain beforehand. The costs should remain about this low for microtransactions.
Syscoin will achieve further reduction of fees and even greater scalability with offchain payment channels for assets, with Z-DAG as a resilience fallback. New payment channel technology is one of the topics under research by the Syscoin development team with our academic partners at TU Delft. In line with the calculation in the Lightning Networks white paper, payment channels using assets with Syscoin Core will bring theoretical capacity for each person on Earth (7.8 billion) to have five on-chain transactions per year, per person, without requiring anyone to enter a fee market (aka “wait for a block”). This exceeds the minimum LN expectation of two transactions per person, per year; one to exist on-chain and one to settle aggregated value.

Tools, Infrastructure & Documentation

Syscoin Bridge

Mainnet Demonstration of Syscoin Bridge with the Basic Attention Token ERC-20
A two-way blockchain interoperability system that uses Simple Payment Verification to enable:
  • Any Standard ERC-20 token to be moved from Ethereum to the Syscoin blockchain as a Syscoin Platform Token (SPT), and back to Ethereum
  • Any SPT to be moved from Syscoin to the Ethereum blockchain as an ERC-20 token, and back to Syscoin

Benefits

  • Permissionless
  • No counterparties involved
  • No trading mechanisms involved
  • No third-party liquidity providers required
  • Cross-chain Fractional Supply - 2-way peg - Token supply maintained globally
  • ERC-20s gain vastly improved transactionality with the Syscoin Token Platform, along with the security of bitcoin-core-compliant PoW.
  • SPTs gain access to all the tooling, applications and capabilities of Ethereum for ERC-20, including smart contracts.
https://preview.redd.it/l8t2m8ldh8e51.png?width=1180&format=png&auto=webp&s=b0a955a0181746dc79aff718bd0bf607d3c3aa23
https://preview.redd.it/26htnxzfh8e51.png?width=1180&format=png&auto=webp&s=d0383d3c2ee836c9f60b57eca35542e9545f741d

Source code

https://github.com/syscoin/?q=sysethereum
Main Subprojects

API

Tools to simplify using Syscoin Bridge as a service with dapps and wallets will be released some time after implementation of Syscoin Core 4.2. These will be based upon the same processes which are automated in the current live Sysethereum Dapp that is functioning with the Syscoin mainnet.

Documentation

Syscoin Bridge & How it Works (description and process flow)
Superblock Validation Battles
HOWTO: Provision the Bridge for your ERC-20
HOWTO: Setup an Agent
Developer & User Diligence

Trade-off

The Syscoin Ethereum Bridge is secured by Agent nodes participating in a decentralized and incentivized model that involves roles of Superblock challengers and submitters. This model is open to participation. The benefits here are trust-minimization, permissionless-ness, and potentially less legal/regulatory red-tape than interop mechanisms that involve liquidity providers and/or trading mechanisms.
The trade-off is that due to the decentralized nature there are cross-chain settlement times of one hour to cross from Ethereum to Syscoin, and three hours to cross from Syscoin to Ethereum. We are exploring ways to reduce this time while maintaining decentralization via zkp. Even so, an “instant bridge” experience could be provided by means of a third-party liquidity mechanism. That option exists but is not required for bridge functionality today. Typically bridges are used with batch value, not with high frequencies of smaller values, and generally it is advantageous to keep some value on both chains for maximum availability of utility. Even so, the cross-chain settlement time is good to mention here.

Cost

Ethereum -> Syscoin: Matic or Ethereum transaction fee for bridge contract interaction, negligible Syscoin transaction fee for minting tokens
Syscoin -> Ethereum: Negligible Syscoin transaction fee for burning tokens, 0.01% transaction fee paid to Bridge Agent in the form of the ERC-20, Matic or Ethereum transaction fee for contract interaction.

Z-DAG

Zero-Confirmation Directed Acyclic Graph is an instant settlement protocol that is used as a complementary system to proof-of-work (PoW) in the confirmation of Syscoin service transactions. In essence, a Z-DAG is simply a directed acyclic graph (DAG) where validating nodes verify the sequential ordering of transactions that are received in their memory pools. Z-DAG is used by the validating nodes across the network to ensure that there is absolute consensus on the ordering of transactions and no balances are overflowed (no double-spends).

Benefits

  • Unique fee-market that is more efficient for microtransaction redemption and settlement
  • Uses decentralized means to enable tokens with value transfer scalability that is comparable or exceeds that of credit card networks
  • Provides high throughput and secure fulfillment even if blocks are full
  • Probabilistic and interactive
  • 99.9999% security assurance within 10 seconds
  • Can serve payment channels as a resilience fallback that is faster and lower-cost than falling-back directly to a blockchain
  • Each Z-DAG transaction also settles onchain through Syscoin Core at 60-second block target using SHA-256 Proof of Work consensus
https://preview.redd.it/pgbx84jih8e51.png?width=1614&format=png&auto=webp&s=5f631d42a33dc698365eb8dd184b6d442def6640

Source code

https://github.com/syscoin/syscoin

API

Syscoin-js provides tooling for all Syscoin Core RPCs including interactivity with Z-DAG.

Documentation

Z-DAG White Paper
Useful read: An in-depth Z-DAG discussion between Syscoin Core developer Jag Sidhu and Brave Software Research Engineer Gonçalo Pestana

Trade-off

Z-DAG enables the ideal speed/security tradeoff to be determined per use-case in the application layer. It minimizes the sacrifice required to accept and redeem fast transfers/payments while providing more-than-ample security for microtransactions. This is supported on the premise that a Reddit user receiving points does need security yet generally doesn’t want nor need to wait for the same level of security as a nation-state settling an international trade debt. In any case, each Z-DAG transaction settles onchain at a block target of 60 seconds.

Syscoin Specs

Syscoin 3.0 White Paper
(4.0 white paper is pending. For improved scalability and less blockchain bloat, some features of v3 no longer exist in current v4: Specifically Marketplace Offers, Aliases, Escrow, Certificates, Pruning, Encrypted Messaging)
  • 16MB block bandwidth per minute assuming segwit witness carrying transactions, and transactions ~200 bytes on average
  • SHA256 merge mined with Bitcoin
  • UTXO asset layer, with base Syscoin layer sharing identical security policies as Bitcoin Core
  • Z-DAG on asset layer, bridge to Ethereum on asset layer
  • On-chain scaling with prospect of enabling enterprise grade reliable trustless payment processing with on/offchain hybrid solution
  • Focus only on Simple Value Transfers. MVP of blockchain consensus footprint is balances and ownership of them. Everything else can reduce data availability in exchange for scale (Ethereum 2.0 model). We leave that to other designs, we focus on transfers.
  • Future integrations of MAST/Taproot to get more complex value transfers without trading off trustlessness or decentralization.
  • Zero-knowledge Proofs are a cryptographic new frontier. We are dabbling here to generalize the concept of bridging and also verify the state of a chain efficiently. We also apply it in our Digital Identity projects at Blockchain Foundry (a publicly traded company which develops Syscoin softwares for clients). We are also looking to integrate privacy preserving payment channels for off-chain payments through zkSNARK hub & spoke design which does not suffer from the HTLC attack vectors evident on LN. Much of the issues plaguing Lightning Network can be resolved using a zkSNARK design whilst also providing the ability to do a multi-asset payment channel system. Currently we found a showstopper attack (American Call Option) on LN if we were to use multiple-assets. This would not exist in a system such as this.

Wallets

Web3 and mobile wallets are under active development by Blockchain Foundry Inc as WebAssembly applications and expected for release not long after mainnet deployment of Syscoin Core 4.2. Both of these will be multi-coin wallets that support Syscoin, SPTs, Ethereum, and ERC-20 tokens. The Web3 wallet will provide functionality similar to Metamask.
Syscoin Platform and tokens are already integrated with Blockbook. Custom hardware wallet support currently exists via ElectrumSys. First-class HW wallet integration through apps such as Ledger Live will exist after 4.2.
Current supported wallets
Syscoin Spark Desktop
Syscoin-Qt

Explorers

Mainnet: https://sys1.bcfn.ca (Blockbook)
Testnet: https://explorer-testnet.blockchainfoundry.co

Thank you for close consideration of our proposal. We look forward to feedback, and to working with the Reddit community to implement an ideal solution using Syscoin Platform!

submitted by sidhujag to ethereum [link] [comments]

Accessing wallet never connected to Bitcoin Core

Hey there,
I've made a rookie error and deposited coins into a wallet which never connected to Bitcoin Core. I get that this is completely my fault, but would appreciate some help if possible.
What I did
I followed the installation instructions listed here for macOS. Everything seemed to run smoothly. I began tinkering with the joinmarket.cfg config and inadvertently set my blockchain_source to no-blockchain. I generated a wallet using the python wallet-tool.py generate command and then listed my addresses using the python wallet-tool.py wallet.jmdat command. I deposited Bitcoin into one of my addresses before realising that I wasn't correctly connecting to Bitcoin Core. When I set the blockchain_source back to bitcoin-rpc I get an error stating Failure of RPC connection to Bitcoin Core. Application cannot continue, shutting down. when attempting to run `python joinmarket-qt.py.
What should I do?
I'm not entirely sure how I am meant to be connecting to Bitcoin Core and if once I do connect, I'll be able to access my funds deposited to the wallet address listed earlier.
Would I be better off somehow exporting this wallet to another program (or whatever that process is)?
Any advice would be appreciated. Let me know if you have any questions.
Cheers!
submitted by Beardo01 to joinmarket [link] [comments]

Bitcoin Cash Ecosystem Sees a Tidal Wave of Merchant Acceptance, far more than Bitcoin Core.

Bitcoin Cash Ecosystem Sees a Tidal Wave of Merchant Acceptance, far more than Bitcoin Core. submitted by MemoryDealers to btc [link] [comments]

Connecting bitcoin-qt to bitcoind on local network

Hello,
I have a bitcoin node running on a headless box (bitcoind) and I would like to connect to it using bitcoin-qt on my desktop. I'm getting a little confused with the process.... does bitcoin-qt need to connect to bitcoind using RPC? Do I store my wallet file on the bitcoind box, or bitcoin-qt box?
The bitcoin node is already setup to work with an electrum server, so I already have rpcbind=0.0.0.0, rpcallowip=$ELECTRUX_IP, and rpcuserpcpassword set. I tried adding my desktop IP to rpcallowip, and setting the appropriate username/password in bitcoin-qt's bitcoin.conf, but no luck. I can see in debug.log for bitcoin-qt that the connection is rejected.

The node runs over TOR and I have onlynet=onion set in bitcoind's bitcoin.conf, but that doesn't seem to stop electrumx connecting via RPC over clearnet, so this shouldn't be an issue right?

Am I missing something here? Help would be much appreciated!
submitted by backfromBTCpast to Bitcoin [link] [comments]

Reddcoin (RDD) 02/20 Progress Report - Core Wallet v3.1 Evolution & PoSV v2 - Commits & More Commits to v3.1! (Bitcoin Core 0.10, MacOS Catalina, QT Enhanced Speed and Security and more!)

Reddcoin (RDD) Core Dev Team Informal Progress Report, Feb 2020 - As any blockchain or software expert will confirm, the hardest part of making successful progress in blockchain and crypto is invisible to most users. As developers, the Reddcoin Core team relies on internal experts like John Nash, contributors offering their own code improvements to our repos (which we would love to see more of!) and especially upstream commits from experts working on open source projects like Bitcoin itself. We'd like tothank each and everyone who's hard work has contributed to this progress.
As part of Reddcoin's evolution, and in order to include required security fixes, speed improvements that are long overdue, the team has up to this point incorporated the following code commits since our last v3.0.1 public release. In attempting to solve the relatively minor font display issue with MacOS Catalina, we uncovered a complicated interweaving of updates between Reddcoin Core, QT software, MacOS SDK, Bitcoin Core and related libraries and dependencies that mandated we take a holistic approach to both solve the Catalina display problem, but in doing so, prepare a more streamlined overall build and test system, allowing the team to roll out more frequent and more secure updates in the future. And also to include some badly needed fixes in the current version of Core, which we have tentatively labeled Reddcoin Core Wallet v3.1.
Note: As indicated below, v3.1 is NOT YET AVAILABLE FOR DOWNLOAD BY PUBLIC. We wil advise when it is.
The new v3.1 version should be ready for internal QA and build testing by the end of this week, with luck, and will be turned over to the public shortly thereafter once testing has proven no unexpected issues have been introduced. We know the delay has been a bit extended for our ReddHead MacOS Catalina stakers, and we hope to have them all aboard soon. We have moved with all possible speed while attempting to incorproate all the required work, testing, and ensuring security and safety for our ReddHeads.
Which leads us to: PoSV v2 activation and the supermajority on Mainnet at the time of this writing has reached 5625/9000 blocks or 62.5%. We have progressed quite well and without any reported user issues since release, but we need all of the community to participate! This activation, much like the funding mechanisms currently being debated by BCH and others, and employed by DASH, will mean not only a catalyst for Reddcoin but ensure it's future by providing funding for the dev team. As a personal plea from the team, please help us support the PoSV v2 activation by staking your RDD, no matter how large or small your amount of stake.
Every block and every RDD counts, and if you don't know how, we'll teach you! Live chat is fun as well as providing tech support you can trust from devs and community ReddHead members. Join us today in staking and online and collect some RDD "rain" from users and devs alike!
If you're holding Reddcoin and not staking, or you haven't upgraded your v2.x wallet to v3.0.1 (current release), we need you to help achieve consensus and activate PoSV v2! For details, see the pinned message here or our website or medium channel. Upgrade is simple and takes moments; if you're nervous or unsure, we're here to help live in Telegram or Discord, as well as other chat programs. See our website for links.
Look for more updates shortly as our long-anticipated Reddcoin Payment Gateway and Merchant Services API come online with point-of-sale support, as we announce the cross-crypto-project Aussie firefighter fundraiser program, as well as a comprehensive update to our development roadmap and more.
Work has restarted on ReddID and multiple initiatives are underway to begin educating and sharing information about ReddID, what it is, and how to use it, as we approach a releasable ReddID product. We enthusiastically encourage anyone interested in working to bring these efforts to life, whether writers, UX/UI experts, big data analysts, graphic artists, coders, front-end, back-end, AI, DevOps, the Reddcoin Core dev team is growing, and there's more opportunity and work than ever!
Bring your talents to a community and dev team that truly appreciates it, and share the Reddcoin Love!
And now, lots of commits. As v3.1 is not yet quite ready for public release, these commits have not been pushed publicly, but in the interests of sharing progress transparently, and including our ReddHead community in the process, see below for mind-numbing technical detail of work accomplished.
e5c143404 - - 2014-08-07 - Ross Nicoll - Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope. *99a7dba2e - - 2014-08-15 - Cory Fields - tests: fix test-runner for osx. Closes ##4708 *8c667f1be - - 2014-08-15 - Cory Fields - build: add funcs.mk to the list of meta-depends *bcc1b2b2f - - 2014-08-15 - Cory Fields - depends: fix shasum on osx < 10.9 *54dac77d1 - - 2014-08-18 - Cory Fields - build: add option for reducing exports (v2) *6fb9611c0 - - 2014-08-16 - randy-waterhouse - build : fix CPPFLAGS for libbitcoin_cli *9958cc923 - - 2014-08-16 - randy-waterhouse - build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix. *342aa98ea - - 2014-08-07 - Cory Fields - build: fix automake warnings about the use of INCLUDES *46db8ad51 - - 2020-02-18 - John Nash - build: add build.h to the correct target *a24de1e4c - - 2014-11-26 - Pavel Janík - Use complete path to include bitcoin-config.h. *fd8f506e5 - - 2014-08-04 - Wladimir J. van der Laan - qt: Demote ReportInvalidCertificate message to qDebug *f12aaf3b1 - - 2020-02-17 - John Nash - build: QT5 compiled with fPIC require fPIC to be enabled, fPIE is not enough *7a991b37e - - 2014-08-12 - Wladimir J. van der Laan - build: check for sys/prctl.h in the proper way *2cfa63a48 - - 2014-08-11 - Wladimir J. van der Laan - build: Add mention of --disable-wallet to bdb48 error messages *9aa580f04 - - 2014-07-23 - Cory Fields - depends: add shared dependency builder *8853d4645 - - 2014-08-08 - Philip Kaufmann - [Qt] move SubstituteFonts() above ToolTipToRichTextFilter *0c98e21db - - 2014-08-02 - Ross Nicoll - URLs containing a / after the address no longer cause parsing errors. *7baa77731 - - 2014-08-07 - ntrgn - Fixes ignored qt 4.8 codecs path on windows when configuring with --with-qt-libdir *2a3df4617 - - 2014-08-06 - Cory Fields - qt: fix unicode character display on osx when building with 10.7 sdk *71a36303d - - 2014-08-04 - Cory Fields - build: fix race in 'make deploy' for windows *077295498 - - 2014-08-04 - Cory Fields - build: Fix 'make deploy' when binaries haven't been built yet *ffdcc4d7d - - 2014-08-04 - Cory Fields - build: hook up qt translations for static osx packaging *25a7e9c90 - - 2014-08-04 - Cory Fields - build: add --with-qt-translationdir to configure for use with static qt *11cfcef37 - - 2014-08-04 - Cory Fields - build: teach macdeploy the -translations-dir argument, for use with static qt *4c4ae35b1 - - 2014-07-23 - Cory Fields - build: Find the proper xcb/pcre dependencies *942e77dd2 - - 2014-08-06 - Cory Fields - build: silence mingw fpic warning spew *e73e2b834 - - 2014-06-27 - Huang Le - Use async name resolving to improve net thread responsiveness *c88e76e8e - - 2014-07-23 - Cory Fields - build: don't let libtool insert rpath into binaries *18e14e11c - - 2014-08-05 - ntrgn - build: Fix windows configure when using --with-qt-libdir *bb92d65c4 - - 2014-07-31 - Cory Fields - test: don't let the port number exceed the legal range *62b95290a - - 2014-06-18 - Cory Fields - test: redirect comparison tool output to stdout *cefe447e9 - - 2014-07-22 - Cory Fields - gitian: remove unneeded option after last commit *9347402ca - - 2014-07-21 - Cory Fields - build: fix broken boost chrono check on some platforms *c9ed039cf - - 2014-06-03 - Cory Fields - build: fix whitespace in pkg-config variable *3bcc5ad37 - - 2014-06-03 - Cory Fields - build: allow linux and osx to build against static qt5 *01a44ba90 - - 2014-07-17 - Cory Fields - build: silence false errors during make clean *d1fbf7ba2 - - 2014-07-08 - Cory Fields - build: fix win32 static linking after libtool merge *005ae2fa4 - - 2014-07-08 - Cory Fields - build: re-add AM_LDFLAGS where it's overridden *37043076d - - 2014-07-02 - Wladimir J. van der Laan - Fix the Qt5 build after d95ba75 *f3b4bbf40 - - 2014-07-01 - Wladimir J. van der Laan - qt: Change serious messages from qDebug to qWarning *f4706f753 - - 2014-07-01 - Wladimir J. van der Laan - qt: Log messages with type>QtDebugMsg as non-debug *98e85fa1f - - 2014-06-06 - Pieter Wuille - libsecp256k1 integration *5f1f2e226 - - 2020-02-17 - John Nash - Merge branch 'switch_verification_code' into Build *1f30416c9 - - 2014-02-07 - Pieter Wuille - Also switch the (unused) verification code to low-s instead of even-s. *1c093d55e - - 2014-06-06 - Cory Fields - secp256k1: Add build-side changes for libsecp256k1 *7f3114484 - - 2014-06-06 - Cory Fields - secp256k1: add libtool as a dependency *2531f9299 - - 2020-02-17 - John Nash - Move network-time related functions to timedata.cpp/h *d003e4c57 - - 2020-02-16 - John Nash - build: fix build weirdness after 54372482. *7035f5034 - - 2020-02-16 - John Nash - Add ::OUTPUT_SIZE *2a864c4d8 - - 2014-06-09 - Cory Fields - crypto: create a separate lib for crypto functions *03a4e4c70 - - 2014-06-09 - Cory Fields - crypto: explicitly check for byte read/write functions *a78462a2a - - 2014-06-09 - Cory Fields - build: move bitcoin-config.h to its own directory *a885721c4 - - 2014-05-31 - Pieter Wuille - Extend and move all crypto tests to crypto_tests.cpp *5f308f528 - - 2014-05-03 - Pieter Wuille - Move {Read,Write}{LE,BE}{32,64} to common.h and use builtins if possible *0161cc426 - - 2014-05-01 - Pieter Wuille - Add built-in RIPEMD-160 implementation *deefc27c0 - - 2014-04-28 - Pieter Wuille - Move crypto implementations to src/crypto/ *d6a12182b - - 2014-04-28 - Pieter Wuille - Add built-in SHA-1 implementation. *c3c4f9f2e - - 2014-04-27 - Pieter Wuille - Switch miner.cpp to use sha2 instead of OpenSSL. *b6ed6def9 - - 2014-04-28 - Pieter Wuille - Remove getwork() RPC call *0a09c1c60 - - 2014-04-26 - Pieter Wuille - Switch script.cpp and hash.cpp to use sha2.cpp instead of OpenSSL. *8ed091692 - - 2014-04-20 - Pieter Wuille - Add a built-in SHA256/SHA512 implementation. *0c4c99b3f - - 2014-06-21 - Philip Kaufmann - small cleanup in src/compat .h and .cpp *ab1369745 - - 2014-06-13 - Cory Fields - sanity: hook up sanity checks *f598c67e0 - - 2014-06-13 - Cory Fields - sanity: add libc/stdlib sanity checks *b241b3e13 - - 2014-06-13 - Cory Fields - sanity: autoconf check for sys/select.h *cad980a4f - - 2019-07-03 - John Nash - build: Add a top-level forwarding target for src/ objects *f4533ee1c - - 2019-07-03 - John Nash - build: qt: split locale resources. Fixes non-deterministic distcheck *4a0e46e76 - - 2019-06-29 - John Nash - build: fix version dependency *2f61699d9 - - 2019-06-29 - John Nash - build: quit abusing AMCPPFLAGS *99b60ba49 - - 2019-06-29 - John Nash - build: avoid the use of top and abs_ dir paths *c8f673d5d - - 2019-06-29 - John Nash - build: Tidy up file generation output *5318bce57 - - 2019-06-29 - John Nash - build: nuke Makefile.include from orbit *672a25349 - - 2019-06-29 - John Nash - build: add stub makefiles for easier subdir builds *562b7c5a6 - - 2020-02-08 - John Nash - build: delete old Makefile.am's *066120079 - - 2020-02-08 - John Nash - build: Switch to non-recursive make
Whew! No wonder it's taken the dev team a while! :)
TL;DR: Trying to fix MacOS Catalina font display led to requiring all kinds of work to migrate and evolve the Reddcoin Core software with Apple, Bitcoin and QT components. Lots of work done, v3.1 public release soon. Also other exciting things and ReddID back under active dev effort.
submitted by TechAdept to reddCoin [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 Unlimited 1.7.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.7.0, October 11th, 2019) from:
 
https://www.bitcoinunlimited.info/download
https://github.com/BitcoinUnlimited/BitcoinUnlimited/releases/tag/bucash1.7.0.0
 
This is a major release of Bitcoin Unlimited compatible with the upcoming protocol upgrade of the Bitcoin Cash network. You could find November 15th, 2019 upgrade specifications here:
This is list of the main changes that have been merged in this release:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.7.0.md
 
PS Ubuntu PPA repository is currently being updated to serve for 1.7.0
(*) if you were using BU with -txindex, after the fist session after the upgrade the database where the index are stored will be upgraded to a new format. During this migration RPC command will return an error message saying the txindex is syncing. The lasting of the migration process depends on the machine where BU is installed.
submitted by s1ckpig to btc [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]

To the people criticising the Bitcoin Foundation and its membership.

Bitcoin is open and decentralised. The legitimacy of The Bitcoin Foundation is by popular acceptance only, just like the blockchain.
If people really think there is a problem with the Foundation, then create a competing one. Find people and companies you respect and nominate them. Donate money to pay people to run it. Fund active Bitcoin development. Make a difference. Prove that your new foundation is beneficial to the ecosystem.
submitted by peterjoel to Bitcoin [link] [comments]

Bitcoin Unlimited 1.7.0 has just been released

Download the latest Bitcoin Cash compatible release of Bitcoin Unlimited (1.7.0, October 11th, 2019) from:
 
https://www.bitcoinunlimited.info/download
https://github.com/BitcoinUnlimited/BitcoinUnlimited/releases/tag/bucash1.7.0.0
 
This is a major release of Bitcoin Unlimited compatible with the upcoming protocol upgrade of the Bitcoin Cash network. You could find November 15th, 2019 upgrade specifications here:
This is list of the main changes that have been merged in this release:
 
Release notes: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/dev/doc/release-notes/release-notes-bucash1.7.0.md
 
PS Ubuntu PPA repository is currently being updated to serve for BUcash 1.7.0
submitted by s1ckpig to Bitcoincash [link] [comments]

Bisq not connecting to local bitcoind

Hi, I run Bisq 1.1.7 (and before it's predecessor with the same problem) on my linux box, and I have problems connecting to my local bitcoind. The log says:
Oct-12 21:33:59.240 [PeerGroup Thread] INFO o.b.c.PeerGroup: Attempting connection to [127.0.1.1]:8333 (0 connected, 1 pending, 1 max)
Oct-12 21:33:59.241 [NioClientManager] INFO o.b.n.NioClientManager: Connected to /127.0.1.1:8333
Oct-12 21:33:59.241 [NioClientManager] INFO o.b.core.Peer: Announcing to /127.0.1.1:8333 as: /bitcoinj:0.14.7.bisq.1-SNAPSHOT/Bisq:1.1.7/
Oct-12 21:33:59.241 [NioClientManager] INFO o.b.core.Peer: [127.0.1.1]:8333: Got version=70015, subVer='/Satoshi:0.18.1/', services=0x1037, time=2019-10-12 21:33:59, blocks=599090
Oct-12 21:33:59.241 [NioClientManager] INFO o.b.c.PeerGroup: [127.0.1.1]:8333: New peer (1 connected, 0 pending, 1 max)
Oct-12 21:33:59.242 [NioClientManager] INFO o.b.c.PeerGroup: Setting download peer: [127.0.1.1]:8333
Oct-12 21:33:59.242 [NioClientManager] INFO o.b.c.l.DownloadProgressTracker: Chain download switched to [127.0.1.1]:8333
Oct-12 21:33:59.287 [NioClientManager] INFO o.b.c.PeerGroup: [127.0.1.1]:8333: Peer died (0 connected, 0 pending, 1 max)
Oct-12 21:33:59.287 [NioClientManager] INFO o.b.c.PeerGroup: Download peer died. Picking a new one.
Oct-12 21:33:59.288 [NioClientManager] INFO o.b.c.PeerGroup: Unsetting download peer: [127.0.1.1]:8333
Oct-12 21:33:59.288 [PeerGroup Thread] INFO o.b.c.PeerGroup: Waiting 1000 msec before next connect attempt to [127.0.0.1]:8333

The GUI shows the "connected peer" flickering on and off, the status line on the bottom shows "Bitcoin network peers: [0/1]" flickering between 0 and 1, and the radiobuttons for selecting a bitcoind greyed out, so I can't edit anything in the GUI. I tried the --rpcXXXX commandline options with no change. My node is fully synced and not pruned.
netstat shows:
tcp 0 0 127.0.0.1:83320.0.0.0:* LISTEN 8542/bitcoin-qt
tcp 0 0 0.0.0.0:83330.0.0.0:* LISTEN 8542/bitcoin-qt
with 8332 being the rpc port.
Any ideas?
submitted by kbdwarrior to bisq [link] [comments]

Running eclair with bitcoin-qt. (Ubuntu)

Trying to get eclair (lightning serveapp gui) to run and having issues. Seems I need to run qt in server mode so it can run the RPC server. Doing this in the command line however launches Bitcoin qt again and it attempts to reindex the whole blockchain (even though it's run from same location)... What am I doing wrong?
Interested also if anyone is running qt on Ubuntu and also attempting to experiment with lightning ...tips tricks etc..
submitted by hungdoge to Bitcoin [link] [comments]

9. bitcoind Bitcoin-QT wallet review Dev++ 01-08-EN  Remote Procedure Calls (RPC) - Anditto Heristyo 4. Installing Bitcoin Core on Linux Bitcoin-qt .NET - C# wrapper - how to use

Bitcoin-Qt ist ein Open-Source-Projekt und derzeit einer der sichersten Vertreter unter den Mining-Clients. Hier müssen Sie sich nicht um eventuelle Angriffe auf Ihr virtuelles Geld sorgen. Ebenfalls Open-Source und vertrauenswürdig ist Electrum.Das Tool punktet mit einer 2-Faktor-Authentifizierung, dem Support von Add-ons und der Möglichkeit, Ihre Keys jederzeit in andere Bitcoin-Clients ... Bitcoin Core is a community-driven free software project, released under the MIT license. Verify release signatures Download torrent Source code Show version history. Bitcoin Core Release Signing Keys v0.8.6 - 0.9.2.1 v0.9.3 - 0.10.2 v0.11.0+ Or choose your operating system. Windows exe - zip. Mac OS X dmg - tar.gz. Linux (tgz) 64 bit. ARM Linux 64 bit - 32 bit. Linux (Snap Store) Support ... Bitcoin Core 0.17.0. If the following options are not in a section, they will only apply to mainnet: addnode=, connect=, port=, bind=, rpcport=, rpcbind= and wallet=.The options to choose a network (regtest= and testnet=) must be specified outside of sections.‘label’ and ‘account’ APIs for wallet Bitcoin Core ist ein gemeinschaftliches, freies Software-Projekt, veröffentlicht unter der MIT-Lizenz. Release-Signaturen überprüfen Download über Torrent Quelltext Versionshistorie anzeigen. Bitcoin Core Release Signierschlüssel v0.8.6 - 0.9.2.1 v0.9.3 - 0.10.2 v0.11.0+ Oder wählen Sie Ihr Betriebssystem . Windows exe - zip. Mac OS X dmg - tar.gz. Linux (tgz) 64 bit. ARM Linux 64 bit ... Bitcoin core wallet RPC console commands – Bitcoin-qt client API call lists. coinguides Follow on Twitter October 21, 2020. 0 1 . Facebook Twitter LinkedIn Pinterest Reddit. In this article we’ll share some of the basic commands that you can use to interact with your Bitcoin core RPC console. Bitcoin core QT client is the original Bitcoin wallet and a full node that has features most other ...

[index] [47528] [19968] [17848] [40291] [26117] [9558] [13450] [7321] [46900] [1107]

9. bitcoind

In this video from http://www.secureyourwallet.com we do a full review of the original Satoshi Bitcoin wallet. We do an install, look at the blockchain data,... Bitcoin JSON-RPC Tutorial 4 - Command Line Interface - Duration: 5:14. m1xolyd1an Recommended for you. 5:14. Bitcoin Lightning Network Tutorial Part 1 - Setup Bitcoind - Duration: 15:10. ... Programming Bitcoin-qt using the RPC api (1 of 6) - Duration: 3:17. Lars Holdgaard 4,643 views. 3:17. Language: English Location: United States Restricted Mode: Off History Help About ... JSON RPC Calls with Bitcoin qt (4 of 6) - Duration: 4:25. Lars Holdgaard 6,166 views. 4:25. Pomp Podcast #256: Billionaire Chamath Palihapitiya on How To Invest in This Crisis - Duration: 1:22:42. ... Programming Bitcoin-qt using the RPC api (1 of 6) - Duration: 3:17. Lars Holdgaard 4,678 views. 3:17. Great Lecture: Alan Watts - Veil Of Thoughts [FULL] (WISDOM) - Duration: 1:13:11. ...

#