Skip to content
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

Refactor: Easier support for chains with multiple genesis assets #164

Closed

Conversation

jtimon
Copy link
Contributor

@jtimon jtimon commented Apr 20, 2017

Some POC chains may be interested in having more than one genesis asset for spiking the additional step of issuing a second asset (or more) for a particular demonstration. Presumably they would copy and modify CElementsParams to create their own chain.

For the 2 way peg, as a next step, a multiasset chain can support pegs to the same parent chain with different federation scripts, or even pegged to different parent chains. We don't support that yet, but in the same way this makes testing that kind of extension easier to test without needing to issue new pegged assets during the tests. Issuing them on the fly can be a next step.

Intentionally, the new "feature" isn't tested, for that would require either a "genesis block id HF" or a new chain. I would prefer if that is done in a later PR (see jtimon/elements@e13-multi-genesis...jtimon:e13-multi-genesis-test for a WIP) and this is merged without testing first purely on the grounds that the behavior should remain perfectly equivalent and if at any point this is not the case for this PR, it should be nacked by reviewers.

Dependencies:

instagibbs and others added 3 commits April 19, 2017 23:43
Since the scriptPubKey for signing blocks never changes, there's no
point in repeating it with every block header.
Using Bitcoin genesis mainnet hash for pegged-bitcoin asset id was a
mistake in the first place.
@jtimon jtimon force-pushed the e13-multi-genesis branch from 104d073 to d7f11c5 Compare April 20, 2017 02:16
@instagibbs
Copy link
Collaborator

quick read ACK

@jtimon
Copy link
Contributor Author

jtimon commented Jun 22, 2017

Replaced by #191

@jtimon jtimon closed this Jun 22, 2017
gwillen pushed a commit that referenced this pull request Jun 1, 2022
…-sort Peers table

986bf78 qt: Emit dataChanged signal to dynamically re-sort Peers table (Hennadii Stepanov)

Pull request description:

  [By default](https://doc.qt.io/qt-5/qsortfilterproxymodel.html#details), the `PeerTableSortProxy`
  > dynamically re-sorts ... data whenever the original model changes.

  That is not the case on master (8cdf917) as in ecbd911 (#164) no signals are emitted to notify about model changes.

  This PR uses a dedicated [`dataChanged`](https://doc.qt.io/qt-5/qabstractitemmodel.html#dataChanged) signal.

  Fixes #367.

  An alternative to #374.

ACKs for top commit:
  jarolrod:
    ACK 986bf78

Tree-SHA512: dcb92c2f9a2c632880429e9528007db426d2ad938c64dfa1f1538c03e4b62620df52ad7daf33b582976c67b472ff76bc0dae707049f4bbbd4941232cee9ce3d4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants