bLIP-56: Pluggable Channel Factories.

[ZmnSCPxj-jr]

Channel factories are a way of scaling Bitcoin by hosting offchain channels, not directly onchain, but in another offchain mechanism. The hosting mechanism is called a channel factory. The channel factory can change the funding amounts of channels inside the factory, without any onchain transactions.

This pluggable channel factory protocol is a proposal by which base node software can handle channel state, while letting external code handle state of the channel factory. As far as the node software is concerned, the channel is a "0-conf" channel whose funding transaction never seems to confirm, even though the state is actually backed by an offchain mechanism that ensures that the channel can be unilaterally closed in the worst-case scenario.

When the channel factory wants to change the funding amounts of hosted channels, the node software acts as if a splice operation is being performed, which changes the funding amount (or not changes it, if it is other channels in the same factory that are changed but not this one). When the channel factory offchain mechanism has settled to a new state, it is as if a splice transaction was successfully deeply confirmed.

[ZmnSCPxj-jr]

Updated blip number to 56, as per PR number.

[t-bast]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

[tnull]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

Hmm, I'm a bit confused about exact process (also related to #55), as bLIP-01 states:

Reference Implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol.

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

[t-bast]

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

[tnull]

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

Alright, makes sense, thanks for clarifying!

[8144225309]

Currently a small team is building SuperScalar wallet on top of this blip56 design with a cln plugin specific to SuperScalar to keep blip56 neutral and application agnostic.

Any input, requested changes, feature requests, comments or concerns are greatly appreciated while we are still early in the development process for this bLIP-56 implementation. Thanks!

bLIP-56 Fork of Core Lightning:
https://github.com/8144225309/lightning/tree/blip-56
SuperScalar-CLN Plugin:
https://github.com/8144225309/superscalar-cln
WIP SuperScalar Wallet:
https://github.com/8144225309/superscalar-wallet
Original SuperScalar-CLI (implementation reference):
https://github.com/8144225309/SuperScalar
SuperScalar Docs:
https://www.superscalar.win
https://github.com/8144225309/superscalar-docs

[ZmnSCPxj-jr]

Channel factories are a way of scaling Bitcoin by hosting offchain channels, not directly onchain, but in another offchain mechanism. The hosting mechanism is called a channel factory. The channel factory can change the funding amounts of channels inside the factory, without any onchain transactions.

This pluggable channel factory protocol is a proposal by which base node software can handle channel state, while letting external code handle state of the channel factory. As far as the node software is concerned, the channel is a "0-conf" channel whose funding transaction never seems to confirm, even though the state is actually backed by an offchain mechanism that ensures that the channel can be unilaterally closed in the worst-case scenario.

When the channel factory wants to change the funding amounts of hosted channels, the node software acts as if a splice operation is being performed, which changes the funding amount (or not changes it, if it is other channels in the same factory that are changed but not this one). When the channel factory offchain mechanism has settled to a new state, it is as if a splice transaction was successfully deeply confirmed.

[ZmnSCPxj-jr]

Updated blip number to 56, as per PR number.

[t-bast]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

[tnull]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

Hmm, I'm a bit confused about exact process (also related to #55), as bLIP-01 states:

Reference Implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol.

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

[t-bast]

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

[tnull]

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

Alright, makes sense, thanks for clarifying!

[8144225309]

Currently a small team is building SuperScalar wallet on top of this blip56 design with a cln plugin specific to SuperScalar to keep blip56 neutral and application agnostic.

Any input, requested changes, feature requests, comments or concerns are greatly appreciated while we are still early in the development process for this bLIP-56 implementation. Thanks!

bLIP-56 Fork of Core Lightning:
https://github.com/8144225309/lightning/tree/blip-56
SuperScalar-CLN Plugin:
https://github.com/8144225309/superscalar-cln
WIP SuperScalar Wallet:
https://github.com/8144225309/superscalar-wallet
Original SuperScalar-CLI (implementation reference):
https://github.com/8144225309/SuperScalar
SuperScalar Docs:
https://www.superscalar.win
https://github.com/8144225309/superscalar-docs

[ZmnSCPxj-jr]

Channel factories are a way of scaling Bitcoin by hosting offchain channels, not directly onchain, but in another offchain mechanism. The hosting mechanism is called a channel factory. The channel factory can change the funding amounts of channels inside the factory, without any onchain transactions.

This pluggable channel factory protocol is a proposal by which base node software can handle channel state, while letting external code handle state of the channel factory. As far as the node software is concerned, the channel is a "0-conf" channel whose funding transaction never seems to confirm, even though the state is actually backed by an offchain mechanism that ensures that the channel can be unilaterally closed in the worst-case scenario.

When the channel factory wants to change the funding amounts of hosted channels, the node software acts as if a splice operation is being performed, which changes the funding amount (or not changes it, if it is other channels in the same factory that are changed but not this one). When the channel factory offchain mechanism has settled to a new state, it is as if a splice transaction was successfully deeply confirmed.

[ZmnSCPxj-jr]

Updated blip number to 56, as per PR number.

[t-bast]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

[tnull]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

Hmm, I'm a bit confused about exact process (also related to #55), as bLIP-01 states:

Reference Implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol.

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

[t-bast]

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

[tnull]

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

Alright, makes sense, thanks for clarifying!

[8144225309]

Currently a small team is building SuperScalar wallet on top of this blip56 design with a cln plugin specific to SuperScalar to keep blip56 neutral and application agnostic.

Any input, requested changes, feature requests, comments or concerns are greatly appreciated while we are still early in the development process for this bLIP-56 implementation. Thanks!

bLIP-56 Fork of Core Lightning:
https://github.com/8144225309/lightning/tree/blip-56
SuperScalar-CLN Plugin:
https://github.com/8144225309/superscalar-cln
WIP SuperScalar Wallet:
https://github.com/8144225309/superscalar-wallet
Original SuperScalar-CLI (implementation reference):
https://github.com/8144225309/SuperScalar
SuperScalar Docs:
https://www.superscalar.win
https://github.com/8144225309/superscalar-docs

[ZmnSCPxj-jr]

Channel factories are a way of scaling Bitcoin by hosting offchain channels, not directly onchain, but in another offchain mechanism. The hosting mechanism is called a channel factory. The channel factory can change the funding amounts of channels inside the factory, without any onchain transactions.

This pluggable channel factory protocol is a proposal by which base node software can handle channel state, while letting external code handle state of the channel factory. As far as the node software is concerned, the channel is a "0-conf" channel whose funding transaction never seems to confirm, even though the state is actually backed by an offchain mechanism that ensures that the channel can be unilaterally closed in the worst-case scenario.

When the channel factory wants to change the funding amounts of hosted channels, the node software acts as if a splice operation is being performed, which changes the funding amount (or not changes it, if it is other channels in the same factory that are changed but not this one). When the channel factory offchain mechanism has settled to a new state, it is as if a splice transaction was successfully deeply confirmed.

[ZmnSCPxj-jr]

Updated blip number to 56, as per PR number.

[t-bast]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

[tnull]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

Hmm, I'm a bit confused about exact process (also related to #55), as bLIP-01 states:

Reference Implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol.

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

[t-bast]

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

[tnull]

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

Alright, makes sense, thanks for clarifying!

[8144225309]

Currently a small team is building SuperScalar wallet on top of this blip56 design with a cln plugin specific to SuperScalar to keep blip56 neutral and application agnostic.

Any input, requested changes, feature requests, comments or concerns are greatly appreciated while we are still early in the development process for this bLIP-56 implementation. Thanks!

bLIP-56 Fork of Core Lightning:
https://github.com/8144225309/lightning/tree/blip-56
SuperScalar-CLN Plugin:
https://github.com/8144225309/superscalar-cln
WIP SuperScalar Wallet:
https://github.com/8144225309/superscalar-wallet
Original SuperScalar-CLI (implementation reference):
https://github.com/8144225309/SuperScalar
SuperScalar Docs:
https://www.superscalar.win
https://github.com/8144225309/superscalar-docs

[ZmnSCPxj-jr]

Channel factories are a way of scaling Bitcoin by hosting offchain channels, not directly onchain, but in another offchain mechanism. The hosting mechanism is called a channel factory. The channel factory can change the funding amounts of channels inside the factory, without any onchain transactions.

This pluggable channel factory protocol is a proposal by which base node software can handle channel state, while letting external code handle state of the channel factory. As far as the node software is concerned, the channel is a "0-conf" channel whose funding transaction never seems to confirm, even though the state is actually backed by an offchain mechanism that ensures that the channel can be unilaterally closed in the worst-case scenario.

When the channel factory wants to change the funding amounts of hosted channels, the node software acts as if a splice operation is being performed, which changes the funding amount (or not changes it, if it is other channels in the same factory that are changed but not this one). When the channel factory offchain mechanism has settled to a new state, it is as if a splice transaction was successfully deeply confirmed.

[ZmnSCPxj-jr]

Updated blip number to 56, as per PR number.

[t-bast]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

[tnull]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

Hmm, I'm a bit confused about exact process (also related to #55), as bLIP-01 states:

Reference Implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol.

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

[t-bast]

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

[tnull]

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

Alright, makes sense, thanks for clarifying!

[8144225309]

Currently a small team is building SuperScalar wallet on top of this blip56 design with a cln plugin specific to SuperScalar to keep blip56 neutral and application agnostic.

Any input, requested changes, feature requests, comments or concerns are greatly appreciated while we are still early in the development process for this bLIP-56 implementation. Thanks!

bLIP-56 Fork of Core Lightning:
https://github.com/8144225309/lightning/tree/blip-56
SuperScalar-CLN Plugin:
https://github.com/8144225309/superscalar-cln
WIP SuperScalar Wallet:
https://github.com/8144225309/superscalar-wallet
Original SuperScalar-CLI (implementation reference):
https://github.com/8144225309/SuperScalar
SuperScalar Docs:
https://www.superscalar.win
https://github.com/8144225309/superscalar-docs

[ZmnSCPxj-jr]

Channel factories are a way of scaling Bitcoin by hosting offchain channels, not directly onchain, but in another offchain mechanism. The hosting mechanism is called a channel factory. The channel factory can change the funding amounts of channels inside the factory, without any onchain transactions.

This pluggable channel factory protocol is a proposal by which base node software can handle channel state, while letting external code handle state of the channel factory. As far as the node software is concerned, the channel is a "0-conf" channel whose funding transaction never seems to confirm, even though the state is actually backed by an offchain mechanism that ensures that the channel can be unilaterally closed in the worst-case scenario.

When the channel factory wants to change the funding amounts of hosted channels, the node software acts as if a splice operation is being performed, which changes the funding amount (or not changes it, if it is other channels in the same factory that are changed but not this one). When the channel factory offchain mechanism has settled to a new state, it is as if a splice transaction was successfully deeply confirmed.

[ZmnSCPxj-jr]

Updated blip number to 56, as per PR number.

[t-bast]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

[tnull]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

Hmm, I'm a bit confused about exact process (also related to #55), as bLIP-01 states:

Reference Implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol.

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

[t-bast]

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

[tnull]

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

Alright, makes sense, thanks for clarifying!

[8144225309]

Currently a small team is building SuperScalar wallet on top of this blip56 design with a cln plugin specific to SuperScalar to keep blip56 neutral and application agnostic.

Any input, requested changes, feature requests, comments or concerns are greatly appreciated while we are still early in the development process for this bLIP-56 implementation. Thanks!

bLIP-56 Fork of Core Lightning:
https://github.com/8144225309/lightning/tree/blip-56
SuperScalar-CLN Plugin:
https://github.com/8144225309/superscalar-cln
WIP SuperScalar Wallet:
https://github.com/8144225309/superscalar-wallet
Original SuperScalar-CLI (implementation reference):
https://github.com/8144225309/SuperScalar
SuperScalar Docs:
https://www.superscalar.win
https://github.com/8144225309/superscalar-docs

[ZmnSCPxj-jr]

Channel factories are a way of scaling Bitcoin by hosting offchain channels, not directly onchain, but in another offchain mechanism. The hosting mechanism is called a channel factory. The channel factory can change the funding amounts of channels inside the factory, without any onchain transactions.

This pluggable channel factory protocol is a proposal by which base node software can handle channel state, while letting external code handle state of the channel factory. As far as the node software is concerned, the channel is a "0-conf" channel whose funding transaction never seems to confirm, even though the state is actually backed by an offchain mechanism that ensures that the channel can be unilaterally closed in the worst-case scenario.

When the channel factory wants to change the funding amounts of hosted channels, the node software acts as if a splice operation is being performed, which changes the funding amount (or not changes it, if it is other channels in the same factory that are changed but not this one). When the channel factory offchain mechanism has settled to a new state, it is as if a splice transaction was successfully deeply confirmed.

[ZmnSCPxj-jr]

Updated blip number to 56, as per PR number.

[t-bast]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

[tnull]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

Hmm, I'm a bit confused about exact process (also related to #55), as bLIP-01 states:

Reference Implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol.

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

[t-bast]

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

[tnull]

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

Alright, makes sense, thanks for clarifying!

[8144225309]

Currently a small team is building SuperScalar wallet on top of this blip56 design with a cln plugin specific to SuperScalar to keep blip56 neutral and application agnostic.

Any input, requested changes, feature requests, comments or concerns are greatly appreciated while we are still early in the development process for this bLIP-56 implementation. Thanks!

bLIP-56 Fork of Core Lightning:
https://github.com/8144225309/lightning/tree/blip-56
SuperScalar-CLN Plugin:
https://github.com/8144225309/superscalar-cln
WIP SuperScalar Wallet:
https://github.com/8144225309/superscalar-wallet
Original SuperScalar-CLI (implementation reference):
https://github.com/8144225309/SuperScalar
SuperScalar Docs:
https://www.superscalar.win
https://github.com/8144225309/superscalar-docs

[ZmnSCPxj-jr]

Channel factories are a way of scaling Bitcoin by hosting offchain channels, not directly onchain, but in another offchain mechanism. The hosting mechanism is called a channel factory. The channel factory can change the funding amounts of channels inside the factory, without any onchain transactions.

This pluggable channel factory protocol is a proposal by which base node software can handle channel state, while letting external code handle state of the channel factory. As far as the node software is concerned, the channel is a "0-conf" channel whose funding transaction never seems to confirm, even though the state is actually backed by an offchain mechanism that ensures that the channel can be unilaterally closed in the worst-case scenario.

When the channel factory wants to change the funding amounts of hosted channels, the node software acts as if a splice operation is being performed, which changes the funding amount (or not changes it, if it is other channels in the same factory that are changed but not this one). When the channel factory offchain mechanism has settled to a new state, it is as if a splice transaction was successfully deeply confirmed.

[ZmnSCPxj-jr]

Updated blip number to 56, as per PR number.

[t-bast]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

[tnull]

I think we should wait for a reference implementation, indicating that this will actually be used in practice before merging this bLIP. But it's fine to keep the PR open to guide future implementers!

Hmm, I'm a bit confused about exact process (also related to #55), as bLIP-01 states:

Reference Implementation -- The reference implementation must be completed before any bLIP is given status "Final", but it need not be completed before the bLIP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Lightning protocol.

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

[t-bast]

Wouldn't this indicate that bLIPs would get accepted (read: merged) in Draft status if they meet the other criteria, and could advance to Proposed/Final once the reference implmentation is finished?

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

[tnull]

True, but if there is an implementation (or potentially multiple) that are in-progress: the goal of merging early in draft is mainly when more than one implementations are in-progress and they want to make sure they're building on the same foundations. I believe that we shouldn't accept bLIPs that nobody is actually implementing: if this is just a research protocol that should be iterated on before someone actually wants to use it, delving bitcoin is a better place.

Alright, makes sense, thanks for clarifying!

[8144225309]

Currently a small team is building SuperScalar wallet on top of this blip56 design with a cln plugin specific to SuperScalar to keep blip56 neutral and application agnostic.

Any input, requested changes, feature requests, comments or concerns are greatly appreciated while we are still early in the development process for this bLIP-56 implementation. Thanks!

bLIP-56 Fork of Core Lightning:
https://github.com/8144225309/lightning/tree/blip-56
SuperScalar-CLN Plugin:
https://github.com/8144225309/superscalar-cln
WIP SuperScalar Wallet:
https://github.com/8144225309/superscalar-wallet
Original SuperScalar-CLI (implementation reference):
https://github.com/8144225309/SuperScalar
SuperScalar Docs:
https://www.superscalar.win
https://github.com/8144225309/superscalar-docs