RSKIP-186 - Active Federation creation block height

[josedahlquist]

No description provided.

[marcos-iov]

The names sound a bit confusing to me, I had to read a couple of times what the difference between each is.

Maybe:

federationCreationBlockHeight
federationActivationBlockHeight

What do you think?

[josedahlquist]

• activeFederationCreationBlockHeight: stores the active Federation creation height. This value is the one the user would get
• nextFederationCreationBlockHeight: this is a temporary value created when a new Federation is committed. This committed Federation won't be activated until the network's configuration delay is achieved.

I'll try better explaining this in the RSKIP.

Thanks!

[donequis]

This doesn't seem to solve the issue that is addressing at the description.

When the Federation change voting process finishes, the Bridge emmits a `commit_federation` event. This event can be used to provide a blockchain proof of the Federation address when requested. Nowadays doing this would imply navigating the blockchain to determine when it was emmited, or constantly monitoring said events.

An user requesting the current federation can't validate with this event that the address provided it is actually the current federation. The reasonable thing would be to have a storage key with the federation address and present a storage proof of it or something similar.

[josedahlquist]

This doesn't seem to solve the issue that is addressing at the description.

When the Federation change voting process finishes, the Bridge emmits a `commit_federation` event. This event can be used to provide a blockchain proof of the Federation address when requested. Nowadays doing this would imply navigating the blockchain to determine when it was emmited, or constantly monitoring said events.

An user requesting the current federation can't validate with this event that the address provided it is actually the current federation. The reasonable thing would be to have a storage key with the federation address and present a storage proof of it or something similar.

You are correct @donequis, this is not enough to provide that functionality. But it's the required consensus change to be able to later create said functionality in the node itself (via an json-rpc method most likely)

[donequis]

I think that this is not enough to create such functionality (at least not cleanly). With these changes a node will be able to find a block with the event and present a proof for such an event. The problem is that the user receiving the proof can't verify that the provided address is the actual federation address (i.e. there was no such an event after the given one). The user will be able to check that the address was at least active once in the past, which is not an enough guarantee.

The only solution is to provide a proof of the height/tx execution and only then provide the event to the user. But it would be easier to save the federation address and send it directly to the user with a proof of storage

[juli]

IMO this RSKIP tries to address two independent problems and there are alternative solutions for both:

1. Add a way to flag transactions to the Bitcoin multisig as "donation" (e.g., OP_RETURN) independent of the origin of the transaction.
2. Log the current multisig Bitcoin address as frequently as possible (e.g., for each updateCollections)

Solution 1 is more generic than this proposal and can be used in the future as part of the ERP recovery and could be supported by PowPeg hardware device if necessary, it can also be used in migrations (simplifying them?)

Solution 2 allows a client without a full node to verify a merkle proof of a transaction receipt including an event with the multisig address and determine if it is the current one or not. The client needs to know the current blockchain height (as always) and the frequency of updates and reject proofs that are too old.