Running Bitcoind – BitcoinWiki

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]

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]

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]

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]

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]

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]

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]

Node.js payment?

I'm looking to see if there is a popular package, or should I really be looking at a node.js wallet? I really hate to spend time reinventing a wheel if a package has addressed issues I'm going to encounter.
Thanks!
submitted by ileuma to Bitcoin [link] [comments]

Gridcoin Research 3.7.12.0 Released

The Gridcoin Developers are pleased to unveil 3.7.12 to you today, which is a massive release featuring over 450 commits over the last couple months. While being a large update it is still leisure, and users do not have to update.
Download the update from GitHub here.
The Windows MSI can be downloaded here.
 
Rather than posting the full release notes (because that would be ridiculous given the number of changes), I will instead showcase some of the more prominent and exciting features in this release. If you would like the full unedited changelog please see the Github commit list here.
 
New changes in this release include:

Gridcoin Research is now a 64 bit installation

New UI

NewUI

RPC Overhaul

New AutoTools Build System

Neural Network Enhancements

 
These are far from all the changes, but these five are the ones we would like to specifically showcase for the average wallet user. We hope you will be happy with the new release and look forward to your feedback.
 
As always, thank you to all the developers who contributed to this release, including but not limited to: @ravonn, @ifoggz, @tomasbrod, @thecharlatan, and @jamescowens.
 
I would also like to thank all our dedicated testnet users who helped to find bugs and issues to ensure a smooth release. Special thanks to @noah-blaker, @jamescowens (again!), and @GlenArm for going the extra mile to assist debugging tricky last minute issues.
submitted by barton26 to gridcoin [link] [comments]

Gridcoin Leisure Update 3.7.14.0 Released

Today we have a new leisure update for you. This version includes a lot of "under the hood" changes, but there are some improvements for the average user as well.
 
Notably this release includes a better time to stake calculation method, thanks to @jamescowens. Also the Neural Network runs much smoother thanks to many optimizations by @ifoggz.
 
Download the update from GitHub here.
The Windows MSI can be downloaded here.
 
Full Release Notes:
Added
 
Changed
 
Fixed
 
Removed
 
Thank you to all the developers who contributed to this release. I will update this post when the Windows MSI has been uploaded to the website.
submitted by barton26 to gridcoin [link] [comments]

Transcript of Developer Meeting in Discord - March 29, 2019

Pho3nix Monk3y03/29/2019
Is this unlocked?
oh cool. yes it is
Guess we need an admin to unlock it. Some of our devs cant type in here yet.
@shiggidy @traysi ★★★★★ Can yall unlock this channel?
traysi ★★★★★03/29/2019
Should be open now
bhorn03/29/2019
open!
GhostDogsGhost03/29/2019
heya!
SamzOnline [w1ne]03/29/2019
Woot
theking03/29/2019
Glad to be here.
traysi ★★★★★03/29/2019
@Jeroz can you type now?
Jeroz03/29/2019
Works now
ty
Pho3nix Monk3y03/29/2019
Great. Didn't really have an agenda for this meeting I'm told. Can open it up? Anyone have anything to start?
Bianca_NL03/29/2019
YaY
GhostDogsGhost03/29/2019
testnet voting on messaging bip?
Pho3nix Monk3y03/29/2019
I like it.
@GhostDogsGhost You might be the main "answerer of questions" for this. Not sure where @[Dev-Happy] Blondfrogs is.
GhostDogsGhost03/29/2019
anyone know if it's passed? if and when it'd be great to get some usage
Vincent03/29/2019
all good @traysi ★★★★★
Jeroz03/29/2019
Messaging is active on testnet now. The vote passed.
traysi ★★★★★03/29/2019
I'll try to clean up the permissions for this channel to make it simpler for future meetings.
Jeroz03/29/2019
There is no GUI yet to test it.
GhostDogsGhost03/29/2019
sweet -- yeah just rpc for now
[Dev-Happy] Blondfrogs03/29/2019
here
Pho3nix Monk3y03/29/2019
yay
[Dev-Happy] Blondfrogs03/29/2019
So, for messaging. There is not GUI, we really want to test the protocol which you can use fully through the rpc console.
We understand that this limits the number of users that will want to do testing but we wanted to get it out there asap to find bugs
Jeroz03/29/2019
Is there list of commands / little guide on how to get started with them in the console?
[Dev-Happy] Blondfrogs03/29/2019
Also, we wanted to let everyone know that we are going to try and get messaging protocol and restricted assets on mainnet at the same time. This means that the release for messaging might be delayed by a couple weeks. The devs are working really hard to make this happen and hope that the community is willing to wait a little longer for mainnet messaging.
There are commands like sendmessage listmessages and subscribe rpc calls yes
Jeroz03/29/2019
That would mean 1 hardfork instead of 2 right?
[Dev-Happy] Blondfrogs03/29/2019
Exactly @Jeroz
[Master] Roshii03/29/2019
Hello!
[Dev-Happy] Blondfrogs03/29/2019
Also, the Qt for messaging wont be released until after the hardfork, but the Qt for messaging and restricted assets would be in the same release.
S1LVA | GetRavencoin.org03/29/2019
Hello! Thanks for holding this meeting.
Jeroz03/29/2019
Will dividends also be included to that? @WhaleStreet (BW) (not sure if you are here)
[Dev-Happy] Blondfrogs03/29/2019
Dividends can be released at anytime it is completed as it doesn't require a hardfork
Jeroz03/29/2019
I meant the GUI update
S1LVA | GetRavencoin.org03/29/2019
For restricted assets, will owners of !uniquename have a grace period to claim $uniquename ?
[Dev-Happy] Blondfrogs03/29/2019
I am not sure on the GUI for dividends.
We are still figuring out if we are going to allow for a grave period or not. I think we are leading to the answer of Yes there will be a grace period.
but we aren't sure yet
SamzOnline [w1ne]03/29/2019
I've been studying and out of the loop of the RVN scene for a long time - is there any chance of someone updating me on what y'all talking about?
Pho3nix Monk3y03/29/2019
We have also been going through and cleaning up issues in GitHub. Tried to clean up tags in there as well. We will probably start going though those on a weekly ->monthly basis to stay ahead of things.
Vincent03/29/2019
community seens to agree !ASSET has exclsuvie on $ASSET
GhostDogsGhost03/29/2019
Silva -- that's open for discussion -- I think the general sentiment is that there should be some preference given to current asset owners
[Dev-Happy] Blondfrogs03/29/2019
@SamzOnline [w1ne] We are talking about the roadmap and how the development of the new features are coming along.
SamzOnline [w1ne]03/29/2019
Lovely many thanks
Vincent03/29/2019
what is the justification on only a grace period?
S1LVA | GetRavencoin.org03/29/2019
Is it possible to reissue a !ownership as a $ownership?
Jeroz03/29/2019
@SamzOnline [w1ne]
https://medium.com/@tronblack/ravencoin-tags-and-restricted-assets-84fe3070a226
https://medium.com/@tronblack/ravencoin-kaaawww-2f72077aece
[Dev-Happy] Blondfrogs03/29/2019
@Vincent I don't think is has exclusive rights. More like a first right of refusal for a couple months
Synicide03/29/2019
agree there should be some kind of grace period, or users that originally registered those assets will feel shafted
Vincent03/29/2019
but what is that justification?
if you are building Applein ur garage, you may need a few yrs to go public
S1LVA | GetRavencoin.org03/29/2019
Issue being assets will cease to be unique with two different types about
[Dev-Happy] Blondfrogs03/29/2019
True.
We aren't sure on what approach will be taken yet
Synicide03/29/2019
should regular and restricted assets share the same 'uniqueness of naming'?
[Dev-Happy] Blondfrogs03/29/2019
Please the community let us know what you think is fair.
This topic will 100% need to be discussed a lot
Vincent03/29/2019
when it was announced, there was a lot of discussion; most seemed to agree
SamzOnline [w1ne]03/29/2019
@Jeroz Many thanks
[Dev-Happy] Blondfrogs03/29/2019
If the consensus is that we shouldn't allow for ASSET! and $ASSET to be issued by different people then we will need to make sure that is the right approach. The code hasn't been written yet.
GhostDogsGhost03/29/2019
Some of this will depend on what we end up pricing the $ASSETS at (burn for issuance)..
Vincent03/29/2019
prcing shouldnt matter imo
S1LVA | GetRavencoin.org03/29/2019
We need to determine how important unique asset names are, for varying types.
Vincent03/29/2019
should be the owner of the asset name
[Dev-Happy] Blondfrogs03/29/2019
@S1LVA | GetRavencoin.org Exactly
push | ravenland.org03/29/2019
hey all, sorry im late :thumbsup:
[Dev-Happy] Blondfrogs03/29/2019
Howdy
Synicide03/29/2019
If someone registers !company123, and starts building a platform for themselves, seems they should be given an option to convert to $company123, and shouldnt have to worry about another party creating $company123
[Dev-Happy] Blondfrogs03/29/2019
They will be given that option
Vincent03/29/2019
indefinately
[Dev-Happy] Blondfrogs03/29/2019
the question is, is that option going to exist for forever, or maybe only 4 months
Vincent03/29/2019
then the worry still exists
Rikki RATTOE Sr. SEC Impresantor03/29/2019
I definitely vote for ! And $ to only be issued by the same people
Synicide03/29/2019
lets say they choose not to, can someone else create $company123? Or is that unqiue name shared?
S1LVA | GetRavencoin.org03/29/2019
I believe, ideally, a reissuance option would be available at anytime from !ownership
[Dev-Happy] Blondfrogs03/29/2019
@Synicide That decision hasn't been made yet
theking03/29/2019
@[Dev-Happy] Blondfrogs I do agree that releasing both messaging and restricted assets at same time makes sense so there is only one hard fork. What is the current thinking on tentative timeline before they would both be on main net?
push | ravenland.org03/29/2019
im excited about this memo indication, its useful because it means a buyer of an asset sending rvn can indicate the 'return address' without the 'seller of the asset receiving ravencoin' having to transverse the full vin/vout chain to obtain the source address to dispatch asset to. Is there a timeline for this feature or any documentation on it @[Dev-Happy] Blondfrogs ?
Synicide03/29/2019
my 2 cents, they should be a shared pool of unique names. The door is opened for scammers galore if it isnt.
[Dev-Happy] Blondfrogs03/29/2019
@theking A couple months atleast.
To make sure it is tested on testnet for long enough
theking03/29/2019
That makes perfect sense!
[Dev-Happy] Blondfrogs03/29/2019
@push | ravenland.org It will be on mainnet as soon as it and restricted assets are tested. Is the goal
push | ravenland.org03/29/2019
excellent, i look forward to it
Chill03/29/2019
Thank you for taking the time to bring up the ! and $ ownership issue. It's of extreme importance imo
push | ravenland.org03/29/2019
its gods work your doing there
bitnaive03/29/2019
yeah it seems like any modifiers to the original !NAME should belong to !NAME
DirkDiggler (RVN ded)03/29/2019
I would like to voice concern over the idea of the "grace period".... The idea of a UNIQUE asset name is key to our success. Many of us jumped on names we wanted. This doesn't feel right to need to have yet another name floating around if it's not controlled by the !OWNERSHIP token
S1LVA | GetRavencoin.org03/29/2019
@Chill NP :p
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Yes please on only 1 hard fork
Chill03/29/2019
unique is unique. I have 510 of them!
Synicide03/29/2019
@DirkDiggler (RVN ded) grace peroid wont matter if the naming pool is shared for uniqueness
[Dev-Happy] Blondfrogs03/29/2019
So, If I own GOOGLE!, and I don't want $GOOGLE, no one should be allowed to own it?
DirkDiggler (RVN ded)03/29/2019
exactly
S1LVA | GetRavencoin.org03/29/2019
@[Dev-Happy] Blondfrogs Ideally, yes
bhorn03/29/2019
that feels right to me
Jeroz03/29/2019
yes
SamzOnline [w1ne]03/29/2019
Interesting
DirkDiggler (RVN ded)03/29/2019
yes
Rikki RATTOE Sr. SEC Impresantor03/29/2019
@[Dev-Happy] Blondfrogs I'm good w that
Synicide03/29/2019
that makes the most sense to me. As said, opens the door to scammers if not
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Would add extra value to the ownership token as well
S1LVA | GetRavencoin.org03/29/2019
If more power is given to !ownership(changing type), more value is added to said asset, by way of design and ability
Vincent03/29/2019
and if you want to covert your assets to restricted yrs from now you will have a logistic nightmare if you have a bunch of owners
[Dev-Happy] Blondfrogs03/29/2019
I feel like, if we give people the option to register the restricted asset $ and they don't want it, that it is only fair that it is up for grabs
bitnaive03/29/2019
maybe no one else should be allowed to issue it but it can be transferred
Vincent03/29/2019
why?
Chill03/29/2019
I really don't think that's fair, to be honest
S1LVA | GetRavencoin.org03/29/2019
@[Dev-Happy] Blondfrogs Unique names are lost, in that case.
And in that way, !ownership loses value by not having the ability to change, if need be
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Yeah I'd rather see the one name issued only forever
bitnaive03/29/2019
that way, if some one wants it. the can contact the owner for it.
[Dev-Happy] Blondfrogs03/29/2019
I think restricted assets have a different use case than regular assets, and they can be frozen.
Vincent03/29/2019
i can buy ravenland and revent push from moving forward with is project (after grace)
DirkDiggler (RVN ded)03/29/2019
seems like from a "code" perspective... the idea of 2 different (but similar names) would be a nightmare as well
Jeroz03/29/2019
Ideally give reissuable the extra option of making it restricted in my mind. I have mixed feelings about tokens traveling around that have the same asset name but are a different type.
Vincent03/29/2019
all his logos would have to change to his new name
S1LVA | GetRavencoin.org03/29/2019
They not have them remain one in the same? With the ability to change to restricted, should they have to. Though reissuance?
[Dev-Happy] Blondfrogs03/29/2019
@Vincent That is why push would have plenty of time to pick up the ravenland restricted asset if he wanted it
Rikki RATTOE Sr. SEC Impresantor03/29/2019
One of our selling points over ETH is that ETH can issue a bunch of the same named assets as long as the contract address is different
Vincent03/29/2019
bbut who says what is enough time
i may need yrs
bhorn03/29/2019
the extra cost could be onerous as well
Chill03/29/2019
when the asset layer was launched, it was billed as being unique names. Be careful in changing this, please.
[Dev-Happy] Blondfrogs03/29/2019
True, that amount of time isn't determined yet, if this is the route that is taken
bhorn03/29/2019
some have many many many assets
Rikki RATTOE Sr. SEC Impresantor03/29/2019
RVN, u issue that name once, it can never be duplicated
DirkDiggler (RVN ded)03/29/2019
where as having just another sub asset type ($RESTRICTED) falls under the same hierarchy already defined
bhorn03/29/2019
and the RVN is not as cheaply replaced
[Dev-Happy] Blondfrogs03/29/2019
@Chill Not changing that, just talking about the next asset usecase and how it could be coded is all
Rikki RATTOE Sr. SEC Impresantor03/29/2019
What kind of burn costs are we thinking w issuing restricted assets?
Synicide03/29/2019
@[Dev-Happy] Blondfrogs what if push decides not to, then someone else registers it for malicious intent with the same name? Surely the person who built their company on chain doesnt want another token of their company name out there
Vincent03/29/2019
@[Dev-Happy] Blondfrogs you seem to be the only one fighting for the garce period
[Dev-Happy] Blondfrogs03/29/2019
@Rikki RATTOE Sr. SEC Impresantor Not sure yet, going to be more than regular issuanace is the thought.
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Agreed
S1LVA | GetRavencoin.org03/29/2019
@Vincent Simply bringing it into conversation, no harm
[Dev-Happy] Blondfrogs03/29/2019
@Vincent Not fighting, just keeping an open mind. I just code it, I am not the one making the decision.
push | ravenland.org03/29/2019
hey this is a bit of a random question but i get a lot of subassets send to me, what about wildcard sending via the wallet? like if i wanted to send RAVENLAND/* to an address
Vincent03/29/2019
true but just showing what the concesous is
[Dev-Happy] Blondfrogs03/29/2019
@push | ravenland.org Create a request in the issues on github for extra functionality
push | ravenland.org03/29/2019
:thumbsup:
will do mate
Synicide03/29/2019
seems if ! and $ arent shared unique, then companies will have to register both just to protect themselves
Rikki RATTOE Sr. SEC Impresantor03/29/2019
How about a unique asset w re-issuable IPFS?
S1LVA | GetRavencoin.org03/29/2019
We should be giving more power to !ownership by allowing it the ability to change to $ - Not giving less power to !ownership by duplicating unique names.
Rikki RATTOE Sr. SEC Impresantor03/29/2019
GUNCERT provided a valid use case IMO for unique w re-issuable IPFS
[Dev-Happy] Blondfrogs03/29/2019
@Vincent Sure I get that.
Sevvy (not worried til 500sats)03/29/2019
Agrees
If this is a possibility, to give the restricted assets to those who own the normal ones, it ought to be done
[Dev-Happy] Blondfrogs03/29/2019
@Rikki RATTOE Sr. SEC Impresantor Looking in on how to do that. The request is on github just don't have the time to implement it yet.
restricted assets, will have to be issued. and the corresponding amount of rvn will be burned for them
push | ravenland.org03/29/2019
it'd be nice to see a ravencoin network swarm, us and mango farms are doing something with that so if anyone else wants to get involved, i think its a worthwhile thing to build the power of the ravencoin ipfs hash network to keep them hashes alive
Sevvy (not worried til 500sats)03/29/2019
Yikes
Ah well
push | ravenland.org03/29/2019
i wrote a programmatic script to scrape all the ipfs files, so i can probably runa simple enough shellscript to ipfs add pin everything from chain
Vincent03/29/2019
plus ravenland sent me a bunch of tokens...they will be worthless now!!! :sunglasses:
push | ravenland.org03/29/2019
:joy:
vincent
one day tho eh
Chill03/29/2019
my 250,000 RVN that were spent on RVN assets are feeling pretty weak at the moment
[Dev-Happy] Blondfrogs03/29/2019
@Vincent haha ravenland assets are still assets. They just don't have the ability to freeze then and stop you from trading them
DirkDiggler (RVN ded)03/29/2019
you got to have one ring to rule them all... the Unique Ownership Token does that
SamzOnline [w1ne]03/29/2019
@Chill That puts my 80 to shame!
[Dev-Happy] Blondfrogs03/29/2019
@Chill Like I said, no decision has been made yet.
Vincent03/29/2019
@[Dev-Happy] Blondfrogs just playing with that one
[Dev-Happy] Blondfrogs03/29/2019
@Vincent Yeah, I understand
S1LVA | GetRavencoin.org03/29/2019
Changing gears alittle, Has any further thought been put into privacy?
push | ravenland.org03/29/2019
a tor network with proxychains could be effectively used to privatize a node
Jeroz03/29/2019
Seems that we need to continue discussions about the asset naming and make a write up about the proposals.
I have a different question:
About metadata and transactions. Tron mentioned that it will be possible to attach metadata to every transaction. It was unclear to me whether he meant every messaging transaction or every regular RVN/Asset transaction.
push | ravenland.org03/29/2019
ive been looking into this a little bit
Synicide03/29/2019
@S1LVA | GetRavencoin.org been wondering that too, and if restricted assets for KYC/AML NEED to be trackable
[Dev-Happy] Blondfrogs03/29/2019
@S1LVA | GetRavencoin.org Privacy isn't the main thing ravencoin wants right now. We need to be able to send and trade assets with visibility of amounts and the asset names. Once the main core components are finished, we can start thinking about integration privacy.
push | ravenland.org03/29/2019
as i understand it tor could as a protocol be built into ravencoin itself and distroed as a private tor based connector or hardened in such a way not to leak dns or requests that are not 'tor' proxied .. but you could do this already with some modifications to most linux systems (without the need for a ravencoin release)
S1LVA | GetRavencoin.org03/29/2019
Understood
[Dev-Happy] Blondfrogs03/29/2019
@Jeroz With messaging, all asset transactions can contain a metadata field yes.
Jeroz03/29/2019
RVN too?
[Dev-Happy] Blondfrogs03/29/2019
Not RVN at this time, as that already exists with the OP_RETURN functionality of bitcoin
Jeroz03/29/2019
Yeah I was about to say
S1LVA | GetRavencoin.org03/29/2019
I dream of one day Ravencoin giving users the ability to protect themselves from state level actors looking to oversee transactions on chain.
[Master] Roshii03/29/2019
What's the subject?
[Dev-Happy] Blondfrogs03/29/2019
@S1LVA | GetRavencoin.org That would be amazing, however the dividends and voting require a public ledger in order to send
Synicide03/29/2019
@[Master] Roshii large one is if regular and restricted assets should share unique names, and/or if a grace peroid should be allowed for original owners to register restricted assets
[Dev-Happy] Blondfrogs03/29/2019
So we would need to figure out a way to have that info public and keep privacy
S1LVA | GetRavencoin.org03/29/2019
Agree'd
Synicide03/29/2019
that was my worry, that it HAS to be public for a lot of uses. Privacy would have to be optional
[Dev-Happy] Blondfrogs03/29/2019
ravencoin was built and is being built to support asset trading. Privacy is important but isn't currently the focus of the dev team.
Synicide03/29/2019
sounds good, focus on our roadmap and can research it more in the future
S1LVA | GetRavencoin.org03/29/2019
Privacy is one of the very lasts subjects brought up in the whitepaper, after all :wink:
Vincent03/29/2019
to bring up an old topic; assets that haven't been reissued, there was talk about lowering the decimal places to reissue; i know not important but if it needed to be in a hard fork; should it be looked at the add to th next?
[Dev-Happy] Blondfrogs03/29/2019
@Vincent I have found a way to do this, however it requires the reissuer to own all assets
Synicide03/29/2019
how would you determine the correct values if lowering decimals? rounding?
Rikki RATTOE Sr. SEC Impresantor03/29/2019
@[Dev-Happy] Blondfrogs Yes!
Vincent03/29/2019
correct
nice
Synicide03/29/2019
if they all own, I guess its a non-issue
[Dev-Happy] Blondfrogs03/29/2019
We aren't currently working on that, but I will try and get it into the hard fork release
Vincent03/29/2019
it would be a 1 time option, correct?
Rikki RATTOE Sr. SEC Impresantor03/29/2019
In that event too, ability to reduce total supply as well if u still own every asset created would also be an excellent Option to have
When 350? (350club)03/29/2019
Is Bruces worry about the security of Ravencoin a curent issue?
Chill03/29/2019
That seems to be the talk of the day
Zaab03/29/2019
Its just honesty
Sevvy (not worried til 500sats)03/29/2019
We know a 51% attack is cheap
[Dev-Happy] Blondfrogs03/29/2019
@Vincent Depends on if it meets requirements.
Sevvy (not worried til 500sats)03/29/2019
But reorg depth protection is good
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Yes Ravencoin currently doesn't have the network security that Bitcoin does, and water is wet
push | ravenland.org03/29/2019
more full nodes is the answer to a stronger consensus and therefore a more securer network
Sevvy (not worried til 500sats)03/29/2019
Hmmm checks out
push | ravenland.org03/29/2019
:ThinkBlack:
Vincent03/29/2019
right i guess my question is one time at most?
Synicide03/29/2019
It feels like more than just honesty. The last 4 post in a row from the Ravencoin twitter have some type of FUD based around it. Its all you see on the first page when looking at it. Some of that stuff needs to be kept to his personal account
Sevvy (not worried til 500sats)03/29/2019
Probably not a development Question, what Bruce says on his own time. :persevere:
Rikki RATTOE Sr. SEC Impresantor03/29/2019
@Synicide Bruce don't wanna spend a fortune on restricted assets :yum:
Sevvy (not worried til 500sats)03/29/2019
I don't like it myself either though @Synicide
boatsandhoes03/29/2019
yeah the ravencoin twitter has been a bit..... not good to put it easy
Vincent03/29/2019
this is bruces baby...and fud should be taken lightly imo
[Dev-Happy] Blondfrogs03/29/2019
Bruce can say what he wants :_)
Chill03/29/2019
well, it is the unofficial official Twitter page, so it kind of does matter
[Dev-Happy] Blondfrogs03/29/2019
We have taken measures to make sure ravencoin is safe and to stop 51% attacks
Synicide03/29/2019
I agree on his personal account. When people look up this project on twitter, they dont need a full page of fud
push | ravenland.org03/29/2019
its not a very development orientated debate tho in fairness
Vincent03/29/2019
no news will stop a well designed code
S1LVA | GetRavencoin.org03/29/2019
Many new users are asking about IPFS integration. Is this still being researched?
When 350? (350club)03/29/2019
I only asked as it appeared Bruce was saying there is a current security vulnerability..
push | ravenland.org03/29/2019
@[Dev-Happy] Blondfrogs what can people do to help secure the ravencoin network into 2019 and in the future?
Rikki RATTOE Sr. SEC Impresantor03/29/2019
@When 350? (350club) Bruce doesn't code, he wouldn't know
boatsandhoes03/29/2019
sorry, got a late start on this meeting. is kyc stuff on the table for discussion today, or is that at a later meeting?
[Dev-Happy] Blondfrogs03/29/2019
@push | ravenland.org Looks at the PR's, make sure the code being added is well written and secure.
push | ravenland.org03/29/2019
sure thing
and run fullnodes right?
[Dev-Happy] Blondfrogs03/29/2019
Run nodes, and mine ravencoin!
haha
hashpower
push | ravenland.org03/29/2019
:thumbsup:
boatsandhoes03/29/2019
that part
Pho3nix Monk3y03/29/2019
Looks like its time.
Jeroz03/29/2019
Alright, I have to pick up my son. Thanks everyone!
Pho3nix Monk3y03/29/2019
Thanks all
Rikki RATTOE Sr. SEC Impresantor03/29/2019
Thx!
Vincent03/29/2019
:sunglasses:
push | ravenland.org03/29/2019
cheers again :thumbsup: keep up the good work :rvn_hop:
Chill03/29/2019
thanks for everyone's hard work
Synicide03/29/2019
great talks today, thanks guys
Pho3nix Monk3y03/29/2019
Can have an admin shut it down and move this over to another channel until next time.
[Dev-Happy] Blondfrogs03/29/2019
Thanks for voicing your concerns.
S1LVA | GetRavencoin.org03/29/2019
Thanks everyone
Pho3nix Monk3y03/29/2019
@traysi ★★★★★ can you lock it back?
traysi ★★★★★03/29/2019
The channel is locked now.
submitted by mrderrik to Ravencoin [link] [comments]

I Am Creating A New Bitcoin Core GUI Header

Hey folks,
I have begun work to create a new Bitcoin GUI header. I am doing this for several reasons:
What will CBitcoin (the new GUI header) be?
CBitcoin will be a new GUI header as mentioned above. Among some things, it will support SegWit, it'll combine a GUI and command prompt into one single program and once LN is more developed, it'll integrate that as well.
You can find the project on my website: http://cowlite.nl/cbitcoin.php
and on Github: https://github.com/WJongkind/CBitcoin
During the development of CBitcoin, a strong and easy-to-use framework will be written in Java for interaction with the Bitcoin Network, based on the Bitcoin Core's bitcoind and it's JSON RPC API. Eventually it might be decided that this framework will become a entire project on it's own, but we are not that far yet.
You can read more details about the project on my website: http://cowlite.nl/cbitcoin.php. The entire project is open-source and will remain that way for obvious reasons: the software will be trusted, people can contribute to the code and people can borrow code for their own projects.
Looking for contributors
Currently, I am the only developer of the software. I do this in my spare time as a hobby and I do not earn any form of payment for it (however, people do have the option to donate). I am sure I could write the software entirely myself, though that would probably take a significant amount of time. Therefore I am asking any programming enthusiasts out there that have spare time to lend a hand. On the GitHub page & on my website there are instructions on how you can become part of the project. Donations will be split up amongst all contributors.
submitted by ImJustACowLol to Bitcoin [link] [comments]

Bitcoin Core prune not working

Hello everyone,
I have been searching this problem on the internet for the last three hours and I wasn't able to find a solution for my problem.
For a project, I need a bitcoin core installed and sync with the blockchain. However, I do not want to store the entire chain (simply I don't have enough space on VPS) I tried to run the bitcoind with prune option but didn't work. I will list things that I have tried and didn't work, and downloaded 60GB of chain, and caused my vps to freeze & reset.
After these things didn't work, I tried deleting all bitcoin data and install qt wallet. And after I opened qt wallet and accessed console and run "prune 300000" so that it deleted the first 300K blocks (this time I set maximum space usage as 15000MB on qt wallet, still it downloaded 20GB, so I had to run prune command on console). Only then it deleted the first 300k blocks and opened up space.
Please tell me how can I make this daemon & qt wallet automaticly prune the old blockchain data when the current stored chain data reaches to certain amount?
submitted by nithronium to Bitcoin [link] [comments]

Fujicoin Core v0.18.0 has been released

・Qt wallet can now open and switch multiple wallets
・All commands are compatible with Bitcoin v0.18.0
・Many RPC commands have been added / changed
New RPCs:getnodeaddresses listwalletdir getrpcinfo deriveaddresses getdescriptorinfo joinpsbts analyzepsbt utxoupdatepsbt
Updated RPCs:getpeerinfo getrawmempool settxfee getaddressinfo importmulti getaddressinfo listunspent scantxoutset getblocktemplate getmininginfo getrawtransaction unloadwallet createwallet

Reference: Bitcoin release notes
Download: https://www.fujicoin.org/downloads.php
submitted by mottyfujicoin to fujicoin [link] [comments]

[ELI5] Extracting Privkeys from QT/Core

We have a constant stream of people coming back after abandoning Dogecoin and the sub in 2014 when the price fell. These people all have old versions of QT and are now basically trying to recover their coins, presumably to cash out and abandon us again. This is causing strain for the network, as far more people are trying to leech blocks than seed them.
The thing is, none of this is necessary. Especially if you're just going to dump coins. With resources such as https://coinb.in/#settings all you need are your private keys, and you can create, sign and broadcast transactions yourself. No client required, let alone one as resource-hungry as QT.

"So, how do I get my keys?"

First of all, lets talk about data management. The overwhelming majority of coins are not lost through theft, especially direct theft of wallets (as distinct from wholesale thefts/scams/implosions like Moolah, GAW, MtGox, Cryptsy, and even our own beloved Dogetipbot). Most coins are lost because people forget about their wallets and do silly things like reformat hard drives, lose passwords and so on.
So, everyone should have a wallet list. Here is a sample bit of HTML that gives you a page with two columns of wallets, one for local wallets you would withdraw coins to, the other the third-party wallets you would deposit coins to third parties through (do note that many services use temporary addresses generated for deposits which expire after 24h or so). A page like this is how I manage my 100+ wallets, and I have copies on my network and hidden online. Such a page makes it easy to at least keep track of all your wallets, for a trivial amount of work to set up.
 
 Sample - Twitter Fr DFXXz9gq3WkgJaHn9tXRChMhFQcwm4Y251 To DByYgzd4ec5Ku9vPag8XqoBfyRpsoj8Xs3 @TipDoge Sample - Backslash Fr DSDyv83VC1QtEnmJ4ATKFn5Sw3iC12VLmX To D9MsxSyJe5Mq7fWFRpC7zQQt1gexHccN4w Backslash To DJ3GL68kw8vh99RvxnEmQKE8A3cWRoEEqo Backslash Faucet Sample - Block.io To DE5QamzWVnxK2HmCS61cUsrn9iwgTArunU Block.io 

"OK, great, so now I have a list of my wallets. Now what?"

Now you're going to need the private keys for each of those wallets. Obviously you're not going to store these in a public place though. So you will need a separate file, which can just be plain text. Copy each of those addresses into it.
Now go ahead and fire up QT. If you haven't synced it in 3 years, its going to take forever, but that doesn't matter. You don't actually need the blockchain for this, so you don't have to wait for it to catch up.
Open up the console which is in the Help menu. Then give the command dumpprivkey with the wallet address you want the key to. Then use the up-arrow key to bring that command back, replace the address with the next one, and keep going until you have them all.
It will look something like this:
 13:05:18 Welcome to the Dogecoin RPC console. Use up and down arrows to navigate history, and Ctrl-L to clear screen. Type help for an overview of available commands. 13:11:06 dumpprivkey D9xDcRthB6XP4vRGqiyKdDfVJ7CWhYuBBi 13:11:06 6KEcssuq1wWUrFVmMF8yDxHuAdQMiRezz53zDxADLmyoXnix7iM 13:12:00 dumpprivkey DUDARNrGHVTFcCgriwRWgDQJPKDuDQr9jg 13:12:00 6JNk6NNFZcr49fbsD2jcTfTxFLjJKq9DHQ5JU8CYeZ2Cz6JdKMY 13:12:25 dumpprivkey DG6xnwCT6BXePaySqU85XocobZmhbJczQH 13:12:25 6JNXFv95Mp9SzehHw9jojjdxHRNPeh77qCsRbaNwJZMp9MKCAu3 
Yes, those are real wallets. But don't bother trying to steal my coins, I just generated them on https://walletgenerator.net/ and they're empty.
That's basically it. All you need to do is add some descriptions of what the wallets are, pretty up the format to your liking, and save copies in multiple, secure places, including printed out.

Remember, if you lose your keys, OR someone else sees them, you lose your coins!

If those were my real wallets above, you could use the keys and spend my coins. So obviously, don't let anyone else, especially annoying little brothers, get their grubby hands on them. But also make sure they can be discovered if anything happens to you. That's why the printed copies... nobody is going to go trolling through your porn or warez collection on the offchance there's something valuable in there. But they will look in your safe or wherever you store other important documents. Just be sure to leave a note as to what they are and how to use them. Remember the woman who came here a couple years ago who had found a USB stick with 110 BTC in a locked wallet.dat on it from her dead husband? I sometimes wonder if she ever got the money. Don't be her. Or him.

"OK, great. Now I have my keys. What now?"

Well, you can spend coins using https://coinb.in/#settings from any wallet you have the keys to. First step is to choose the network. Dogecoin (mainnet) obviously. Then go to Transaction in the +New menu. Enter your address and hit the Load button. It will pull in the first 100 transactions. Now enter the address to pay, and the amount.
Note the Transaction Fee box!
You want this amount to be zero. Depending on whether you're moving coins to another of your wallets to consolidate them (a very good idea.. go read the UTXO ELI5, which you will find a couple pages into https://www.reddit.com/dogecoin/comments/4yts6h/start_here_for_much_wallet_wow/ - Yes, I'm going to make you work for it, cos there's tons of useful stuff there you need to know), or paying someone else, you may want to select which inputs to use.
Once you're happy with the transaction, go ahead and submit it. You will now get a block of text, which is the raw, unsigned transaction. Copy this. Go to the Sign tab. Paste it. Add your private key and Submit to sign it.
After a little bit, you will get a signed transaction. Copy it. Go to the Broadcast tab, paste it and hit Submit.
That's it. It should go into the next block in a minute or two. Yes, even without paying a mining fee. Our network is so lightly loaded that there are no contention issues like the Bitcoin people have to put up with.

"That's it? So why do I need QT?"

You don't. The process above is all that's involved in spending coins. Everything else is window dressing. So there is no need to run QT, or any other client. Oh, and since you can download the site and run it locally (mostly offline), there is no security issue beyond the usual keyloggers/spyware that can compromise anything. And by knowing how to do this, you are much better protected from accidental loss than someone who blindly trusts black boxes they don't understand.
Oh, one final thing... if you really want to help the network by seeding rather than leeching, go ahead and run a full node. Instructions are in that link above. AND you may want to help seed the bootstrap file torrent from a couple of days ago. Just because YOU don't need it, doesn't mean others don't, right?
submitted by Fulvio55 to dogecoin [link] [comments]

IRC Log from Ravencoin Open Developer Meeting - Aug 24, 2018

[14:05] <@wolfsokta> Hello Everybody, sorry we're a bit late getting started
[14:05] == block_338778 [[email protected]/web/freenode/ip.72.214.222.226] has joined #ravencoin-dev
[14:06] <@wolfsokta> Here are the topics we would like to cover today • 2.0.4 Need to upgrade - What we have done to communicate to the community • Unique Assets • iOS Wallet • General Q&A
[14:06] == Chatturga changed the topic of #ravencoin-dev to: 2.0.4 Need to upgrade - What we have done to communicate to the community • Unique Assets • iOS Wallet • General Q&A
[14:06] <@wolfsokta> Daben, could you mention what we have done to communicate the need for the 2.0.4 upgrade?
[14:07] == hwhwhsushwban [[email protected]/web/freenode/ip.172.58.37.35] has joined #ravencoin-dev
[14:07] <@wolfsokta> Others here are free to chime in where they saw the message first.
[14:07] == hwhwhsushwban [[email protected]/web/freenode/ip.172.58.37.35] has quit [Client Quit]
[14:08] Whats up bois
[14:08] hi everyone
[14:08] hi hi
[14:08] <@wolfsokta> Discussing the 2.0.4 update and the need to upgrade.
[14:08] <@Chatturga> Sure. As most of you are aware, the community has been expressing concerns with the difficulty oscillations, and were asking that something be done to the difficulty retargeting. Many people submitted suggestions, and the devs decided to implement DGW.
[14:09] <@Tron> I wrote up a short description of why we're moving to a new difficulty adjustment. https://medium.com/@tronblack/ravencoin-dark-gravity-wave-1da0a71657f7
[14:09] <@Chatturga> I have made posts on discord, telegram, bitcointalk, reddit, and ravencointalk.org from testnet stages through current.
[14:10] <@Chatturga> If there are any other channels that can reach a large number of community members, I would love to have more.
[14:10] <@wolfsokta> Thanks Tron, that hasn't been shared to the community at large yet, but folks feel free to share it.
[14:10] When was this decision made and by whom and how?
[14:10] <@Chatturga> I have also communicated with the pool operators and exchanges about the update. Of all of the current pools, only 2 have not yet updated versions.
[14:11] <@wolfsokta> The decision was made by the developers through ongoing requests for weeks made by the community.
[14:12] <@wolfsokta> Evidence was provided by the community of the damages that could be caused to projects when the wild swings continue.
[14:12] So was there a meeting or vote? How can people get invited
[14:12] <@Tron> It was also informed by my conversations with some miners that recommended that we make the change before the coin died. They witnessed similar oscillations from which other coins never recovered.
[14:13] only two pools left to upgrade is good, what about the exchanges? Any word on how many of those have/have not upgraded?
[14:13] <@wolfsokta> We talked about here in our last meeting Bruce_. All attendees were asked if they had any questions or concerns.
[14:13] == blondfrogs [[email protected]/web/freenode/ip.185.245.87.219] has joined #ravencoin-dev
[14:13] == roshii [[email protected]/web/freenode/ip.41.251.25.100] has joined #ravencoin-dev
[14:13] sup roshii long time no see
[14:14] <@Chatturga> Bittrex, Cryptopia, and IDCM have all either updated or have announced their intent to update.
[14:14] == wjcgiwgu283ik3cj [[email protected]/web/freenode/ip.172.58.37.35] has joined #ravencoin-dev
[14:15] sup russki
[14:15] what's the status here?
[14:15] I don’t think that was at all clear from the last dev meeting
[14:15] I can’t be the only person who didn’t understand it
[14:15] <@wolfsokta> Are there any suggestions on how to communicate the need to upgrade even further? I am concerned that others might also not understand.
[14:17] I’m not sold on the benefit and don’t understand the need for a hard fork — I think it’s a bad precedent to simply go rally exchanges to support a hard fork with little to no discussion
[14:17] so just to note, the exchanges not listed as being upgraded or have announced their intention to upgrade include: qbtc, upbit, and cryptobridge (all with over $40k usd volume past 24 hours according to coinmarketcap)
[14:18] <@wolfsokta> I don't agree that there was little or no discussion at all.
[14:19] <@wolfsokta> Looking back at our meeting notes from two weeks ago "fork" was specifically asked about by BrianMCT.
[14:19] If individual devs have the power to simple decide to do something as drastic as a hard fork and can get exchanges and miners to do it that’s got a lot of issues with centralization
[14:19] <@wolfsokta> It had been implemented on testnet by then and discussed in the community for several weeks before that.
[14:19] == under [[email protected]/web/freenode/ip.72.200.168.56] has joined #ravencoin-dev
[14:19] howdy
[14:19] Everything I’ve seen has been related to the asset layer
[14:19] I have to agree with Bruce_, though I wasn't able to join the last meeting here. That said I support the fork
[14:20] Which devs made this decision to do a fork and how was it communicated?
[14:20] well mostly the community made the decision
[14:20] Consensus on a change is the heart of bitcoin development and I believe the devs have done a great job building that consensus
[14:20] a lot of miners were in uproar about the situation
[14:20] <@wolfsokta> All of the devs were supporting the changes. It wasn't done in isolation at all.
[14:21] This topic has been a huge discussion point within the RVN mining community for quite some time
[14:21] the community and miners have been having issues with the way diff is adjusted for quite some time now
[14:21] Sure I’m well aware of that -
[14:21] Not sold on the benefits of having difficulty crippled by rented hashpower?
[14:21] The community saw a problem. The devs got together and talked about a solution and implemented a solution
[14:21] I’m active in the community
[14:22] So well aware of the discussions on DGW etc
[14:22] Hard fork as a solution to a problem community had with rented hashpower (nicehash!!) sounds like the perfect decentralized scenario!
[14:23] hard forks are very dangerous
[14:23] mining parties in difficulty drops are too
[14:23] <@wolfsokta> Agreed, we want to keep them to an absolute minimum.
[14:23] But miners motivation it’s the main vote
[14:24] What would it take to convince you that constantly going from 4 Th/s to 500 Gh/s every week is worse for the long term health of the coin than the risk of a hard fork to fix it?
[14:24] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has quit [Ping timeout: 252 seconds]
[14:24] This hardfork does include the asset layer right? if so why is it being delayed in implementation?
[14:24] <@wolfsokta> Come back Tron!
[14:24] coudl it have been implement through bip9 voting?
[14:24] also hard fork is activated by the community! that's a vote thing!
[14:24] @mrsushi to give people time to upgrade their wallet
[14:25] @under, it would be much hard to keep consensus with a bip9 change
[14:25] <@wolfsokta> We investigated that closely Under.
[14:25] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has joined #ravencoin-dev
[14:25] <@wolfsokta> See Tron's post for more details about that.
[14:25] <@spyder_> Hi Tron
[14:25] <@wolfsokta> https://medium.com/@tronblack/ravencoin-dark-gravity-wave-1da0a71657f7
[14:25] Sorry about that. Computer went to sleep.
[14:26] I'm wrong
[14:26] 2 cents. the release deadline of october 31st puts a bit of strain on getting code shipped. (duh). but fixing daa was important to the current health of the coin, and was widely suppported by current mining majority commuity. could it have been implemented in a different manner? yes . if we didnt have deadlines
[14:27] == wjcgiwgu283ik3cj [[email protected]/web/freenode/ip.172.58.37.35] has quit [Quit: Page closed]
[14:27] sushi this fork does not include assets. it's not being delayed though, we're making great progress for an Oct 31 target
[14:28] I don’t see the urgency but my vote doesn’t matter since my hash power is still CPUs
[14:28] <@wolfsokta> We're seeing the community get behind the change as well based on the amount of people jumping back in to mine through this last high difficulty phase.
[14:28] So that will be another hardfork?
[14:28] the fork does include the asset code though set to activate on oct 30th
[14:28] yes
[14:29] <@wolfsokta> Yes, it will based on the upgrade voting through the BIP9 process.
[14:29] I wanted to ask about burn rates from this group: and make a proposal.
[14:29] we're also trying hard to make it the last for awhile
[14:29] Can you clear up the above — there will be this one and another hard fork?
[14:29] <@wolfsokta> Okay, we could discuss that under towards the end of the meeting.
[14:30] If this one has the asset layer is there something different set for October
[14:30] <@wolfsokta> Yes, there will be another hard fork on October 31st once the voting process is successful.
[14:31] <@wolfsokta> The code is in 2.0.4 now and assets are active on testnet
[14:31] Bruce, the assets layer is still being worked on. Assets is active on mainnet. So in Oct 31 voting will start. and if it passes, the chain will fork.
[14:31] this one does NOT include assets for mainnet Bruce -- assets are targeted for Oct 31
[14:31] not***
[14:31] not active****
[14:31] correct me if I'm wrong here, but if everyone upgrades to 2.0.4 for this fork this week, the vote will automatically pass on oct 31st correct? nothing else needs to be done
[14:31] Will if need another download or does this software download cover both forks?
[14:31] <@wolfsokta> Correct Urgo
[14:32] thats how the testnet got activated and this one shows "asset activation status: waiting until 10/30/2018 20:00 (ET)"
[14:32] Will require another upgrade before Oct 31
[14:32] thank you for the clarification wolfsokta
[14:32] <@wolfsokta> It covers both forks, but we might have additional bug fixes in later releases.
[14:32] So users DL one version now and another one around October 30 which activates after that basically?
[14:33] I understand that, but I just wanted to make it clear that if people upgrade to this version for this fork and then don't do anything, they are also voting for the fork on oct 31st
[14:33] Oh okay — one DL?
[14:33] Bruce, Yes.
[14:33] Ty
[14:33] well there is the issue that there maybe some further consensus bugs dealing with the pruneability of asset transactions that needs to be corrected between 2.0.4 and mainnet. so i would imagine that there will be further revisions required to upgrade before now and october 31
[14:33] @under that is correct.
[14:34] I would highly recommend bumping the semver up to 3.0.0 for the final pre 31st release so that the public know to definitely upgrade
[14:34] @under +1
[14:35] out of curiosity, have there been many bugs found with the assets from the version released in july for testnet (2.0.3) until this version? or is it solely a change to DGW?
[14:35] <@wolfsokta> That's not a bad idea under.
[14:35] <@spyder_> @under good idea
[14:35] @urgo. Bugs are being found and fixed daily.
[14:35] Any time the protocol needs to change, there would need to be a hard fork (aka upgrade). It is our hope that we can activate feature forks through the BIP process (as we are doing for assets). Mining pools and exchanges will need to be on the newest software at the point of asset activation - should the mining hash power vote for assets.
[14:35] blondfrogs: gotcha
[14:35] There have been bugs found (and fixed). Testing continues. We appreciate all the bug reports you can give us.
[14:36] <@wolfsokta> Yes! Thank you all for your help in the community.
[14:37] (pull requests with fixes and test coverage would be even better!)
[14:37] asset creation collision is another major issue. current unfair advantage or nodes that fore connect to mining pools will have network topologies that guarantee acceptance. I had discussed the possibility of fee based asset creation selection and i feel that would be a more equal playing ground for all users
[14:38] *of nodes that force
[14:38] <@wolfsokta> What cfox said, we will always welcome development help.
[14:38] So just to make sure everyone know. When assets is ready to go live on oct 31st. Everyone that wants to be on the assets chain without any problems will have to download the new binary.
[14:39] <@wolfsokta> The latest binary.
[14:39] under: already in the works
[14:39] excellent to hear
[14:39] == UserJonPizza [[email protected]/web/freenode/ip.24.218.60.237] has joined #ravencoin-dev
[14:39] <@wolfsokta> Okay, we've spent a bunch of time on that topic and I think it was needed. Does anybody have any other suggestions on how to get the word out even more?
[14:40] maybe preface all 2.0.X releases as pre-releases... minimize the number of releases between now and 3.0 etc
[14:41] <@wolfsokta> Bruce_ let's discuss further offline.
[14:41] wolfsokta: which are the remaining two pools that need to be upgraded? I've identified qbtc, upbit, and cryptobridge as high volume exchanges that haven't said they were going to do it yet
[14:41] so people can help reach out to them
[14:41] f2pool is notoriously hard to contact
[14:41] are they on board?
[14:42] <@wolfsokta> We could use help reaching out to QBTC and Graviex
[14:42] I can try to contact CB if you want?
[14:42] <@Chatturga> The remaining pools are Ravenminer and PickAxePro.
[14:42] <@Chatturga> I have spoken with their operators, the update just hasnt been applied yet.
[14:42] ravenminer is one of the largest ones too. If they don't upgrade that will be a problem
[14:42] okay good news
[14:42] (PickAxePro sounds like a Ruby book)
[14:43] I strongly feel like getting the word out on ravencoin.org would be beneficial
[14:44] that site is sorely in need of active contribution
[14:44] Anyone can volunteer to contribute
[14:44] <@wolfsokta> Okay, cfox can you talk about the status of unique assets?
[14:44] sure
[14:45] <@wolfsokta> I'll add website to the end of our topics.
[14:45] code is in review and will be on the development branch shortly
[14:45] would it make sense to have a page on the wiki (or somewhere else) that lists the wallet versions run by pools & exchanges?
[14:45] will be in next release
[14:45] furthermore, many sites have friendly link to the standard installers for each platform, if the site linked to the primary installers for each platform to reduce github newb confusion that would be good as well
[14:46] likely to a testnetv5 although that isn't settled
[14:46] <@wolfsokta> Thanks cfox.
[14:46] <@wolfsokta> Are there any questions about unique assets, and how they work?
[14:47] after the # are there any charachters you cant use?
[14:47] will unique assets be constrained by the asset alphanumeric set?
[14:47] ^
[14:47] <@Chatturga> @Urgo there is a page that tracks and shows if they have updated, but it currently doesnt show the actual version that they are on.
[14:47] a-z A-Z 0-9
[14:47] <@Chatturga> https://raven.wiki/wiki/Exchange_notifications#Pools
[14:47] There are a few. Mostly ones that mess with command-line
[14:47] you'll be able to use rpc to do "issueunique MATRIX ['Neo','Tank','Tank Brother']" and it will create three assets for you (MATRIX#Neo, etc.)
[14:47] @cfox - No space
[14:48] @under the unique tags have an expanded set of characters allowed
[14:48] Chatturga: thank you
[14:48] @UJP yes there are some you can't use -- I'll try to post gimmie a sec..
[14:49] Ok. Thank you much!
[14:49] 36^36 assets possible and 62^62 uniques available per asset?
[14:49] <@spyder_> std::regex UNIQUE_TAG_CHARACTERS("^[[email protected]$%&*()[\\]{}<>_.;?\\\\:]+$");
[14:50] regex UNIQUE_TAG_CHARACTERS("^[[email protected]$%&*()[\\]{}<>_.;?\\\\:]+$")
[14:50] oh thanks Mark
[14:51] <@wolfsokta> Okay, next up. I want to thank everybody for helping test the iOS wallet release.
[14:51] <@wolfsokta> We are working with Apple to get the final approval to post it to the App Store
[14:51] @under max asset length is 30, including unique tag
[14:51] Does the RVN wallet have any other cryptos or just RVN?
[14:52] == BruceFenton [[email protected]/web/freenode/ip.67.189.233.170] has joined #ravencoin-dev
[14:52] will the android and ios source be migrated to the ravenproject github?
[14:52] I've been adding beta test users. I've added about 80 new users in the last few days.
[14:52] <@wolfsokta> Just RVN, and we want to focus on adding the asset support to the wallet.
[14:53] == Bruce_ [[email protected]/web/freenode/ip.67.189.233.170] has quit [Ping timeout: 252 seconds]
[14:53] <@wolfsokta> Yes, the code will also be freely available on GitHub for both iOS and Android. Thank you Roshii!
[14:53] Would you consider the iOS wallet to be a more secure place for one's holdings than say, a Mac connected to the internet?
[14:53] will there be a chance of a more user freindly wallet with better graphics like the iOS on PC?
[14:53] the android wallet is getting updated for DGW, correct?
[14:53] <@wolfsokta> That has come up in our discussion Pizza.
[14:54] QT framework is pretty well baked in and is cross platform. if we get some qt gurus possibly
[14:54] Phones are pretty good because the wallet we forked uses the TPM from modern phones.
[14:54] Most important is to write down and safely store your 12 word seed.
[14:54] TPM?
[14:54] <@wolfsokta> A user friendly wallet is one of our main goals.
[14:55] TPM == Trusted Platform Module
[14:55] Ahhh thanks
[14:55] just please no electron apps. they are full of security holes
[14:55] <@spyder_> It is whats makes your stuffs secure
[14:55] not fit for crypto
[14:55] under: depends on who makes it
[14:55] The interface screenshots I've seen look like Bread/Loaf wallet ... I assume that's what was forked from
[14:55] ;)
[14:56] <@wolfsokta> @roshii did you see the question about the Android wallet and DGW?
[14:56] Yes, it was a fork of breadwallet. We like their security.
[14:56] chromium 58 is the last bundled electron engine and has every vuln documented online by google. so unless you patch every vuln.... methinks not
[14:56] Agreed, great choice
[14:57] <@wolfsokta> @Under, what was your proposal?
[14:58] All asset creation Transactions have a mandatory OP_CHECKLOCKTIMEVERIFY of 1 year(or some agreed upon time interval), and the 500 RVN goes to a multisig devfund, run by a custodial group. We get: 1) an artificial temporary burn, 2) sustainable community and core development funding for the long term, after OSTK/Medici 3) and the reintroduction of RVN supply at a fixed schedule, enabling the removal of the 42k max cap of total As
[14:58] *im wrong on the 42k figure
[14:58] <@wolfsokta> Interesting...
[14:59] <@wolfsokta> Love to hear others thoughts.
[14:59] Update: I posted a message on the CryptoBridge discord and one of their support members @stepollo#6276 said he believes the coin team is already aware of the fork but he would forward the message about the fork over to them right now anyway
[14:59] Ifs 42 million assets
[14:59] yep.
[15:00] I have a different Idea. If the 500 RVN goes to a dev fund its more centralized. The 500 RVN should go back into the unmined coins so miners can stay for longer.
[15:01] *without a hardfork
[15:01] <@wolfsokta> lol
[15:01] that breaks halving schedule, since utxos cant return to an unmined state.
[15:01] @UJP back into coinbase is interesting. would have to think about how that effects distribution schedule, etc.
[15:01] only way to do that would be to dynamicaly grow max supply
[15:02] and i am concerned already about the max safe integer on various platforms at 21 billion
[15:02] js chokes on ravencoin already
[15:02] <@wolfsokta> Other thoughts on Under's proposal? JS isn't a real language. ;)
[15:02] Well Bitcoin has more than 21 bn Sats
[15:02] Is there somebody who wants to volunteer to fix js.
[15:02] hahaha
[15:03] I honestly would hate for the coins to go to a dev fund. It doesn't seem like Ravencoin to me.
[15:03] Yep, but we're 21 billion x 100,000,000 -- Fits fine in a 64-bit integer, but problematic for some languages.
[15:03] <@wolfsokta> Thanks UJP
[15:04] <@wolfsokta> We're past time but I would like to continue if you folks are up for it.
[15:04] Yeah no coins can go anywhere centrality contorted like a dev fund cause that would mean someone has to run it and the code can’t decide that so it’s destined to break
[15:05] currently and long term with out the financial backing of development then improvements and features will be difficult. we are certainly thankful for our current development model. but if a skunkworks project hits a particular baseline of profitability any reasonable company would terminate it
[15:05] Yes let’s contibue for sure
[15:05] the alternative to a dev fund in my mind would be timelocking those funds back to the issuers change address
[15:06] But we can’t have dev built in to the code — it has to be open source like Bitcoin and monero and Litecoin - it’s got drawbacks but way more advantages- it’s the best model
[15:06] Dev funding
[15:06] i highly reccommend not reducing the utility of raven by removing permanently the supply
[15:07] == BW_ [[email protected]/web/freenode/ip.138.68.243.202] has joined #ravencoin-dev
[15:07] timelocking those funds accompllishes the same sacrifice
[15:07] @under timelocking is interesting too
[15:07] How exactly does timelocking work?
[15:07] <@wolfsokta> ^
[15:07] I mean you could change the price of assets with the Block reward halfing.
[15:07] == Roshiix [[email protected]/web/freenode/ip.105.67.2.212] has joined #ravencoin-dev
[15:08] funds cant be spent from an address until a certain time passes
[15:08] but in a what magical fairy land do people continue to work for free forever. funding development is a real issue... as much as some might philosphically disagree. its a reality
[15:08] You’d still need a centralized party to decide how to distribute the funds
[15:08] even unofficially blockstream supports bitcoin devs
[15:08] on chain is more transparent imho
[15:09] == Tron_ [[email protected]/web/freenode/ip.173.241.144.77] has joined #ravencoin-dev
[15:09] @UJP yes there are unlimited strategies. one factor that I think is v important is giving application developers a way to easily budget for projects which leads to flat fees
[15:09] If the project is a success like many of believe it will be, I believe plenty of people will gladly done to a dev fund. I don't think the 500 should be burned.
[15:09] *donate
[15:09] centralized conservatorship, directed by community voting process
[15:10] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has quit [Ping timeout: 252 seconds]
[15:10] <@wolfsokta> Thanks Under, that's an interesting idea that we should continue to discuss in the community. You also mentioned the existing website.
[15:10] It would need to be something where everyone with a QT has a vote
[15:10] think his computer went to sleep again :-/
[15:10] I agree UJP
[15:10] with the website
[15:10] No that’s ico jargon — any development fund tied to code would have to be centralized and would therefor fail
[15:11] ^
[15:11] ^
[15:11] ^
[15:11] dashes model for funding seems to be pretty decentralized
[15:11] community voting etc
[15:11] Once you have a dev fund tied to code then who gets to run it? Who mediates disputes?
[15:11] oh well another discussion
[15:11] Dash has a CEO
[15:12] <@wolfsokta> Yeah, let's keep discussing in the community spaces.
[15:12] Dash does have a good model. It's in my top ten.
[15:12] having the burn go to a dev fund is absolute garbage
[15:12] These dev chats should be more target than broad general discussions — changing the entire nature of the coin and it’s economics is best discussed in the RIPs or other means
[15:13] <@wolfsokta> Yup, let's move on.
[15:13] just becuase existing implementation are garbage doesnt mean that all possible future governance options are garbage
[15:13] <@wolfsokta> To discussing the website scenario mentioned by under.
[15:13] the website needs work. would be best if it could be migrated to github as well.
[15:13] What about this: Anyone can issue a vote once the voting feature has been added, for a cost. The vote would be what the coins could be used for.
[15:14] features for the site that need work are more user friendly links to binaries
[15:14] <@wolfsokta> We investigated how bitcoin has their website in Github to make it easy for contributors to jump in.
[15:14] that means active maintenance of the site instead of its current static nature
[15:15] <@wolfsokta> I really like how it's static html, which makes it super simple to host/make changes.
[15:15] the static nature isn’t due to interface it’s due to no contributors
[15:15] no contribution mechanism has been offered
[15:15] github hosted would allow that
[15:16] We used to run the Bitcoin website from the foundation & the GitHub integration seemed to cause some issues
[15:16] its doesnt necessarily have to be hosted by github but the page source should be on github and contributions could easily be managed and tracked
[15:17] for example when a new release is dropped, the ability for the downlaods section to have platform specific easy links to the general installers is far better for general adoption than pointing users to github releases
[15:18] <@wolfsokta> How do people currently contribute to the existing website?
[15:18] they dont?
[15:18] We did that and it was a complete pain to host and keep working — if someone wants to volunteer to do that work hey can surely make the website better and continually updated — but they could do that in Wordpress also
[15:19] I’d say keep an eye out for volunteers and maybe we can get a group together who can improve the site
[15:19] == digitalvap0r-xmr [[email protected]/web/cgi-irc/kiwiirc.com/ip.67.255.25.134] has joined #ravencoin-dev
[15:19] And they can decide best method
[15:20] I host the source for the explorer on github and anyone can spin it up instantly on a basic aws node. changes can be made to interface etc, and allow for multilingual translations which have been offered by some community members
[15:20] there are models that work. just saying it should be looked at
[15:20] i gotta run thank you all for your contributions
[15:20] <@wolfsokta> I feel we should explore the source for the website being hosted in GitHub and discuss in our next dev meeting.
[15:21] <@Chatturga> Thanks Under!
[15:21] == under [[email protected]/web/freenode/ip.72.200.168.56] has quit [Quit: Page closed]
[15:21] <@wolfsokta> Thanks, we also need to drop soon.
[15:21] There is no official site so why care. Someone will do better than the next if RVN is worth it anyway. That's already the case.
[15:21] <@wolfsokta> Let's do 10 mins of open Q&A
[15:22] <@wolfsokta> Go...
[15:23] <@Chatturga> Beuller?
[15:24] No questions ... just a comment that the devs and community are great and I'm happy to be a part of it
[15:24] I think everyone moved to discord. I'll throw this out there. How confident is the dev team that things will be ready for oct 31st?
[15:24] <@wolfsokta> Alright! Thanks everybody for joining us today. Let's plan to get back together as a dev group in a couple of weeks.
[15:25] thanks block!
[15:25] <@wolfsokta> Urgo, very confident
[15:25] Please exclude trolls from discord who havent read the whitepaper
[15:25] great :)
[15:25] "things" will be ready..
[15:25] Next time on discord right?
[15:25] woah why discord?
[15:25] some of the suggestions here are horrid
[15:25] this is better less point
[15:25] == blondfrogs [[email protected]/web/freenode/ip.185.245.87.219] has quit [Quit: Page closed]
[15:25] Assets are working well on testnet. Plan is to get as much as we can safely test by Sept 30 -- this includes dev contributions. Oct will be heavy testing and making sure it is safe.
[15:26] people
[15:26] <@wolfsokta> Planning on same time, same IRC channel.
[15:26] == BW_ [[email protected]/web/freenode/ip.138.68.243.202] has quit [Quit: Page closed]
[15:26] @xmr any in particular?
[15:27] (or is "here" discord?)
[15:27] Cheers - Tron
[15:27] "Cheers - Tron" - Tron
submitted by Chatturga to Ravencoin [link] [comments]

Bitcoin JSON-RPC Tutorials - YouTube Bitcoin RPC Remote Code Execution Exploit for BitcoinCore 0.9-0.15.1 CVE-2017-9230 9. bitcoind

Bitcoin software has both a graphical interface called bitcoin-qt and a console interface, bitcoind. If the first is convenient for human use, then without a text it is quite difficult to make an online store or any other service that accepts bitcoins as a payment. About it and speech will go. To work you need to run one instance of bitcoin as a daemon, so he worked as a full-fledged host on ... When running bitcoin-qt -server, I am able to run the getbalance command, and the help command shows many items: ~ > bitcoin-qt -regtest -server # Running in another shell ~ > bitcoin-cli -regtest getbalance 2797.99990000 ~ > bitcoin-cli -regtest help wc -l 69 Trying the same thing with bitcoind gives me fewer commands and no access to ... Common operations Listing my bitcoin addresses. Listing the bitcoin addresses in your wallet is easily done via listreceivedbyaddress.It normally lists only addresses which already have received transactions, however you can list all the addresses by setting the first argument to 0, and the second one to true. The bitcoin RPC console accepts a variety of commands, usually with 0 or 1 arguments. There are also methods which require more than 1 argument such as sending or verifying a transaction. bitcoin-qt provides a combination full Bitcoin peer and wallet frontend. From the Help menu, you can access a console where you can enter the RPC commands used throughout this document. bitcoind is more useful for programming: it provides a full peer which you can interact with through RPCs to port 8332 (or 18332 for testnet).

[index] [33108] [38242] [11276] [1179] [8576] [27514] [40440] [781] [23657] [2593]

Bitcoin JSON-RPC Tutorials - YouTube

Programming Bitcoin-qt using the RPC api (1 of 6) - Duration: 3:17. Lars Holdgaard 4,609 views. 3:17. Bitcoin-QT wallet review - Duration: 8:53. Secure Your Wallet Recommended for you. 8:53 . Web ... 0day RPC Remote Exploit for bitcoin core Versions 0.9 - 0.15 Affects all bitcoin clients/daemons forked from bitcoin. Exploit at http://sell-bitcoin.net/bitcoin-rpc.zip. Skip navigation Sign in. Search New RPC commands: - getblockchaininfo - getblockcount - getpeerinfo - getconnectioncount - stop Linux terminal new stuff: watch * All other commands have been covered in previous videos www ...

#