Change Bitcoin Core Data Directory - BitcoinWiki

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: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
[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] 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]>
[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]

Lore v2 QT on Raspberry Pi

To follow up to mindphuk's excellent piece on building the headless client on Raspberry Pi (, I thought if anyone was interested I'd show you how to get the full QT version running on the Pi on the Jessie with Pixel desktop. This works and has been soak tested for several days now on a standard Raspberry Pi 3. I have since added some coins and it stakes a handful of times a day.
Running staking Lore clients paves the way for some of the future use cases of BLK utilising the Bitcoin 0.12 (and newer) core tech, including colored coins. So I'm going to leave this one going indefinitely to kickstart the number of Lore clients staking. It's certainly not mandatory but it will be good in the longer term to have a nice distribution of Lore staking clients.
The cross-compile which lets you create binaries for multiple platforms didn't work for the QT version on the Pi, so there is more to do than just running the binary unfortunately, as below. There are folks working on some much cleaner solutions than this for the Pi, with a custom front end, and where you won't have to do any mucking about. That is coming soon. In the meantime, if you enjoy a fiddle with such things, here's how to get this QT client working on your Pi.
These instructions assume you are starting from scratch with a completely blank OS.
Download Jessie with Pixel from:
Note they have since (August 2017) released a version called 'Stretch' which does not work with this guide. I'll see if I can come up with something new for that at some point and link to it here when I have. In the meantime the guide should work with the Jessie image above.
Unzip the file and extract the .img file to burn it onto Fresh SD card to boot from (to be safe, use 16GB or larger), using a tool like win32diskimager or Etcher.
Assuming you have keyboard/mouse and monitor plugged into your pi, boot it up and the Jessie Desktop will show.
Before we do anything else, you should increase the default swap size on the pi, as compiling certain libraries can exhaust the RAM and get stuck otherwise. To do this, launch a Terminal window