Yes, sorry about that yplkm, the situation is as Epsylon3 eplained. 

Then :

"Yo dawg, I heard you liked getwork so I got to work and got getwork to work"

I added getwork back into the code repo with this commit:

https://github.com/funkshelper/woodcore/commit/ac00e0faf8dd4eaed4fec7076962750e07aa0ac6

Unfortunately I still haven't had time to build windows binaries of this thing.  This afternoon china time I will do it for sure! 

Thanks for your patience Pokeytex and to the stress testers working overtime on this coin recently!  And for your comments Cryptophilanthropist. 

Cheerio  -

I was going to say.. great work!  But uh oh, what happened?  Is there more block withholding going on or is this an issue with the new client's block header?  Did you use the getwork() call or is it getblocktemplate()  ? 

Thanks!! 

Agreed Moshen. 

Personally I always tell people to before they click anything DOUBLE CHECK THE POSITION OF THE DECIMAL POINT. 

In doing so, this is also an opportunity for a second thought about the nature of the transaction itself.  Sometimes there is no going back, so make sure you get it right.  Bitcoin is like gravity, not exactly a forgiving system. 

Greetings LOGcutters great and small -

  Happy Oestern, Easter, Pacques, Ishtar, and ancient holiday, and new tradition, greetings to you all.

  I have reimplemented "getwork"  in the new 0.13.2 client repo.

  Here's the commit:

https://github.com/funkshelper/woodcore/commit/ac00e0faf8dd4eaed4fec7076962750e07aa0ac6

  Or just clone:

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

  Go ahead and build and mine   

  I will be building executables for the various boxes soon after I get feedback. 


 

Hi Pokeytex.  My apologies for another longwinded reply in advance.

Short story: the 0.13.2 release is ready for mining, in the same sense that Dash, Bitcoin-core, Litecoin nodes are also ready for mining.  HOWEVER, none of these will support solo-mining with ccminer pointed right at the node.  This  is presumably what you are trying to do, as this is what some of us were doing before with the old Funkenstein 1.1 client.   

The way most wallet and node developers handle this is to tell people to get their miner to support getblocktemplate.  For example from the Dash forum:

"Since v12 wallet merged updated with bitcoin core, rpc/getwork is not available on wallet anymore. For solo miner, please use mining application which support rpc/getblocktemplate or create own mining pool or p2pool for support rpc/getwork to mining application."

This can be done by using a "getwork - getblocktemplate bridge proxy", such as Luke-Jr' s python script
https://gitlab.com/bitcoin/eloipool/blob/master/gmp-proxy.py
 or BFGminer itself which apparently can also be used as a bridge. 

After reading about all the history of these mining protocols and going through the codes of several refactored versions, I realize that much of the trouble with disconnect between so-called devs and miners is -- drumroll please -- the devs removed getwork from their node software api.  Four years of drama over this can you believe it? 

So yeah, I'm putting getwork back into this thing for 0.13.3, and I expect ccminer's developer to be working on getting adding support for getblocktemplate as well.  In the meantime you are going to have to use the older client.  The good news - there's not much difference really  

   

 

Lol for srs? 

Maybe read up on it and try to understand why having a reasonable long term plan of supply distribution is important. 

If you still have them and want to buy BTC, I'm happy to trade find me on IRC  

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  

Oy sorry..   did you try:

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

?? 

 

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.  

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.  
    

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!  

Those of you interested in Segregated Witness,

...might be interested to see a segwit signalling Woodcoin-Core 0.13.2
live on the woodcoin network.

The client is ported from the litecoin fork of the bitcoin-core-0.13 repository.

https://github.com/funkshelper/woodcore




Armed and fully operational for your enjoyment.  

Many thanks to sipa, nullc, coblee, bitcoin dev team, litecoin dev team, et al.!

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.

Thank you Pokeytex!!  Good luck with this build, your efforts much appreciated.   

Those following the Segregated Witness rollout story might be interested to see we have a fully segwit-enabled client on the woodcoin network.  Official release is Mar. 21, but here's a teaser:



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

All comments appreciated.  Keep up the good work public coin enthusiasts!

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

I see a few nodes reporting to be Woodcore0.13 on the network, but not much feedback yet.

I'd love to hear from woodcutters on this build.  This client is tricky to use as a standalone miner but in tandem with the GPU miners that currently dominate our hashpower it should be swappable with the Funkenstein1.0.1 client.

Official release scheduled for 2 days from now. 

 

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.

In other news, there is a new woodcoin.org website up and slowly growing. Please take a look and if there are any issues let us know here. 

The repo for making changes to this is at github.com/woodcoin-core/wooccoin.org/   

A number of our projects have also been forked into the github.com/woodcoin-core/ github heading for simplicity and ease of access. 

If there are any issues with these repos please do post here. 

Hi Pokeytex, well it is a long story, sorry.  And one without a conclusion at this point.  

Basically what "segwit" refers to is two new types of transaction, in addition to the types we have already.  Mostly we have today Pay-To-Pubkey-Hash (pay to a standard bitcoin address) transactions, but also possible are Pay-To-Pubkey transactions.  There are also Pay-To-Script-Hash transactions, which enable multisignature functionality.  For an interesting review as of 2014, see this survey of the bitcoin blockchain:

http://www.quantabytes.com/articles/a-survey-of-bitcoin-transaction-types

The new types in "segwit" are referred to as pay-to-witness-public-key-hash and pay-to-witness-script-hash if you want to look them up.  There are a couple of advantages to these TX types.  One is that they allow for an elimination of transaction-ID-malleability, which enables certain implementations of payment channels and sidechains.  Another is that they take up less space.

This would be all well and good, if they were cleanly back-compatible like the other new transaction types have been.  

For example if you are using bitcoin 0.5.3, which doesn't have multisig P2SH transactions implemented, you can still sync to the chain.  P2SH transactions just look nonstandard but still verify as valid and don't cause a conflict in the block chain.  

HOWEVER, one of the new transaction types in segwit looks like an "anyone-can-spend" transaction to an older client.  This means that a chain split is possible.  One miner verifying with older software might let somebody spend these, whereas the newer software being run by another miner wouldn't let that transaction go through.  This means there is a fundamental disagreement over what is the blockchain, which is bad (TM) (R).  

People are generally scared of any kind of forking in the consensus mechanism, and so segwit transactions have not appeared on any highly valued blockchain.  However there is a "signalling" mechanism that allows miners to publicly state that they are willing to start confirming these new transactions.  When a certain level of support is signalled, we will relax a little bit, the transaction type will be enabled, and maybe people will start using them.  

Currently some miners of bitcoin and litecoin are signalling that they support this "soft-fork", but not a majority.  It is only a soft fork because non-mining users wouldn't have to update to validate segwit transactions.    

--

I have not gone through the segwit code in detail nor done testing personally on the segwit-enabled-bitcoin-testnet.  My purpose here is not to promote segwit transations, though the idea seems sound and potentially useful as well as being recommended by many developers I respect.  My purpose is rather to make the option available, and to point out that woodcoin is ready for this should woodcutters (and LOG users) desire it.  It has no fundamental conflict with the logarithmic release schedule nor our other unique features.  

That's my understanding, likely incomplete, and hence my request for comments from all y'all.  Hope that helps!

Recommended reading:

http://achow101.com/2016/04/Segwit-FUD-Clearup




    




 


 

WOODCOIN UPDATE

Greetings citizens of middle earth.

I have been working on yet another client for the woodcoin network: 

https://github.com/funkshelper/woodcore

When this goes live we will have the option of woodcutters signaling, and people using, segregated witness transactions. 

It's probably a good idea to throw this out there as a request for comments before I get much further. 

What do you think? 

Until then of course, and even after, the original client and source tree are still validating the chain and enabling interaction:

https://github.com/funkshelper/woodcoin

There are a number of contributions still oustanding on this task, including adapting and performing all the relevant unit tests.  Your efforts will be generously compensated.