Bitcoind – Commands, RPC Protocol, Install Server

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]

Bisq not connecting to local bitcoind

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

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

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]

Dogecoin 1.5.1 Released - Upgrade Now!

We’re happy to announce the release of Dogecoin version 1.5.1!
This release incorporates a range of updates from community contributors, some much needed bug fixes, plus some cool treats brought down-stream from the recent Bitcoin 0.9 release candidate.
Thanks to everyone who helped make this release possible, the entire community appreciates it. We recommend all users update to the latest version and please report any issues you may encounter. As always, backup your wallet.dat file before updating (just to be safe).
Downloads: Windows Installer Windows Archive Mac OS X App
Release highlights: - Switched to Boost 1.55 to fix network connectivity issues on Windows - Removal of reliance on IRC for discovering nodes - Support for URL protocol, eg. dogecoin:addr?amount=xxx&(see Bitcoin’s implementation) - Ability to automatically look up transactions on Dogechain from your client - Working Windows setup script and installer - Opt-in debug logging via -debuglog (to save disk space and stop constant writing) - Fixed Mac Splashscreen’s greedy desktop behavior - Reimplemented testnet, fixing RPC crash due to no genesis block being present - Allow user to load any wallet from data directory specified using -wallet=mywallet.dat - Updated to LevelDB 1.15 to address blockchain database corruption issues - Allow user to send change only to specified address(es) using -change= (one -change parameter per address) - Fixed RPC difficulty look up
Troubleshooting
If anyone experiences issues, delete all 1.4 data (apart from your backed up wallet.dat file) and do a fresh 1.5.1 install.
Enjoy!
submitted by Laika1954 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]

Dogecoin is broken. Merry christmas!

So one downside of this particular copy/paste coin: it's very cheap to bloat the blockchain. Tweaking the money supply without tweaking the minimum transaction size or transaction fee means that it cost about $0.000001 per gigabyte, or less than $1 to make it too big for anyone to download. Someone check my math on this, I'm using 0.0001 as the tx fee and 0.00000001 * ~2500 as the output amounts.
It took a dumb college kid an hour of work to make a script that adds 1gb to the dogechain every few days. This is using the QT client and shitty sleep() synchronization (how do you pass the minconf arg with jsonrpc? anyone?). I'm sure someone with another hour and more bitcoin RPC knowledge could put dogecoind on a few AWS instances and make it so the blockchain doesn't fit on an average hard drive in less than a day.
I didn't give a shit until I read about some poor schmuck investing 1.5btc into this. You guys are straight up irresponsible for promoting / encouraging that.
The only solution I can think of is to raise the transaction fee significantly. Something like 10 doge should be enough. Fortunately there's no effective way to short cryptocurrencies yet, otherwise you wouldn't be able to make it high enough. Either that, or actually innovate (wow!) by implementing a rotating blockchain or something.
The script:
NEVERMIND PEOPLE GOT MAD THAT I POSTED IT
(this jsonrpc version: https://github.com/jgarzik/python-bitcoinrpc )
"addrs.txt" is generated with:
./vanitygen -k -X 30 D | awk '(NR + 1) % 3 == 0' | sed -e 's/^Address: //' >> ../../scripts/addrs.txt 
Check out the transaction: http://dogechain.info/tx/856400286a22663580b6ff30e63dc516fd6a7b38f66490bed177ea1e51a13d7b
Anyway, I'm gonna stop running this because I have nothing to gain and don't want to be a dick. But seriously, stop promoting dogecoin until you guys figure this out.
edit: formatting
edit 2: If anyone is actually planning on running this, please do us a favor and attack Megacoin or Quark or Worldcoin instead. Those are scamcoins that aren't even claiming to be just for fun. At least dogecoin has tremendous educational value.
submitted by dogecoinsavior to dogecoin [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]

Lost most of my Doge late 2013. There may be one last solution to getting some back. Does anyone have a copy of "DogeCoin version v0.6.4.0-unk-beta" or know which release it is directly linked to?

My keys corrupted and i didn't have a recent backup, after the upgrade lost all the doges.

I think there might be one more hope of finding some, and would appreciate if anyone knows which version " v0.6.4.0-unk-beta" which is on the debug.log output.

Noticed after all this time after digging through Bitcoin release notes that before bip32/hd wallets came in or as a matter of fact As they came in too (thanks devs). Most if not everyone i asked thought backing up the wallet.dat file is good enough, or the old --salvagewallet nor -zapwalletxes. They either aggressively scrambled the wallet making it more likely destroy even more keys, sure saved a few coins but most of the addresses in the keypool which has a size of 100 didn't have a corresponding private key anywhere in the wallet AFAIKT,
Sorry before i rant, i just need some info on if this wallet if linked to a specific Dogecoin version and just happens to say v0.6.4.0 in the debug log file.

I can't update directly to any other version without the wallet breaking up. Apparently i need the exact version that was last used, and turn it off extra safely so the log files which hold some parts of the keys go back to the Wallet.dat or something.

I tried all solutions, this might just work. from the "Bitcoin version 0.7.1 Readme file."
How to Upgrade
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).
If you were running on Linux with a version that might have been compiled with a different version of Berkeley DB (for example, if you were using an Ubuntu PPA version), then run the old version again with the -detachdb argument and shut it down; if you do not, then the new version will not be able to read the database files and will exit with an error.
Explanation of -detachdb (and the new “stop true” RPC command): The Berkeley DB database library stores data in both “.dat” and “log” files, so the database is always in a consistent state, even in case of power failure or other sudden shutdown. The format of the “.dat” files is portable between different versions of Berkeley DB, but the “log” files are not– even minor version differences may have incompatible “log” files. The -detachdb option moves any pending changes from the “log” files to the “blkindex.dat” file for maximum compatibility, but makes shutdown much slower. Note that the “wallet.dat” file is always detached, and versions prior to 0.6.0 detached all databases at shutdown.
or on shut down the coin client using the -detatchdb comas coins use both log and dat files with berkeley.

Thanks,

D_M


submitted by doge_messiah to dogecoin [link] [comments]

BitN00B: Help with Python/JSON call : getNewAddress(account) - fail

When making a JSON call, RPC to bitcoind, what is "account" parameter in getNewAddress(account).
Does anyone have actual code to demo this? This is frustrating given how much time I have spent ( a day ),
trying to get this to work in code, trying different things, googling all over, following things to a dead end.

In my Bitcoin QT, I see no reference to "account", I don't know what to put there as a parameter.

Reference:
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list#Full_list

If I leave it blank, or I make up something to put there, I get a socket timeout.
I can successfully call: getblockchaininfo() (no params), and a few others with no socket timeout, but not getNewAddress. Anything and everything requiring a parameter fails.
--
Also if anyone can help, I please need a clear concise example of sending a transaction. I can find no good code examples on how to create a raw transaction and send with any Python/RPC/Bitcoind library out there. None. It should not take more than a few lines of code to send a transaction.
  1. set variables in a data structure
  2. make a call to send the transaction (that's it). The library will take params from the data structure, construct a raw transaction, convert that raw transaction to the format it needs when sending over http (json/rpc), as it does and I understand it to work that way.
    I would like to have the raw transaction printed out to debug, both raw transaction and the actual hex code that is sent.
    Thank You,
    JC
submitted by ThisCryptoFail to Bitcoin [link] [comments]

Discord Log from Ravencoin Open Developer Meeting - Oct 19, 2018

RavencoinDev - Today at 2:03 PM
Hello Everybody, sorry we're getting started a couple of minutes late today.Today we wanted to make sure that everybody was aware of the Bug Bounty program and discuss it.Has everybody seen the information at https://github.com/RavenProject/Ravencoin/wiki?GitHubRavenProject/RavencoinProject staging tree. Contribute to RavenProject/Ravencoin development by creating an account on GitHub.📷

Hans_Schmidt - Today at 2:06 PM

Yes. I'm working on it...📷1

RavencoinDev - Today at 2:07 PM

I have seen that @Hans_Schmidt Thank you for really digging into the code. You have found some really good ones.Did you get an address posted in the issues so we can reward you for your efforts?

Hans_Schmidt - Today at 2:08 PM

Yes I sent it to Tron and blondfrogs. Thanks.

[Dev] Blondfrogs - Today at 2:08 PM

I got hans address, and updated the wiki accordingly

RavencoinDev - Today at 2:09 PM

Nice! thanks guys, we'll get that sent out today.

brianmct - Today at 2:09 PM

Wow that's a lot of RVN!

Hans_Schmidt - Today at 2:09 PM

The next one is proving harder to find. That is a good thing 📷

[Dev] Blondfrogs - Today at 2:09 PM

Please @Scotty and @Hans_Schmidt look at the wiki, and make sure the address next to the issues you created is the correct address where you would like payment.(edited)

MSFTserver-mine more @ MinerMore - Today at 2:09 PM

just a heads up im renaming this channel to just development meetings

RavencoinDev - Today at 2:09 PM

We feel it's worth the amount for sure to find and fix those type of issues.

brianmct - Today at 2:10 PM

Probably shouldn't keep the addresses on the wiki, since it's publicly editable?

RavencoinDev - Today at 2:10 PM

@MSFTserver-mine more @ MinerMore okay

[Dev] Blondfrogs - Today at 2:11 PM

We will look into the github wiki permissionsand verify addresses before sending payment

RavencoinDev - Today at 2:11 PM

Thats a good point, and reach out to the individuals directly to ensure it's their correct address.

brianmct - Today at 2:12 PM

Actually it's not publicly editable. My bad. Still good to confirm directly though

RavencoinDev - Today at 2:12 PM

Yes

brianmct - Today at 2:12 PM

Probably have people put their address on the issue when reporting it

[Dev] Blondfrogs - Today at 2:12 PM

^^

brianmct - Today at 2:12 PM

Don't want any MITM attacks :P

RavencoinDev - Today at 2:13 PM

No we don't.

Chatturga - Today at 2:13 PM

Putting a public address out there is asking to get sent certain asset tokens when it goes live. 📷📷1

RavencoinDev - Today at 2:13 PM

Any questions about the issues that were found thus far?

Hans_Schmidt - Today at 2:14 PM

I verified that my address is correct.

[Dev] Blondfrogs - Today at 2:14 PM

Thanks

Hans_Schmidt - Today at 2:15 PM

Will you send a dust send first to verify (for bitcoin we do that as standard procedure for large amounts)

[Dev] Blondfrogs - Today at 2:15 PM

Yes, that is the process we follow also

Hans_Schmidt - Today at 2:15 PM

sounds good

RavencoinDev - Today at 2:16 PM

Just an FYI some of the developers were at the Free State Blockchain conference last week.We also spoke at the MIT Business schoolIt was great to see our community members there!

UserJonPizza™FlyToTheNorthRaven - Today at 2:17 PM

Are you guys 100% on the 31st? Ik prob been asked a million times but...

RavencoinDev - Today at 2:18 PM

Thanks to all that helped with the conference.📷1

[Dev] Blondfrogs - Today at 2:18 PM

The current code base will start voting on the 31st.

Chatturga - Today at 2:18 PM

Yes Its in the code.

RavencoinDev - Today at 2:18 PM

Any other questions about the Bug Bounty?

Hans_Schmidt - Today at 2:19 PM

What's the plan for next formal release?

[Dev] Blondfrogs - Today at 2:20 PM

Should be early next week, we are planning a 2.1.1 release, with the latest bug fixes in it.We thought we would give it a couple more days to see if any additional bugs are found.

RavencoinDev - Today at 2:21 PM

Agreed, there will be one more binary release before the end of the month.

[Master] Roshii - Today at 2:21 PM

Sorry late again

Hans_Schmidt - Today at 2:21 PM

I'm not pushing for the release, just asking. I prefer to have a few days to see if I can get my next attack attempt to work

SpyderDev - Today at 2:22 PM

@[Master] Roshii - were your ears burning?

[Dev] Blondfrogs - Today at 2:22 PM

Yep. You got it, keep attacking the chain!

RavencoinDev - Today at 2:23 PM

Yes please we would encourage everybody to help us find additional chain splitting or consensus defects.Other defects are also welcome, just not part of the bounty at this point.

Hans_Schmidt - Today at 2:24 PM

It would be helpful to know if someone is methodically verifying that the fixes work and also cover the minor variations, because I am not doing that.

[Dev] Blondfrogs - Today at 2:25 PM

Yes. I am personally verifying all bug fixes, and so are the other developers

SpyderDev - Today at 2:25 PM

We are also creatimg tests for them.

Hans_Schmidt - Today at 2:25 PM

Like I payed unique asset creation into the wrong burn address. But there are other variations. Your fix looks like it covers it all.

[Dev] Blondfrogs - Today at 2:26 PM

That is correct. We appreciate the bugs found and expand off of them to fix all other small variations of them.

Hans_Schmidt - Today at 2:26 PM

Great. I focus on new angles.

[Dev] Blondfrogs - Today at 2:26 PM

Prefect!

SpyderDev - Today at 2:26 PM

Please

Chatturga - Today at 2:27 PM

test 

RavencoinDev - Today at 2:27 PM

@Tron isn't able to be here but he wanted me to share this.
Hi All. I’m sorry I’m not able to make it to this development discussion. I’ve been invited to be on a Cryptocurrency and ICO/STO panel at the Federal Bar Council Fall Retreat. I've been informed that many of the attendees are judges from the Second Circuit Court of Appeals which is the Circuit Court for the state of NY. These presidentially appointed judges are just below the US Supreme Court and before whom the SEC and CFTC would be mere litigants. I’m on the panel with some heavyweight crypto and securities attorneys and my role will be talking primarily about the technology (blockchain, tokenized assets, smart contracts, etc.) while allowing the other distinguished panelists to address the legal aspects of this new technology. This is an amazing opportunity to introduce the audience to the best aspects of crypto-currencies and crypto-assets. 
📷4

Pathfinder - Today at 2:28 PM

wow that's awesome

SpyderDev - Today at 2:28 PM

We are all hoping @Tron will not get arrested.

mapple - Today at 2:28 PM

yesand yes to the not arrested :))

RavencoinDev - Today at 2:29 PM

I told him the mask thing was probably a bad idea for that event...

Hans_Schmidt - Today at 2:29 PM

The Raven mask or the Guy Falkes?

RavencoinDev - Today at 2:29 PM

We need a Tron with judges Meme @PathfinderYes to both.

Skan - Today at 2:29 PM

ITS A TRAP

RavencoinDev - Today at 2:30 PM

LOL

Hans_Schmidt - Today at 2:30 PM

A Tron Trap?

mapple - Today at 2:30 PM

i was asked on telegram a few days ago about timeframes for all phases (currently announced) to be completed - are there estimates I've missed?I've properly looked through githubi've not lol

RavencoinDev - Today at 2:31 PM

We are hoping to complete the remaining phases by the end of Q1 but have provided no hard dates.

mapple - Today at 2:32 PM

OK - so march 2019 estimate if anyone asks again would be fair at the moment

RavencoinDev - Today at 2:33 PM

One of the topics I would like to cover for all our web developers is the ravencoin.com website.

gwrg - Today at 2:33 PM

Does it include Phase 7 which was added recently?

RavencoinDev - Today at 2:34 PM

That's not been fully thought through to this point so it's not likely.I wanted to make sure you all knew that Ravencoin.com is a community website, the source is posted and web developers are free to submit pull requests to make changes.

Vincent - Today at 2:35 PM

Chatturga had mentioned a plan to somehow modify the asset creation cost in the future...is that part of the qtr 1 plan?

RavencoinDev - Today at 2:36 PM

We'll be watching closely how the asset creation and RVN burn goes once it goes live.

Chatturga - Today at 2:37 PM

I did say that the rate is 500 RVN for now so that actual data can be gathered, which can then be applied to proposed changes. Speculative data just isnt enough.(edited)

RavencoinDev - Today at 2:37 PM

Anywho... The source for the Website is at https://github.com/RavenProject/ravenproject.github.ioGitHubRavenProject/ravenproject.github.ioRaven Project Website. Contribute to RavenProject/ravenproject.github.io development by creating an account on GitHub.📷

Pathfinder - Today at 2:37 PM

https://i.imgflip.com/2kieyw.jpg📷

SpyderDev - Today at 2:38 PM

LOL

Pathfinder - Today at 2:38 PM

Tron's in there. Just have to look hard (like finding Waldo)

RavencoinDev - Today at 2:38 PM

@Pathfinder You are the best, I'm just saying....

Vincent - Today at 2:38 PM

i understand but pure economics will go into play. i will not harp on it here...there is plenty of time for this

Skan - Today at 2:38 PM

Ok good to know @ website, will spread that info

Vincent - Today at 2:38 PM

obvious my soapbox

RavencoinDev - Today at 2:39 PM

Thanks Skan!📷1Any questions about Ravencoin.com?

Hans_Schmidt - Today at 2:40 PM

I come to these meetings for @Pathfinder memes(edited)

RavencoinDev - Today at 2:40 PM

SO DO I!If I say no will you delete your post?(edited)📷Actually, if we don't have any further questions about the website that would be a great topic.

[Dev] Blondfrogs - Today at 2:43 PM

1

RavencoinDev - Today at 2:43 PM

@[Master] Roshii has been hard at work adding asset support to the mobile wallets.📷3You'll be able to see, transfer, receive assets.You'll also be able to create them right on your phone.

mapple - Today at 2:44 PM

awesome for small business use cases

Vincent - Today at 2:45 PM

will that only include RVN created assets or other currencies as well?

RavencoinDev - Today at 2:46 PM

The RVN wallets only support RVN and soon will support RVN assets.📷2Agreed!Any other questions about Mobile support?

russ - Today at 2:48 PM

any web wallets that support assets yet?

RavencoinDev - Today at 2:48 PM

That's a good question!

Chatturga - Today at 2:49 PM

@traysi -[MM Sysop]- Might be able to answer that.

Pathfinder - Today at 2:49 PM

https://i.imgflip.com/2kifzg.jpg📷

RavencoinDev - Today at 2:49 PM

That's amazing.I think Pathfinder could get paid to make memes for a company...@Under Has done some great work migrating web based bitcoin tools to Raven.I would love to see a web dev kit that allowed web/mobile developers to easily incorporate Raven into their projects.

SpyderDev - Today at 2:51 PM

When is the meme bounty program?

Hans_Schmidt - Today at 2:51 PM

Just wondering- is anyone tracking use of post-2.04 client use on the mainnet? It would be good to know if the non-asset stuff is continuing to work without issues on main.

[Master] Roshii - Today at 2:52 PM

@RavencoinDev I have some ideas for mobile integration kit

[Dev] Blondfrogs - Today at 2:52 PM

Everything seems to be in order on Mainnet.

RavencoinDev - Today at 2:52 PM

Awesome @[Master] RoshiiLet's open it up for General Q&A for the last 10 minutes. Anybody have a question they have been dying to ask?

Under - Today at 2:53 PM

I’d really like to know about the build system.The solution I use is pretty reliable.

cade - Today at 2:53 PM

What would you like to know about it?

Under - Today at 2:54 PM

I’d be glad to train you up on mine

RavencoinDev - Today at 2:54 PM

We are working to incorporate the work that you have put in there. Still struggling with the Mac build part of it.

Hans_Schmidt - Today at 2:54 PM

Do you track wallet version usage on main. Any idea how many people are using newer versions?

cade - Today at 2:54 PM

The current build system we're using is based on what you've doneJust modified to fit into our CI process

[Dev] Blondfrogs - Today at 2:55 PM

@Hans_Schmidt We don't have a rolling tally but you can use the explores to view node versions.

RavencoinDev - Today at 2:55 PM

We do check what's being run on the network periodically but don't have a dashboard type view into the version data.

Vincent - Today at 2:55 PM

is the burn rate going to be tracked and charted on the asset explorer?

Under - Today at 2:55 PM

Rather than incorporating it, it vanilla in a vanilla Ubuntu 18 box works pretty well. CI like Travis could run on a fully gitian build, which I’m glad to work on too

RavencoinDev - Today at 2:56 PM

@Vincent There was talk of creating an RPC call that would show how much has been burned and for what purpose.Anybody want to take a shot at writing that?

Under - Today at 2:56 PM

I’m in the process !Lol

Vincent - Today at 2:56 PM

be a great stat to watch

russ - Today at 2:56 PM

http://ravencoin.asset-explorer.net/stats @Vincentburn and creation rate

Vincent - Today at 2:56 PM

nice

RavencoinDev - Today at 2:57 PM

Sweet, thanks @russ

russ - Today at 2:57 PM

@Scotty made it📷1top notch

cade - Today at 2:58 PM

@Under We have processes and tools that are in use within our organization and we leverage those tools for all of our projects. We have taken the awesome work you've done and tailored it to fit within our toolsets.📷2

Under - Today at 2:59 PM

I can understand that, but I’d counter that the process I describe is simply a copy of bitcoins and allows for it to be replicated in a larger community of developer outside of the Medici teamIt makes the build process trustless and decentralized if it can be replicated by anyone.But I get why you have your ways of doing it.

Hans_Schmidt - Today at 3:00 PM

If you drop the burn address into the web explorer, it tells you how much went there.

Vincent - Today at 3:00 PM

charts are nicer📷2📷1

RavencoinDev - Today at 3:01 PM

I would like a burned endpoint that coinmarketcap can easily call to use in their circulating supply metric.

Vincent - Today at 3:01 PM

burn and rewards can only go one way.... 📷

RavencoinDev - Today at 3:02 PM

Alright, thank you all for being here today. Thank you for your support and for all your effort on Ravencoin platform!

Neo-Geo - Today at 3:02 PM

While we are aware of the dev team’s commitment to ASIC resistance, are there any assurances that RVN dev will find a solution to stay GPU exclusive for optimal decentralization? Monero’s commitment to fork every 6 months (currently on CryptoNightV8) has been wildly successful in keeping AMD’s cards pointing predominantly at their network. RVN is quickly replacing Ethereum as the defacto coin to mine for Nvidia owners (the world’s most popular video card), but the rise of FPGAs can ruin the incentive for GPU miners and lead to hash centralization.📷2

Vincent - Today at 3:02 PM

as a noob...glad to be part of this...great job by all

cade - Today at 3:03 PM

@Under We will be releasing our build process to the community

RavencoinDev - Today at 3:03 PM

Yes @Neo-Geo we are committed to ASIC resistance and we are watching Monero closely.Thanks again everybody. Now go find some BUGS!

Under - Today at 3:04 PM

Cool thanks guys

[Dev] Blondfrogs - Today at 3:04 PM

BTW. QT wallet GUI update is coming. hahahah. have a good day everyone📷1

russ - Today at 3:05 PM

📷

mxL86 (MinerMore.com) - Today at 3:05 PM

Noicee

Hans_Schmidt - Today at 3:05 PM

CU later

Pathfinder - Today at 3:05 PM

thank you everyone!
submitted by Chatturga to Ravencoin [link] [comments]

Gridcoin Developer Update May 7th, 2018

Hello everyone and welcome to another Developer Update from the Gridcoin team. I'd like to remind everyone that these posts will be created every two weeks unless a wallet update is pending that week.
 
The last two weeks have largely been spent preparing for the next leisure release. The release would have come sooner, but some last minute additions to the staging branch were pulled in since the previous update post. Some of these pull requests have included:
 
Testnet has been working with PR #1060 which was mentioned in the last Developer Update post. I can now happily report that two superblocks have been successfully staked on testnet by Linux clients using contract forwarding. These results are extremely promising and will be a welcome addition for improved superblock stability on mainnet.
In the coming days I expect a new staging build to be ready for testnet deployment so testing will refocus soon on the PRs mentioned in this post.
 
While not entirely wallet related, I did want to point out some behind the scenes improvements for the https://gridcoin.us website. The site now properly redirects to HTTPS and supports TLS 1.2. Our site is now rated "A+" by SSL Labs. Thanks to our founder Rob for making these changes!
 
Thanks for reading this edition of the Developer Update. Expect to see another update two weeks from today (5/21), unless there is a wallet update released between now and then. If you have any comments or questions for the Gridcoin development team feel free to ask in the comments below. If I am not able to answer your question directly, I can certainly forward it to someone who can!
submitted by barton26 to gridcoin [link] [comments]

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

[16:01] <@Wolfsokta> Todays topics: DGW implementation, segfault, Q&A, feedback on IRC
[16:01] <@Wolfsokta> Just to set the stage here, this is a developer meeting where developers that have contributed source code to the Ravencoin project can meet and chat about items they are working on. Please be respectful to one another. For the sake of staying on target, please limit interactions to questions and comments on code or projects that you are working on. Any time left over at the end can be opened up for general Q&A.
[16:02] <@Wolfsokta> FYI - I'm RavencoinDev, and lets get started.
[16:03] <@Wolfsokta> @Tron, can you talk about where we are at with DGW on testnet and mainnet?
[16:03] <@Tron> Sure.
[16:03] can someone volunteer to take notes and post also?
[16:03] <@Tron> We are building binaries that will activate DGW-180 at block 338778
[16:04] <@Tron> It looks back 180 blocks to calculate the diff.
[16:04] I will copy the text from the meeting into a file that can be archived later. I can also make summary notes after like BTC core does.
[16:04] I'll save a log of the whole meeting and can post it on the subreddit thread.
[16:04] <@Wolfsokta> We have setup testnet4 in order to test the new binaries.
[16:04] great
[16:05] <@Wolfsokta> We plan to release the binaries later today.
[16:05] @Tron have you looked into the timestamp attack concerns of DGW?
[16:05] https://github.com/zawy12/difficulty-algorithms/issues/30
[16:06] <@Tron> Yes. And for that reason, we've tightened up the timestamps that will be accepted for valid blocks.
[16:06] <@Tron> Moved from 2h to 12 minutes.
[16:06] nice
[16:06] Oh wow okay
[16:06] <@Tron> Its also the reason we went from 60 blocks (lookback) to 180 blocks.
[16:07] why would 2h ever be acceptable? lol
[16:07] 2h was originally used for daylight savings shenanigans I believe
[16:07] <@Tron> It was from bitcoin, and it factors in clock skew, and variance in finding blocks on 10 minute intervals, and block propagation time.
[16:07] makes sense
[16:08] what about the segmentation fault when reindexing?
[16:08] any fix yet?
[16:08] @Tron 12 minutes seems to be pretty small window for clock skew
[16:08] I assume it was chosen due to 1/10th scaling from BTC?
[16:09] <@Wolfsokta> Not yet ruski, we'll cover that in a bit.
[16:09] <@Tron> We did divide existing by 10.
[16:10] <@Wolfsokta> Any further questions about DGW on testnet or on mainnet?
[16:10] What block is it activating on mainnet?
[16:10] <@Wolfsokta> 338778
[16:11] And will there be the need to update binaries twice (for DGW fork and asset layer fork)?
[16:11] <@Tron> We are activating DGW by block height because headers sync first, and the BIP9 activation flag sets a flag, and we need to look at either block height or version to know which diff algo.
[16:11] <@Wolfsokta> Calculated to be near the end of the month so we have some time with DGW on testnet.
[16:11] Someone on discord asked this a while back, but why Was DGW chosen over something like digishield or anyother algo
[16:11] <@Tron> And block version can be changed (tampering) and still make it on the chain.
[16:12] Binaries will need to be updated as more asset layer stuff get completed and tested. Not by the end of the month though.
[16:12] <@Tron> We looked at DGW and LWMA. LWMA has a lot of constants that must be tuned right.
[16:13] <@Tron> We were impressed with the amount of work on LWMA to analyze how it responds, but it wasn't straightforward to understand the nuances of how/why it works.
[16:13] zawy was in the #development channel on Discord. He's an expert on DAAs. I'm sure he would help with tuning LWMA if you asked.
[16:14] <@Tron> Either will be much better that what we have. Even at the extremes, it will adjust smoothly.
[16:14] Are there any issues or comments on the DGW code that should be addressed?
[16:14] @devs in general
[16:15] <@Wolfsokta> Thanks @brianmct, we did look extensively at the DGW code to ensure we weren't going to see the same issues that happened to Verge.
[16:16] so i guess you would have to make way more blocks with false timestamps to be able to exploit our version of dgw right?
[16:16] because of the 12 minute timestamp thing?
[16:16] <@Wolfsokta> With X16R, and with the changes Tron talked about we feel confident that this will address the swings without being able to be exploited.
[16:17] nice
[16:17] @russki Yeah, pretty much.
[16:17] verge is a different type of situation - but overall asics and mining are a risk always
[16:18] <@Wolfsokta> Okay, anything else on the difficulty targeting change?
[16:19] <@Wolfsokta> Cool, blondfrogs wanted to talk about subassets that were added.
[16:19] ooh yeah i saw those github commits
[16:19] looking good
[16:19] We also want to let everyone know that you can now create sub assets with the new binaries that will be posted soon. You can create these subassets using the issue rpc call. Qt will be built shortly. This will allow users to make an asset PARENT
[16:20] <@Wolfsokta> Basic overview. If you own an asset you can create sub-assets by including a '/
[16:20] nice
[16:20] And then make any of the following PARENT/A PARENT/B .... PARENT/Z
[16:20] <@Tron> We'll post a FAQ on assets later today.
[16:21] <@Wolfsokta> And it only is 100 Raven for a subasset
[16:21] on testnetv4 it still says asset activation status: waiting
[16:21] why?
[16:21] <@Tron> Yep, it needs to be voted in.
[16:21] <@Wolfsokta> We wanted to test the BIP9 activation process again as well. The more testing the better.
[16:21] We wanted to make sure that we follow the same process the Mainnet is going to go through.
[16:21] ok nice
[16:22] <@Wolfsokta> Any questions about subassets?
[16:23] are they unique?
[16:23] <@Tron> No
[16:23] <@Wolfsokta> Yes, they behave the same way as a normal asset, just live under an owned asset.
[16:23] <@Tron> Maybe I misunderstood the question. Unique with parent.
[16:23] Each subasset can have their own number issued? So PARENT/A can have 1,000 and PARENT/B can be 50?
[16:23] yes
[16:23] oooh ok that makes more sense
[16:23] <@Wolfsokta> Exactly thanks traysi
[16:24] <@Tron> And, not the same thing as "Unique Assets"
[16:24] <@Wolfsokta> The individual unique asset support is included in an upcoming phase.
[16:25] Moving onto the Segfault issue ----------------------->>>>>>>>>>> SEGFAULT
[16:25] Are we able to changes the properties of subassets after they have been created? Or is something like that specified when creating them?
[16:25] <@Tron> Yes
[16:25] can sub-assets be reassigned to other addresses while retaining control of the parent asset elsewhere?
[16:25] So basically it has all the features of a normal asset, but live under an asset's top-level namespace?
[16:25] satoshi corbie @russkidooski
[16:25] So basically it has all the features of a normal asset, but live under an asset's top-level namespace?
[16:26] <@Tron> Sub-assets are identical to assets after creation.
[16:26] <@Tron> Just cheaper to create, and in your "owned" namespace.
[16:26] Okay cool
[16:26] will subassets eventually have a unqiue tag? eg ASSET/SUB:1
[16:26] We have found an issue with our testnet binaries and are still looking to the issue. The issue presents itself when a user performs a reindexing of the chain. We think we have pinpointed the where the problem is and are currently working a fix. This fix will be out shortly.
[16:26] plan is to make default reissue=true and units=0 and allow increase in units on reissue
[16:26] How much is it going to be for a sub-asset?
[16:27] 100
[16:27] <@Wolfsokta> Okay, let's now focus on the SegFault issue that was discovered by Under.
[16:28] do you know what the issue was?
[16:28] <@Wolfsokta> It seems to be a build problem with the boost library.
[16:28] Still looking into though. :)
[16:29] <@Wolfsokta> We have been able to reproduce it on linux internally with 2.0.3
[16:29] yea i get the same issue on windows 10
[16:30] I saw a Bitcoin thread a while back about the seg fault error. I had it because I had conflicting versions of BDB
[16:30] static compiled on ubuntu 18.04
[16:30] <@Wolfsokta> We really appreciate you guys pulling down master and helping test.
[16:30] @Trap we will look into that also
[16:30] no problem, im just curious lol
[16:32] <@Wolfsokta> We haven't been able to build a windows version that doesn't have the segfault issue.
[16:32] <@Tron> We're dropping Windows support ;)
[16:32] lol
[16:33] Just finished setting up a new Windows test environment so we can test and validate the solution as we are working on it.
[16:33] The bdb issue is a known issue that has been around for some time. We are pretty certain it is a boost library issue, and are working quickly to get a windows build that fixes the issue.
[16:34] what did you guys do to fix the linux version?
[16:34] Once we have binaries for all supported platforms ready, hopefully tonight. No promises. We will make an announcement
[16:34] The issue has been fixed on Linux and Mac though?
[16:34] (oops sorry already answered)
[16:34] <@Wolfsokta> If anybody else gets there first with Windows please let us know what you found.
[16:34] Built the binairies on a Ubuntu 16.04 box.
[16:34] that was it?
[16:35] Yeah, we think so. 16.04 has boost 1.58 which seems to fix the issue. The build on 18.04 use boost 1.67 which seems to cause the issue.
[16:35] is there a boost 1.58 repo on 18.04?
[16:35] 18.04 used 1.65***
[16:36] I've built with boost 1.68 on arch Linux
[16:36] It worked
[16:37] wallet 2.0.x?
[16:37] @Trap, the issue is when -reindex is used.
[16:37] Oh sorry my bad
[16:37] Wallet 2.0.3
[16:38] <@Wolfsokta> For those that joined late we're discussing https://github.com/RavenProject/Ravencoin/issues/208
[16:38] 1 sec im going to boot into ubuntu and try compiling with 1.58 on 18.04
[16:39] Any other questions pertaining to the segfault?
[16:40] <@Wolfsokta> Alright, thanks everybody. Before we start the Q&A I would like to get some quick feedback on using IRC for this meeting.
[16:41] If we're going to use IRC we should take some measures to at least hide people's IPs when they join
[16:42] Yea. It is very hard to read this back.
[16:42] Also no message history
[16:42] If you disconnect and reconnect
[16:42] <@Tron> I'll throw in a vote for Discord.
[16:43] <@Wolfsokta> If you use a decent IRC client instead of the website it's not bad.
[16:43] Some of us used a VPN before we connected to IRC
[16:43] If needed we can restrict channel to Developer roles, etc for the developer meeting and open it up for general Q&A
[16:43] https://www.strawpoll.me/16247952
[16:43] poll
[16:43] Make a discord when only mods can submit links
[16:43] Where*
[16:45] Discord won the poll 5 to 2
[16:45] <@Wolfsokta> There are also a lot of IRC tools that can be used to track the meetings.
[16:45] we know
[16:46] <@Wolfsokta> We also want any developer to be able to speak.
[16:48] <@Wolfsokta> We're open to try Discord next week.
[16:48] <[kai]> perhaps you could even get a feed from this irc to discord?
[16:49] <[kai]> a feed would enable discordians to view the chat, but only contribute if they take the extra steps to come here.
[16:49] <@Wolfsokta> That's a good idea kai... Has anybody seen that working?
[16:50] <[kai]> https://github.com/reactiflux/discord-irc
[16:50] <[kai]> im sure you could make this a one way deal.
[16:51] <@Wolfsokta> I like that idea, let's try that for next week. So we'll meet here in IRC again, but it should be broadcast to Discord.
[16:53] <@Wolfsokta> Okay, we'll go with IRC next week with the broadcast to discord and re-visit for next week.
[16:54] <@Wolfsokta> Okay, let's do open Q&A for the next few mins.
[16:54] <[kai]> just a quickey, more for my curioisty, did you look at digishield?
[16:54] <[kai]> DGW solution seems solid.
[16:55] <[kai]> was just curious if it was one of the four solutions you looked at.
[16:55] <@Wolfsokta> Tron is answering... Any others Q?
[16:55] <@Tron> We briefly looked at Digishield, but our analysis was between DGW and LWMA.
[16:55] <[kai]> right on.
[16:56] <[kai]> cheers guys, see you next time.
[16:56] OPen the gates for the last 4 minutes for any other questions?
[16:58] <@Wolfsokta> Alright, thank you all for being here today and please join the development effort with us. If you have an idea, or a fix for an issue write it up and submit a pull request.
[16:59] <@Wolfsokta> Thanks again for all those that have contributed their time and effort to make Ravencoin successful. We have the BEST community.
[16:59] ^
6:59] You devs are pretty cool
[16:59] did the burn get discussed?
[16:59] <@Wolfsokta> Special thanks to Bruce, really glad you could make it with the short notice.
[17:00] <@Tron> Thanks everyone!
submitted by __pathfinder__ to Ravencoin [link] [comments]

Inadvisably small full node config

Disclaimer: As the subject implies, this is about an inadvisable config. The following is of zero practical use, but like cross-stitch, may be appealing to the random few people interested in such things. Opinions on the futility of this exercise can be considered already noted. Any suggestions to make this more ridiculously small are very welcome. Obviously I'm not running my primary wallet off of this config. It's just for fun.
TLDR: Wow look, my full node fit on a 0.5 CPU with 0.6 GB memory and 25 GB drive... yeah for me!

Background

I used to run a full node a good ways back, but stopped when the old 3rd string laptop I was using to run it was having drive issues. Still the early interest paid dividends as the price has gone exponential. Missing the good ol' days, I wanted to run another node, but really didn't want to do it on any of my work or lab units. My company took a hard stand years ago to prevent interns from mining on spare HW, so running even a full node on my corporate gear is kinda a capitol punishment. Round about this time, I got some spam for some free VPS service for a year. The promotion were really (I mean really wimpy VPSs). Crappy VPS + bitcoind performance tuning = my kind of waste of time.

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VPSs. Maybe some of the tuning parameters could be used for a docker container or some whipy SOC. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoind.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or the kernel oom_killer take maters into its own hands (logged in /valog/syslog). This looks very similar to an issue that was logged against 0.14.0 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less aggressive with a setting of prune=10240 seems to be a good compromise for what I need done. This could possibly be an observation error, but the results seemed very reproducable.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems ridiculous, but on my VPS, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial console on my systemd install.

canary log

Since logging into my system gobbles up memory, I wanted this config to be as low-touch as possible once in motion. After tooling up the serial ports, I found all the system log messages where peekable without logging into my VPS through my VPS provider. I wrote a small canary script to simply chirp to the serial port every 5 minutes to confirm that bitcoind was indeed alive and kicking.

Scripts

I made a few scripts during the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:

Final config

Here is my final config, that is still syncing, but seems to be stable on 0.14.2
/usbin/nice -n 15 bitcoind \ -dbcache=115 \ -prune=10240 \ -maxmempool=5 \ -daemon /usbin/nohup $HOME/canary.sh $1 300 $USER >/dev/null 2>/dev/null & cPid=$! sudo /usbin/renice -n -5 -p $cPid echo "Canary @ $cPid" 
Memory utilization while syncing seems to be at about 400MiB. Once I'm synced, I expect to retune for dbcache=60 and maxmempool=60.
Projected full blockchain sync completion in (gulp) 30 days. CPU utilization is currently reported between 30-60% but my provider offers boost periods where they unmeeter the VMs. I've gotten it up to 110% on their dashboard, for what its worth.
I'm well beyond the word limit so I'll drop off here, but I'll eventually put the snipits in a github repo in the near future.
PS If anyone knows of some free VPS or Docker hosting services, please chime in.
EDIT: s/VSP/VPS/g - lysdexia
submitted by brianddk to BitcoinDiscussion [link] [comments]

Inadvisably small full node config

Disclaimer: As the subject implies, this is about an inadvisable config. The following is of zero practical use, but like cross-stitch, may be appealing to the random few people interested in such things. Opinions on the futility of this exercise can be considered already noted. Any suggestions to make this more ridiculously small are very welcome. Obviously I'm not running my primary wallet off of this config. It's just for fun.
TLDR: Wow look, my full node fit on a 0.5 CPU with 0.6 GB memory and 25 GB drive... yeah for me!

Background

I used to run a full node a good ways back, but stopped when the old 3rd string laptop I was using to run it was having drive issues. Still the early interest paid dividends as the price has gone exponential. Missing the good ol' days, I wanted to run another node, but really didn't want to do it on any of my work or lab units. My company took a hard stand years ago to prevent interns from mining on spare HW, so running even a full node on my corporate gear is kinda a capitol punishment. Round about this time, I got some spam for some free VPS service for a year. The promotion were really (I mean really wimpy VPSs). Crappy VPS + bitcoind performance tuning = my kind of waste of time.

Goal

My goal (perverse though it may be), is to get bitcoin or other forks running in very small VPSs. Maybe some of the tuning parameters could be used for a docker container or some whipy SOC. The system I was targeting has 0.5 CPU, 0.6 GB of memory and 25 GB of disk.

Observations

I found some interesting things out along the way that may be of interest to people tweeking bitcoind.

dbcache limits

Since I don't have the requisite memory required to run the node, I've limited memory using the dbcache parameter. Settings range from 100 to 150 depending on what other settings I have in place.

0.15.1 mallocs

I don't know what changed in 0.15.1 but it seems much more memory hungry than previous releases. Throughout the tuning process, I continually had either bitcoind quit due to memory allocation failures (logged in debug.log), or the kernel oom_killer take maters into its own hands (logged in /valog/syslog). This looks very similar to an issue that was logged against 0.14.0 that was patched in 0.14.1. My ultimate solution was to downgrade to 0.14.2 which seems to work great.

prune compromise

My initial thoughts were to use prune=550 to use the least amount of disk space possible. I found out that even on 0.14.2 this causes memory to fill up quick. I found making the pruning less aggressive with a setting of prune=10240 seems to be a good compromise for what I need done. This could possibly be an observation error, but the results seemed very reproducable.

blocksonly avoidance

I had thought to save some memory by using blocksonly. For some reason, on 0.14.2, this causes more problems than it solves. I had a hard time finding any config where blocksonly would work. Surprisingly, maxmempool=5 does effectively the same thing for the miserly cost of 5MiB of memory.

serial consoles

Seems ridiculous, but on my VPS, if bitcoind was running full speed, I would have a hard time connecting through SSH. There were other SSH clients and connection methods that seemed to work better. By far the quickest connections when under heavy utilization was to connect directly to serial ports. I wrote a small snippet to enable extended serial console on my systemd install.

canary log

Since logging into my system gobbles up memory, I wanted this config to be as low-touch as possible once in motion. After tooling up the serial ports, I found all the system log messages where peekable without logging into my VPS through my VPS provider. I wrote a small canary script to simply chirp to the serial port every 5 minutes to confirm that bitcoind was indeed alive and kicking.

Scripts

I made a few scripts during the process as the needs arose. They are very utilitarian, and could do with some major overhauls, but they did what I needed done at the time I needed it.
Scripts:

Final config

Here is my final config, that is still syncing, but seems to be stable on 0.14.2
/usbin/nice -n 15 bitcoind \ -dbcache=115 \ -prune=10240 \ -maxmempool=5 \ -daemon /usbin/nohup $HOME/canary.sh $1 300 $USER >/dev/null 2>/dev/null & cPid=$! sudo /usbin/renice -n -5 -p $cPid echo "Canary @ $cPid" 
Memory utilization while syncing seems to be at about 400MiB. Once I'm synced, I expect to retune for dbcache=60 and maxmempool=60.
Projected full blockchain sync completion in (gulp) 30 days. CPU utilization is currently reported between 30-60% but my provider offers boost periods where they unmeeter the VMs. I've gotten it up to 110% on their dashboard, for what its worth.
I'm well beyond the word limit so I'll drop off here, but I'll eventually put the snipits in a github repo in the near future.
PS If anyone knows of some free VPS or Docker hosting services, please chime in.
EDIT: s/VSP/VPS/g - lysdexia
submitted by brianddk to Bitcoin [link] [comments]

Interested in contributing to the BTC network? Here is the steps to get a full node up and running in Linux.

These instructions will work both on a VPS cloud server or a personal computer. You may find cheap VPS somewhere online for rent.
What Is A Full Node?
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
Many people and organizations volunteer to run full nodes using spare computing and bandwidth resources—but more volunteers are needed to allow Bitcoin to continue to grow. This document describes how you can help and what helping will cost you.
Costs And Warnings
Running a Bitcoin full node comes with certain costs and can expose you to certain risks. This section will explain those costs and risks so you can decide whether you’re able to help the network.
Special Cases
Miners, businesses, and privacy-conscious users rely on particular behavior from the full nodes they use, so they will often run their own full nodes and take special safety precautions. This document does not cover those precautions—it only describes running a full node to help support the Bitcoin network in general.
Please consult an expert if you need help setting up your full node correctly to handle high-value and privacy-sensitive tasks.
Secure Your Wallet
It’s possible and safe to run a full node to support the network and use its wallet to store your bitcoins, but you must take the same precautions you would when using any Bitcoin wallet. Please see the securing your wallet page for more information.
Minimum Requirements
Bitcoin Core full nodes have certain requirements. If you try running a node on weak hardware, it may work—but you’ll likely spend more time dealing with issues. If you can meet the following requirements, you’ll have an easy-to-use node.
Note: many operating systems today (Windows, Mac, and Linux) enter a low-power mode after the screensaver activates, slowing or halting network traffic. This is often the default setting on laptops and on all Mac OS X laptops and desktops. Check your screensaver settings and disable automatic “sleep” or “suspend” options to ensure you support the network whenever your computer is running.
Possible Problems
Legal: Bitcoin use is prohibited or restricted in some areas.
Bandwidth limits: Some Internet plans will charge an additional amount for any excess upload bandwidth used that isn’t included in the plan. Worse, some providers may terminate your connection without warning because of overuse. We advise that you check whether your Internet connection is subjected to such limitations and monitor your bandwidth use so that you can stop Bitcoin Core before you reach your upload limit.
Anti-virus: Several people have placed parts of known computer viruses in the Bitcoin block chain. This block chain data can’t infect your computer, but some anti-virus programs quarantine the data anyway, making it more difficult to run a full node. This problem mostly affects computers running Windows.
Attack target: People who want to disrupt the Bitcoin network may attack full nodes in ways that will affect other things you do with your computer, such as an attack that limits your available download bandwidth or an attack that prevents you from using your full node’s wallet for sending transactions.
Linux Instructions
The following instructions describe installing Bitcoin Core on Linux systems.
Ubuntu 14.10 Instructions for Bitcoin Core 0.10.0.
If you use Ubuntu Desktop, click the Ubuntu swirl icon to start the Dash and type “term” into the input box. Choose any one of the terminals listed:
Alternatively, access a console or terminal emulator using another method, such as SSH on Ubuntu Server or a terminal launcher in an alternative desktop environment.
Type the following line to add the Bitcoin Personal Package Archive (PPA) to your system:
sudo apt-add-repository ppa:bitcoin/bitcoin
You will be prompted for your user password. Provide it to continue. Afterwards, the following text will be displayed:
Stable Channel of bitcoin-qt and bitcoind for Ubuntu, and their dependencies
More info: https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin
Press [ENTER] to continue or ctrl-c to cancel adding it
Press enter to continue. The following text (with some variations) will be displayed and you will be returned to the command line prompt:
gpg: keyring /tmp/tmpixuqu73x/secring.gpg' created gpg: keyring/tmp/tmpixuqu73x/pubring.gpg' created gpg: requesting key 8842CE5E from hkp server > > > >keyserver.ubuntu.com gpg: /tmp/tmpixuqu73x/trustdb.gpg: trustdb created gpg: key 8842CE5E: public key "Launchpad PPA for Bitcoin" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 pg: imported: 1 (RSA: 1) OK
Type the following line to get the most recent list of packages:
sudo apt-get update
A large number of lines will be displayed as different update files are downloaded. This step may take several minutes on a slow Internet connection.
To continue, choose one of the following options
sudo apt-get install bitcoin-qt
sudo apt-get install bitcoind
sudo apt-get install bitcoin-qt bitcoind
After choosing what packages to install, you will be asked whether you want to proceed. Press enter to continue.
If you’re logged in as an administrative user with sudo access, you may log out. The steps in this section should be performed as the user you want to run Bitcoin Core. (If you’re an expert administrator, you can make this a locked account used only by Bitcoin Core.)
Before using the Bitcoin Core daemon, bitcoind, you need to create its configuration file with a user name and password. First create the .bitcoin directory, create (touch) the file, and set the file’s permissions so that only your user account can read it. From the terminal, type:
mkdir ~/.bitcoin touch ~/.bitcoin/bitcoin.conf chmod 600 ~/.bitcoin/bitcoin.conf
Then you can run the command bitcoind. It will print output similar to this:
bitcoind Error: To use the "-server" option, you must set a rpcpassword in the configuration file: /home/bitcoinorg/.bitcoin/bitcoin.conf It is recommended you use the following random password: rpcuser=bitcoinrpc rpcpassword=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (you do not need to remember this password)
The username and password MUST NOT be the same.
If the file does not exist, create it with owner-readable-only file permissions. It is also recommended to set alertnotify so you are notified of problems; for example: alertnotify=echo %s | mail -s "Bitcoin Alert" [email protected] The “rpcpassword” displayed will be unique for your system. You can copy the rpcuser and rpcpassword lines into your configuration file using the following commands. Note that in most Ubuntu terminals, you need to press Ctrl-Shift-C to copy and Ctrl-Shift-V to paste because Ctrl-C and Ctrl-V have different meanings in a Unix-style terminal.
echo rpcuser=bitcoinrpc >> ~/.bitcoin/bitcoin.conf echo rpcpassword=XXXXXX >> ~/.bitcoin/bitcoin.conf (Warning: Don’t use XXXXXX as your RPC password. Copy the rpcpassword displayed by bitcoind for your system.)
Now you can start Bitcoin Core daemon for real. Type the following command:
bitcoind -daemon
It will print a message that Bitcoin Core is starting. To interact with Bitcoin Core daemon, you will use the command bitcoin-cli (Bitcoin command line interface). Note: it may take up to several minutes for Bitcoin Core to start, during which it will display the following message whenever you use bitcoin-cli:
error: {"code":-28,"message":"Verifying blocks..."}
After it starts, you may find the following commands useful for basic interaction with your node:
to safely stop your node, run the following command:
bitcoin-cli stop
A complete list of commands is available in the Bitcoin.org developer reference.
When Bitcoin Core daemon first starts, it will begin to download the block chain. This step will take at least several hours, and it may take a day or more on a slow Internet connection or with a slow computer. During the download, Bitcoin Core will use a significant part of your connection bandwidth. You can stop Bitcoin Core at any time using the stop command; it will resume from the point where it stopped the next time you start it.
Optional: Start Your Node At Boot
Starting your node automatically each time your computer boots makes it easy for you to contribute to the network. The easiest way to do this is to start Bitcoin Core daemon from your crontab. To edit your crontab, run the following command:
crontab -e
@reboot bitcoind -daemon Save the file and exit; the updated crontab file will be installed for you. Now Bitcoin Core daemon will be automatically started each time your reboot your computer.
If you’re an Ubuntu expert and want to use an init script instead, see this Upstart script.
You have now completed installing Bitcoin Core. If you have any questions, please ask in one of Bitcoin’s many communities, such as Bitcoin StackExchange, BitcoinTalk technical support, or the #bitcoin IRC chatroom on Freenode.
To support the Bitcoin network, you also need to allow incoming connections. Please read the Network Configuration section for details.
Network Configuration
If you want to support the Bitcoin network, you must allow inbound connections.
When Bitcoin Core starts, it establishes 8 outbound connections to other full nodes so it can download the latest blocks and transactions. If you just want to use your full node as a wallet, you don’t need more than these 8 connections—but if you want to support lightweight clients and other full nodes on the network, you must allow inbound connections.
Servers connected directly to the Internet usually don’t require any special configuration. You can use the testing instructions below to confirm your server-based node accepts inbound connections.
Home connections are usually filtered by a router or modem. Bitcoin Core will request your router automatically configure itself to allow inbound connections to Bitcoin’s port, port 8333. Unfortunately many routers don’t allow automatic configuration, so you must manually configure your router. You may also need to configure your firewall to allow inbound connections to port 8333. Please see the following subsections for details.
Testing Connections
The BitNodes project provides an online tool to let you test whether your node accepts inbound connections. To use it, start Bitcoin Core (either the GUI or the daemon), wait 10 minutes, and then visit the GetAddr page (https://getaddr.bitnodes.io/). The tool will attempt to guess your IP address—if the address is wrong (or blank), you will need to enter your address manually.
For more instruction and reviews based off BTC please follow my subreddit /BTC_Reviews
all material from this post was found here --> https://bitcoin.org/en/full-node
submitted by Mattjhagen to Bitcoin [link] [comments]

Dev++ 01-08-EN  Remote Procedure Calls (RPC) - Anditto Heristyo Communicate with Bitcoin-qt using C# - .NET (5 of 6) Basic technical understanding of Bitcoins (2 of 6) 6. bitcoin-qt How to run Bitcoin-qt as a server with a configuration file (3 of 6)

Bitcoin-Qt version 0.8.0 are now available from: “Bloom filter” support in the network protocol for sending only relevant transactions to lightweight clients. /spendfrom is a python-language command-line utility that demonstrates how to use the “raw transactions” JSON-RPC api to send coins received from particular addresses Bitcoin Core 0.9.2.1 Rpc Calls Extended List (pastebin/bitcoinse X-post) Bitcoin Core 0.9.2.1 RPC Calls Extended List (Pastebin/BitcoinSE x-post) I posted Bitcoin Core 0.9.2.1 RPC Calls Extended List over at Bitcoin SE and linked to the full copy/paste at Pastebin There's a few rough formatting issues but I found this hard to find so perhaps it'll help people like myself. Bitcoin clients Bitcoin clients Main article and feature comparison: Clients Bitcoin Core - C++/Qt based tabbed UI. Linux/MacOSX/Windows. Full-featured thick client that downloads the entire block chain, using code from the original Bitcoin client.; bitcoind - GUI-less version of the original Bitcoin client, providing a JSON-RPC interface; MultiBit - lightweight thin client for Windows, MacOS Use env variable QT=1. Example: QT=1 ./qa/rpc-tests/wallet.py --srcdir=src/ The RPC test will be executed over GUI clients. It pretty cool to visually watch the RPC test slowly gets executed. Much slower then bitcoind; aims to help testing and improving UI situations. 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.

[index] [16461] [246] [24643] [12281] [9861] [5887] [14580] [29171] [21591] [4588]

Dev++ 01-08-EN Remote Procedure Calls (RPC) - Anditto Heristyo

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. Programming Bitcoin-qt using the RPC api (1 of 6) - Duration: 3:17. Lars Holdgaard 4,692 views. 3:17. How to run Bitcoin-qt as a server with a configuration file (3 of 6) Skip navigation Sign in. ... JSON RPC Calls with Bitcoin qt (4 of 6) - Duration: 4:25. Lars Holdgaard 6,166 views. RPC commands: - getbalance - getwalletinfo - getnewaddress - getblockcount - getnetworkinfo www.bitcoinhackers.org @402PaymentRequierd bc1qny4am3clu0gcsq3hvj... This video is unavailable. Watch Queue Queue. Watch Queue Queue

Flag Counter