AuxPoW Abstraction

Question

AuxPoW Abstraction

JeremyRand opened this issue 8 years ago · 12 comments

Merge-mined blockchains such as Namecoin and Dogecoin use a different proof of work scheme (AuxPoW), in which a block header and coinbase transaction from a parent chain (usually Bitcoin or Litecoin) is included in the Namecoin or Dogecoin block header. This extra data (referred to as an AuxPoW header) is required in order to verify the PoW (meaning that SPV cannot work without this data).

As far as I can tell, ElectrumX does not currently support sending AuxPoW headers when it sends block headers to a client. As a result, ElectrumX servers cannot be used with Electrum clients that validate AuxPoW, which makes ElectrumX's support for Namecoin and Dogecoin basically useless unless the client fully trusts the server to serve the chain with the most work.

Is there any chance this could be added? I'm not too familiar with the ElectrumX codebase, but at first glance it looks like overriding the electrum_header method might be a reasonable way of doing it.

Answer 1 · 2016-12-19T14:30:25.000Z

Sure; please feel free to submit a PR. I'm not familiar with this stuff - but presumably you have Electrum clients that expect an enhanced electrum header?
I assume these coins have working electrum-server implementations?

Answer 2 · 2016-12-24T19:38:59.000Z

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Neil:

Sure; please feel free to submit a PR.

I'm happy to look into submitting a PR when I have a few minutes of downtime.

I'm not familiar with this stuff - but presumably you have Electrum clients that expect an enhanced electrum header? I assume these coins have working electrum-server implementations?

The only existing implementation I'm aware of is this: https://github.com/electrumalt/electrum-doge and https://github.com/electrumalt/electrum-doge-server . Given that that implementation is more than 2 years old, and to my knowledge is not in usage by anyone at the moment (not to mention I'm unimpressed by its code quality), I would have no objection to modifying the protocol used for AuxPoW with Electrum if there are any issues with the protocol used by that implementation. (There's interest in producing a new Namecoin fork of Electrum based on the current Electrum codebase, but I'm not sure when exactly that will happen. It might make sense to wait until that makes progress before worrying too much about AuxPoW in ElectrumX.)

…

Answer 3 · 2017-02-15T07:32:25.000Z

Didn't want to add a new issue for this as I think it may be related to auxpow extraction. I was trying to setup electrumx for Crown. Electrumx seems to be a much faster server than any of the older auxpow clients. I noticed Doge was on here as well, So i assume that the chain is able to sync?

Part way through the sync the server errors during an assertion check in read_block of lib/tx.py.

Answer 4 · 2017-02-15T08:09:46.000Z

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Alastair Clark:

Didn't want to add a new issue for this as I think it may be related to auxpow extraction. I was trying to setup electrumx for Crown. Electrumx seems to be a much faster server than any of the older auxpow clients. I noticed Doge was on here as well, So i assume that the chain is able to sync? Part way through the sync the server errors during an assertion check in read_block of lib/tx.py.

AFAIK missing AuxPoW support will just result in PoW validation not being performed by the client. If your server is hitting an assertion then it's probably unrelated to this issue (although if your block headers have a nonstandard structure due to AuxPoW you might need to do something to adjust for that).

…

Answer 5 · 2017-02-16T12:10:14.000Z

The block in question that it stop's on is after a few aux blocks have already been mined, I can't see any change in the block header, or coinbase header, Possible you could point me toward anything that may help with debugging our issue? Think I found the block in question. https://chainz.cryptoid.info/crw/block.dws?65113a4acb2165610335336eb15033b24136462d7fb6794edc32f5c995fc425a.htm

after that point the nonce drops to 0 and doesnt return to it's normal value. And the coinbase changed.... -_-

Answer 6 · 2017-02-16T14:05:53.000Z

Still a bit confused as to how dogecoin has no issues now? Considering they also have support for merged mining? Older versions of electrum work with our chain just fine. And we would love to use electrumx as opposed to electrum-server because of the performance benefits of electrumx

Answer 7 · 2017-02-16T14:22:55.000Z

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Alastair Clark:

Still a bit confused as to how dogecoin has no issues now? Considering they also have support for merged mining? Older versions of electrum work with our chain just fine. And we would love to use electrumx as opposed to electrum-server because of the performance benefits of electrumx

I suspect that you've encountered an issue unrelated to AuxPoW, but Dogecoin's initial implementation of AuxPoW was slightly more restrictive than Namecoin's, which caused Dogecoin-based AuxPoW code to detect errors when parsing the Namecoin blockchain. (This was fixed in libdohj after I reported the issue.) The errors being detected were in the coinbase commitments, so I really don't think the issue you're seeing is related, since AFAIK ElectrumX doesn't even try to parse the AuxPoW coinbase commitments.

…

Answer 8 · 2017-02-16T14:30:04.000Z

I'm almost sure this is related to auxpow, as it seems that the first block with the change in the coinbase transaction hash. fails to get checked in electrumx, We seem to use a similar coinbase hash to namecoins, and had domob from namecoin implement the code originally. I'm guessing that we're able to load the blockchain up until that point because we didn't implement auxpow until that block and the coinbase used was similar to bitcoin's not namecoin's.

Answer 9 · 2017-02-16T15:09:20.000Z

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Alastair Clark:

I'm almost sure this is related to auxpow, as it seems that the first block with the change in the coinbase transaction hash. fails to get checked in electrumx, We seem to use a similar coinbase hash to namecoins, and had domob implement the code originally.

Hmm, I just glanced at the relevant ElectrumX code, and I think you're right, I don't see how Dogecoin and Namecoin would be able to sync. In https://github.com/kyuupichan/electrumx/blob/7b8119d78749c30df521bd652fc d960c66b01e4a/lib/coins.py#L226 , HEADER_LEN is 80, and AuxPoW blocks have a header size greater than 80, so the transaction serializer is trying to parse part of the block header as transactions (which I assume would result in an assertion failure). Good catch. :)

…

Answer 10 · 2017-02-16T16:41:48.000Z

Thanks, I'll create an issue and see if we can get it sorted then :)

Answer 11 · 2017-02-16T21:42:18.000Z

To be clear, I'm not going to fix this, as I don't use these coins and so am unable to test what is and isn't working.
I will accept a pull request that fixes the issue(s). It sounds like the main issue might be as simple as bumping the header size at the right height, all that is needed there is a simple change to the coin definition in coins.py

Answer 12 · 2017-02-17T01:24:09.000Z

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Neil:

To be clear, I'm not going to fix this, as I don't use these coins and so am unable to test what is and isn't working. I will accept a pull request that fixes the issue(s). It sounds like the main issue might be as simple as bumping the header size at the right height, all that is needed there is a simple change to the coin definition in coins.py

It's not that simple; the header size of AuxPoW blocks is variable depending on things such as the size of the parent block's coinbase transaction. Some amount of parsing is needed to figure out the size of the header. For anyone who wants to look at fixing this, the libdohj source code is reasonably easy to read and will probably be helpful. I can't vouch for the various Dogecoin ports of Electrum. I might look into fixing this, but if I do it probably won't be very soon, so anyone who wants it sooner will have to do it themselves.

…