-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NOMERGE: Support signet as parent chain #414
base: elements-0.14.1
Are you sure you want to change the base?
NOMERGE: Support signet as parent chain #414
Conversation
91059bf
to
4380518
Compare
fwiw, this seems to be working in the explorer, see jtimon/elements-explorer@df65994 |
src/pow.cpp
Outdated
{ | ||
if (g_solution_blocks) { | ||
if (hash == params.hashGenesisBlock) return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we don't need or want this here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You would need to provide the signature for the genesis block otherwise, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is used to validate the parent chain. The sidechain doesn't validate the parent chain's genesis block (in fact, not even the parent chain should validate the genesis block, the genesis block is a consensus rule in itself and thus doesn't need to be validated, not when it's pow nor when it's blocksigned).
0fd6752
to
1e8648a
Compare
This can now be tested with:
Assuming you're building https://github.com/kallewoof/bitcoin/commits/signet ( b4c9e78 ) on The changes to feature_fedpeg shouldn't break other ways to call the tests:
|
qa/rpc-tests/feature_fedpeg.py
Outdated
self.binary = self.options.parent_binpath if self.options.parent_binpath != "" else None | ||
self.nodes.append(start_node(n, self.options.tmpdir, self.extra_args[n], binary=self.binary, chain=self.parent_chain)) | ||
if self.options.parent_type == 'signet': | ||
self.nodes[n].importprivkey('8Hh8jNjkx1aSCgEk3iq9Vo2APZUSDQJVt3rJ2BRpb5Tavqb68vW') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this magic value related to the one in -signet_blockscript
? Perhaps define them as variables somewhere earlier then together so that it's clear they are related.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will eventually go away, I assume, unless we agree on a global default signet (seems unlikely, at least for upstream to bitcoin/bitcoin).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, we could generate the block signing script and the wif dynamically by starting a node, getnewaddress, dumpprivkey, etc beforehand and then starting the actual testing nodes with the resulting script.
This is just the wif for the public key corresponding to the script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I was using for generating the p2pk sript and the corresponding wif to import:
qa/rpc-tests/feature_fedpeg.py
Outdated
@@ -140,13 +153,21 @@ def test_pegout(self, parent_chain_addr, sidechain): | |||
break | |||
assert pegout_tested | |||
|
|||
# TODO Remove when signet supports generate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an upstream issue to track for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, all we have for now is bitcoin/bitcoin@master...kallewoof:signet where I'm commenting directly on the code.
Pinging @kallewoof since I can't remember if I suggested this to him.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I intend to make a PR against bitcoin core. For now there is a PR against my repo here: kallewoof/bitcoin#4
* Contains a mapping of hash to signature data for each block header | ||
* in signet networks. | ||
*/ | ||
extern std::map<uint256,std::vector<uint8_t>> g_blockheader_payload_map; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this supposed to be like a global cache? It doesn't seem to get emptied ever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An in-memory cache that, most importantly, doesn't inflate memory usage when signet feature is off.
This does mean an ever-growing set when on, yes. Wonder what cane be done with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kallewoof thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's ever growing, yep. It could be cached since header sigs are stored along with headers. I haven't thought too much about it, as even a 1 million block chain (that's 2x the lifetime of bitcoin right now) would only have ~100 MB of RAM use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also when it's a 11-of-15 multisig? Or even larger if this script doesn't have the same script limits as normal tx scripts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right you would basically store siglen + alpha per block. For a 15 multisig over ECDSA it'd get big quicker, I suspect, but I assume we will eventually switch to Schnorr multisigs long term.
Now we can review signet more easily with kallewoof/bitcoin#4 |
1e8648a
to
9dcf7dd
Compare
Needed rebase. Also, removed one TODO and its workaround in the tests since now generate works directly with signet. |
bbc58b9
to
4d9ad55
Compare
Moved to kallewoof/bitcoin#5 and removed the special case for the p2sh test for signet. |
4d9ad55
to
f95af12
Compare
signed has simpler signed blocks but no CT or any other extra feature
f95af12
to
1518f6e
Compare
Updated, now it doesn't have the wif and blockscript hardcoded but generated aumotatically |
1518f6e
to
23cb9ae
Compare
Fixed travis. |
Could we get travis testing against a signet parent binary? |
That would be ideal of course. Could be as simple as the Bitcoin extra Travis thing. But then there need to be some kind of "stable" signet release.. |
@stevenroose I'm simply reticent to merge something we can't be confident of stability of the protocol itself. @kallewoof any plans on "finalizing" this, whatever that means to you? :) We clearly can adapt implementation later to later upgrades. |
Maybe when the elements-0.17 work is done, signet is "released" and we can download a stable binary. I wouldn't mind to keep this open. Or either way just have a custom-compiled signet binary in Travis. |
6ba0d07
to
cc7d24f
Compare
Added a commit (not squashed yet) supposedly adapting the test to #433 as parent chain binary.
|
@kallewoof have you or do you have intentions of releasing binaries for signet? We could at least get this ported to |
@instagibbs Sorry for lack of activity. I am intending on proposing a BIP for signet in the near future. Things will be switched around a bit, I suspect, so no binaries yet. Edit: to actually answer your question, I think having binaries for signet would be useful and will see about making those available. No timeframe at this point in time. |
Ok just curious. Still interested at least in supporting as parent chain. |
signet has simpler signed blocks but no CT or any other extra feature from elements.
Suggestion to test this: #433
Dependencies: