Good news woodcutters!!  

The WoodcoinCore-0.13 client is ARMED and FULLY OPERATIONAL.  Syncs, receives, sends, uses Heirarchical Deterministic wallet and is fully Segwit enabled.  If you check your peers you might already be connected to one.  There are nice new network stats in the GUI and a few other rpc commands, including the split into:

woodcoin-qt
woodcoind
woodcoin-cli
woodcoin-tx

There are a few cosmetic changes needed (e.g. removing the litecoin splash screen lol thanks Charlie) before we make our press releases but the more adventurous of you will definitely want to check it out and take it for a spin.  

https://github.com/funkshelper/woodcore.git


As it stands right now, it won't signal segwit blocks until the spring equinox.  

If you do try it -  BACK UP YOUR OLD WALLET FIRST!!!!  

and then BACK IT UP AGAIN!!!!



As always, your feedback here is much apprecated.
 

For those interested in my technical struggles with this release, they mostly revolved around getting the skein hash function to eat it's meal properly in the new autotools build environment inherited from the bitcoin-core project.  I also re-wrapped the ECDSA functionality into using OpenSSL as opposed to the libsecp256k1 library.  Other than that it was just drop in the woodcoin chainparams and the harmonic sequence subisdy and let her rip. 

Baruk Khazad !
  

This has been a Funkenstein the Dwarf production.

I attempted to cross compile a 64bit windows exe file on my Rpi3 using Debian Jessie.  I got pretty far but lost it in the mingw transfer section.  I just didn't have anymore time this weekend.  I will give it another go this weekend coming up.

A couple more screenshots from the latest release for you here. 





We have all the bitcoin-core features enabled, such as GUI fine-tuning of connected nodes, coin control, fee adjustment, and more. 

I see a few of you on the network, I hope you are enjoying this release.  Love goin' out to you on this equinox.

Just for you pokeytex
Look Mom I built winblows executable!  

Built with GCC+mingw32 on debian

sha256sum woodcore-qt.exe
217c611ad302899cdef96fed622dc8a8f0f3d07edc0fc4c3a480fa98b9fba396  woodcore-qt.exe


grab it from:

https://github.com/woodcoin-core/woodcoin-windows/raw/master/woodcore-qt.exe


Enjoy!  

Greetings woodcutters and public coin enthusiasts -

  A few words about the recent release of "Woodcoin-core 0.13.2" are in order.  

  While the qt-client is nice graphically and the set of rpc commands are great, there are some things which you might not like about this client.  Wait what?  People complaining about software?  Stop the press!  

   I have at present left everything about the client behavior exactly as the Bitcoin 0.13 (van de Laan) (aka "core") client behaves.  The idea is that we can learn about behavior on the BTC network through our development of the LOG network.  Changes will be coming, but for now that is how we leave the public release as a straight port (now with fully armed and operational windows build available).

   The second thing you might notice when running this thing is that it is not very promiscuous.  In fact the thing will happily sit for hours connected to a single node!  You will probably want to coax it by adding more nodes by hand with "addnode x.x.x.x add" command at the debug console.  To find the reason for this behavior you will need to dive into the github comments of the Van de Laan team and various documentation.  They have set it up to be a quiet node that doesn't like to talk to strangers.  And how do we know who "strangers" are you might ask?  Good question.    

   One of the big changes here, which in my opinion is misguided, is the reliance on "Versionbits" and what nodes declare as their version number, on network rules and priorities.  A version number is transmitted in plaintext with no verifiability.  Why do we even pay attention to these?  Well, we pay attention because we are looking for something, anything, to help us decide our networking behavior.  "Shoot the guys in the red coats" is marginally better than "shoot anything that moves".  If you consider this even a partially relevant analogy it should be the basis for a moment of self-reflection.  (pause)        

   In fact a much wiser policy would be to base all networking decisions (banning of nodes, relaying of transactions, relaying of blocks, relaying of node information) on NODE BEHAVIOR rather than what version the node CLAIMS TO BE.  This philosophy really ought to extend right into our discussion of blocks as well.  And perhaps further, as the world is not actually divided into "us" and "them", despite the tragic behavior of a bunch of pitiful orcs long ago.  But I digress.  

   For example, people are talking about how blocks are "signalling"  for "bitcoin-core".  Come again?  This means very little.  A version bit is not a guarantee of anything, and so to rely on it as if it were is misguided.  Blocks have a size, and they contain transactions of certain types.  This we can verify - and in the end - this is what matters.  OK, to be fair, a little bit of introducing ourselves and trusting our neighbors to say what they will do later isn't going to hurt us, as long as we remember not to be totally reliant on it.  But why not ditch the signaling of version between nodes completely?  What do you think?  

  As I see it there is no need to treat a node which looks like "WoodcoinCore 0.13.2" any differently than a node which looks like "Funkenstein 1.0.1" or "Satoshi 1.0.1".  Just as we treat a man and a woman, or a French speaker and a Chinese speaker, equally - until they demonstrate otherwise - we should also so treat our nodes.  Of course, if somebody says "我不会说英文“ we don't simply raise our voice and shout English.  An ideal node speaks all languages and does its best to talk to all nodes - it doesn't prefer to talk to those who wave a certain flag. 

   Thankfully, this discussion is not a huge issue on the woodcoin network.  The chain demonstrating the most work is the one which defines the woodcoin block chain, and how nodes wind up communicating with one another to figure out what is going on is far less important that at first you might imagine.  Sure netsplits are possible, but they do not represent consensus forks.  They just mean somebody has to do a reorg, and transaction confirmation might get delayed.  An introvert can still get the news, it just might take a bit longer.  

   Anyway, this long-winded post basically says: sorry, woodcoin-core is not a very polite child.  Give us time and we'll learn some manners.  Here's a list of some folks who have recently demonstrated at least some friendly behavior such as being non-firewalled on port 8338.  Go ahead and introduce your node to some of them if you want to got out a bit and be more social while you chop and stack your LOG.  

addnode=223.158.211.150
addnode=217.175.119.125
addnode=96.33.131.50
addnode=73.61.69.113
addnode=80.229.163.230
addnode=92.214.191.144
addnode=83.252.17.134
addnode=76.64.74.218
addnode=163.172.28.249
addnode=92.170.141.48
addnode=67.205.162.80
addnode=163.172.90.105
addnode=199.231.215.253
addnode=104.236.96.120
addnode=5.9.233.99
addnode=23.242.89.131
addnode=50.166.119.69
addnode=67.35.116.81
addnode=199.231.215.252
addnode=167.114.103.43
addnode=185.86.148.224
addnode=110.10.176.94
addnode=45.55.152.37
addnode=106.185.41.253
addnode=159.203.76.85
addnode=82.144.204.28

As always, please report any difficulties here.  
    

Woodcoin is the next Pascal.  People ignoring an up and coming coin till it increases 100k%

Thanks for posting ylpkm!  Here is a recommended woodcoin.conf:

server=1
listen=1
daemon=1
rpcallowip=127.0.0.1
rpcport=8339
port=8338
rpcuser=MyUserName
rpcpassword=MyPassWord
addnode=223.158.211.150
addnode=217.175.119.125
addnode=96.33.131.50
addnode=73.61.69.113
... (more addnodes)

And run the miner with a command something like:  

./ccminer --algo=skein2 --user=MyUserName --pass=MyPassWord --url=127.0.0.1:8339


However I have only tested with a CPU miner myself, it looks like ccminer also has a config file which might need to be set.  

Please post your error messages and hopefully we'll get a better answer for you.  

Oy sorry..   did you try:

./ccminer --algo=skein2 --user=MyUserName --pass=MyPassWord --url=stratrum+tcp://127.0.0.1:8339   

?? 

 

stratrum is a pool protocol, and this wallet doesnt have the getwork method because bitcoin removed the mining/miner feature from its wallet code (and most wallet devs copy/follow that lol)

Thank you Epsylon3 and Bathrobehero.  I will put getwork() back into this thing for an update.  I don't know why it was removed.  

tpruvot's cpu miner has the option "--no-getwork" which enables me to cpu mine on this thing.    

However I'm not sure if ccminer has anything similar.  

I see there is a stratum "bridge" proxy that some people use to overcome this issue.  What a pain.  No wonder nobody mines on bitcoin-core

We're learning somethiing!  Thanks