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.

Sign up for GitHub

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

Jump to bottom

Pick a licence for the specs #2

Closed
josephpoon opened this issue Nov 15, 2016 · 3 comments
Closed

Pick a licence for the specs #2

josephpoon opened this issue Nov 15, 2016 · 3 comments

Comments

@josephpoon
Copy link
Collaborator

CC-BY?
GNU FDL?
WTFPL?
@Roasbeef
Copy link
Collaborator

My vote is for the WTFPL 🙌🏾.

WTFPL

rustyrussell referenced this issue in rustyrussell/lightning-rfc Nov 15, 2016
@rustyrussell
BOLT #2, #5: derive maximum HTLC limit based on penalty size.
9bc22e1 
Calculations are put in 05-onchain.md, and referred to by 02-peer-protocol.

The number is 600, comfortably under the 626 theoretical limit.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell referenced this issue in rustyrussell/lightning-rfc Nov 15, 2016
@rustyrussell
BOLT #2, #5: derive maximum HTLC limit based on penalty size.
f4a46a9 
Calculations are put in 05-onchain.md, and referred to by 02-peer-protocol.

The number is 600, comfortably under the 626 theoretical limit.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell added a commit that referenced this issue Nov 15, 2016
@rustyrussell
BOLT #2, #5: derive maximum HTLC limit based on penalty size.
9b7a292 
Calculations are put in 05-onchain.md, and referred to by 02-peer-protocol.

The number is 600, comfortably under the 626 theoretical limit.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell added a commit that referenced this issue Nov 15, 2016
@rustyrussell
BOLT #2: fix cross-references.
d1b7c78 
And remove a duplicate sentence.

Signed-off-by: Rusty Russell <[email protected]>
@cdecker
Copy link
Collaborator

cdecker commented Nov 15, 2016

I quite like CC-BY but I have no idea of the implications :-)

@rustyrussell
Copy link
Collaborator

Joseph Poon [email protected] writes:

CC-BY?
GNU FDL?
WTFPL?

CC-BY would be my default guess, but I'll ask People Who Know This Stuff
and see if there's some reason to prefer something else here.

Cheers,
Rusty.

rustyrussell pushed a commit that referenced this issue Nov 18, 2016
@pm47 @rustyrussell
BOLT #2: Fix indent levels
18824a8 
(Rebased by Rusty Russell <[email protected]>)
rustyrussell pushed a commit that referenced this issue Nov 18, 2016
@pm47 @rustyrussell
BOLT #2: Rename fee-per-kilobyte to feerate-per-kilobyte for clarity.
e81ffb3 
(Rebased by Rusty Russell <[email protected]>)
rustyrussell pushed a commit that referenced this issue Nov 18, 2016
@pm47 @rustyrussell
BOLT #2: Add TOC
db9ad2e 
(Rebased by Rusty Russell <[email protected]>)
rustyrussell referenced this issue in rustyrussell/lightning-rfc Nov 21, 2016
@rustyrussell
BOLT #2: delete duplicate sentence.
a15f3f9 
It's already in the next paragraph.

Signed-off-by: Rusty Russell <[email protected]>
@rustyrussell rustyrussell mentioned this issue Nov 21, 2016
Merged
rustyrussell added a commit that referenced this issue Nov 22, 2016
@rustyrussell
BOLT #2: fill in descriptions and requirements for remaining fields.
9137aed
rustyrussell added a commit that referenced this issue Nov 22, 2016
@rustyrussell
Add CC-BY.
193bbef 
Closes: #2
Signed-off-by: Rusty Russell <[email protected]>
@rustyrussell rustyrussell mentioned this issue Nov 22, 2016
Merged
rustyrussell referenced this issue in rustyrussell/lightning-rfc Jan 3, 2017
@rustyrussell
BOLT #2: allow different handling of update_fail_malformed_htlc if SH…
edd4d75 
…A wrong.

Suggested-by: Olaoluwa Osuntokun <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
rustyrussell referenced this issue in rustyrussell/lightning-rfc Jan 5, 2017
@rustyrussell
BOLT #2: allow different handling of update_fail_malformed_htlc if SH…
6fd5997 
…A wrong.

Suggested-by: Olaoluwa Osuntokun <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
rustyrussell added a commit that referenced this issue Jan 5, 2017
@rustyrussell
BOLT #2: allow different handling of update_fail_malformed_htlc if SH…
d57b33d 
…A wrong.

Suggested-by: Olaoluwa Osuntokun <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
@sstone sstone mentioned this issue May 31, 2017
Merged
andrewshvv referenced this issue in andrewshvv/lightning-rfc Jul 2, 2017
@andrewshvv
BOLT #2: Make onion packet vary size
c4a1f90 
My apology if I have missed the context of the conversation, but it seems for me that in order to update the sphinx onion packet version in the future we have to have onion packet size decoupled from the `update_add_htlc` message, so that we could make smooth transitions, by simultaneously maintaining several types of the onion packet.
@ysangkok ysangkok mentioned this issue Jul 14, 2017
Closed
Roasbeef referenced this issue in Roasbeef/lightning-rfc Jul 24, 2017
@Roasbeef
glossary: move definition of chain_hash to BOLT #0
8e74fcd 
This commit modifies the glossary to add a new entry which defines the
usage of `chain_hash` throughout the remainder of the documents.
Additionally, we now also specify which chain hash we expect for
Bitcoin within the glossary.

This commit also modifies BOLT #2 and #7 to omit the definition of the
expected `chain_hash` value for Bitcoin.
Roasbeef referenced this issue in Roasbeef/lightning-rfc Jul 24, 2017
@Roasbeef
glossary: move definition of chain_hash to BOLT #0
0df422c 
This commit modifies the glossary to add a new entry which defines the
usage of `chain_hash` throughout the remainder of the documents.
Additionally, we now also specify which chain hash we expect for
Bitcoin within the glossary.

This commit also modifies BOLT #2 and #7 to omit the definition of the
expected `chain_hash` value for Bitcoin.
rustyrussell referenced this issue in Roasbeef/lightning-rfc Aug 8, 2017
@Roasbeef @rustyrussell
glossary: move definition of chain_hash to BOLT #0
aeaeda7 
This commit modifies the glossary to add a new entry which defines the
usage of `chain_hash` throughout the remainder of the documents.
Additionally, we now also specify which chain hash we expect for
Bitcoin within the glossary.

This commit also modifies BOLT #2 and #7 to omit the definition of the
expected `chain_hash` value for Bitcoin.
rustyrussell pushed a commit that referenced this issue Aug 8, 2017
@Roasbeef @rustyrussell
glossary: move definition of chain_hash to BOLT #0
25fc33b 
This commit modifies the glossary to add a new entry which defines the
usage of `chain_hash` throughout the remainder of the documents.
Additionally, we now also specify which chain hash we expect for
Bitcoin within the glossary.

This commit also modifies BOLT #2 and #7 to omit the definition of the
expected `chain_hash` value for Bitcoin.
rustyrussell referenced this issue in rustyrussell/lightning-rfc Oct 2, 2017
@rustyrussell
BOLT #2: Swap cltv_expiry_delta values on open/accept for channel.
9576afa 
There's a mistake in the spec, where we were using the outgoing side of
a channel to control the CTLV delta.  But it's the receipient which is
vulnerable if it's too low, so the recipient should set it.

This exchanges values at channel open, and relies on the counterparty
to advertize it correctly in its `channel_update` messages.

There's another patch which changes the "Risks With HTLC Timeouts"
section to cover the setting of cltv_expiry_delta in detail, but
that's not ready yet.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell referenced this issue in rustyrussell/lightning-rfc Oct 3, 2017
@rustyrussell
BOLT #2: Swap cltv_expiry_delta values on open/accept for channel.
670aed9 
There's a mistake in the spec, where we were using the outgoing side of
a channel to control the CTLV delta.  But it's the receipient which is
vulnerable if it's too low, so the recipient should set it.

This exchanges values at channel open, and relies on the counterparty
to advertize it correctly in its `channel_update` messages.

There's another patch which changes the "Risks With HTLC Timeouts"
section to cover the setting of cltv_expiry_delta in detail, but
that's not ready yet.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell referenced this issue in rustyrussell/lightning-rfc Oct 3, 2017
@rustyrussell
BOLT #2: Swap cltv_expiry_delta values on open/accept for channel.
7bc1f60 
There's a mistake in the spec, where we were using the outgoing side of
a channel to control the CTLV delta.  But it's the receipient which is
vulnerable if it's too low, so the recipient should set it.

This exchanges values at channel open, and relies on the counterparty
to advertize it correctly in its `channel_update` messages.

There's another patch which changes the "Risks With HTLC Timeouts"
section to cover the setting of cltv_expiry_delta in detail, but
that's not ready yet.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell referenced this issue in rustyrussell/lightning-rfc Oct 3, 2017
@rustyrussell
BOLT #2: Swap cltv_expiry_delta values on open/accept for channel.
7d49850 
There's a mistake in the spec, where we were using the outgoing side of
a channel to control the CTLV delta.  But it's the receipient which is
vulnerable if it's too low, so the recipient should set it.

This exchanges values at channel open, and relies on the counterparty
to advertize it correctly in its `channel_update` messages.

There's another patch which changes the "Risks With HTLC Timeouts"
section to cover the setting of cltv_expiry_delta in detail, but
that's not ready yet.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell referenced this issue in rustyrussell/lightning-rfc Jan 30, 2018
@rustyrussell
BOLT #2: bad update_fee after shutdown when all HTLCs cleared.
ba03a76 
I got an unexpected update_fee message after `shutdown` exchange,
which is currently legal:

A: shutdown (no htlcs)
                          B: receive shutdown
                          B: reply with shutdown & closing_signed

A: send update_fee & commitment_signed
A: receive shutdown

Simplest to ban any updates (currently, just update_fee) from adding a
new commitment tx while we're at the end of shutdown.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell referenced this issue in rustyrussell/lightning-rfc Feb 5, 2018
@rustyrussell
BOLT #2: bad update_fee after shutdown when all HTLCs cleared.
5f998e5 
I got an unexpected update_fee message after `shutdown` exchange,
which is currently legal:

A: shutdown (no htlcs)
                          B: receive shutdown
                          B: reply with shutdown & closing_signed

A: send update_fee & commitment_signed
A: receive shutdown

Simplest to ban any updates (currently, just update_fee) from adding a
new commitment tx while we're at the end of shutdown.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell added a commit that referenced this issue Feb 5, 2018
@rustyrussell
BOLT #2: bad update_fee after shutdown when all HTLCs cleared.
120003e 
I got an unexpected update_fee message after `shutdown` exchange,
which is currently legal:

A: shutdown (no htlcs)
                          B: receive shutdown
                          B: reply with shutdown & closing_signed

A: send update_fee & commitment_signed
A: receive shutdown

Simplest to ban any updates (currently, just update_fee) from adding a
new commitment tx while we're at the end of shutdown.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell referenced this issue in rustyrussell/lightning-rfc Oct 21, 2018
@rustyrussell
BOLT #2: order htlc_signatures by BIP69 + increasing CLTV.
fddb1d4 
We express it has how the outputs are ordered, but the only way you can
detect that is by the htlc_signatures order, which is the part which really
matters.

I finally reproduced this, BTW, which is why I'm digging it up!

Closes: lightning#448
Signed-off-by: Rusty Russell <[email protected]>
@sstone sstone mentioned this issue Oct 29, 2018
Closed
fjahr referenced this issue in fjahr/lightning-mw Dec 20, 2018
BMW #2: Edit channel funding and flow chart for MW context
a5974d7
fjahr referenced this issue in fjahr/lightning-mw Dec 20, 2018
BMW #2: Edit open_channel and accept_channel messages for mw context
44f91aa
fjahr referenced this issue in fjahr/lightning-mw Dec 20, 2018
BWM #2: Modify channel funding messages for MW context
e8828f6
fjahr referenced this issue in fjahr/lightning-mw Dec 20, 2018
BMW #2: Edit cooperative closing for MW context, missing lots of details
7d94e0e
fjahr referenced this issue in fjahr/lightning-mw Jan 1, 2019
BMW lightning#3: Edit for MW context; BMW #2: Add WIP
2d3bb5c
fjahr referenced this issue in fjahr/lightning-mw Jan 5, 2019
BMW #2: Complete first edit for MW context
83c209b
fjahr referenced this issue in fjahr/lightning-mw Jan 10, 2019
BMW #2: Fix spelling errors
524fc49
fjahr referenced this issue in fjahr/lightning-mw Jan 10, 2019
BMW #2: Fix spelling errors
690d5bb
cdecker referenced this issue in rustyrussell/lightning-rfc Jan 22, 2019
@rustyrussell @cdecker
BOLT #2: order htlc_signatures by BIP69 + increasing CLTV.
c7d0f4b 
We express it has how the outputs are ordered, but the only way you can
detect that is by the htlc_signatures order, which is the part which really
matters.

I finally reproduced this, BTW, which is why I'm digging it up!

Closes: lightning#448
Signed-off-by: Rusty Russell <[email protected]>
cdecker pushed a commit that referenced this issue Jan 22, 2019
@rustyrussell @cdecker
BOLT #2: order htlc_signatures by BIP69 + increasing CLTV.
a57ff00 
We express it has how the outputs are ordered, but the only way you can
detect that is by the htlc_signatures order, which is the part which really
matters.

I finally reproduced this, BTW, which is why I'm digging it up!

Closes: #448
Signed-off-by: Rusty Russell <[email protected]>
@lightning lightning deleted a comment Aug 12, 2021
@animatedbarber animatedbarber mentioned this issue Sep 18, 2021
Merged
@Roasbeef Roasbeef mentioned this issue Mar 14, 2022
Closed
Crypt-iQ pushed a commit to Crypt-iQ/bolts that referenced this issue Sep 20, 2022
@rustyrussell
BOLT lightning#2: Set an initiator in quiescence.
b96218b 
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

Signed-off-by: Rusty Russell <[email protected]>
@JohnLaw2 JohnLaw2 mentioned this issue Nov 26, 2022
Open
ProofOfKeags pushed a commit to ProofOfKeags/bolts that referenced this issue Apr 10, 2024
@rustyrussell
BOLT lightning#2: Set an initiator in quiescence.
9832e17 
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

Signed-off-by: Rusty Russell <[email protected]>
rustyrussell added a commit that referenced this issue Jun 17, 2024
@rustyrussell
BOLT 2: quiescence protocol.
5dd9d9c 
Signed-off-by: Rusty Russell <[email protected]>




Header from folded patch 'bolt_2__set_an_initiator_in_quiescence.patch':

BOLT #2: Set an initiator in quiescence.

This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.

Signed-off-by: Rusty Russell <[email protected]>



Header from folded patch 'option_quiesce__feature_to_support_stfu_method.patch':

option_quiesce: feature to support stfu method.

In practice, sftu is useless unless you have something (e.g. channel_upgrade)
which uses it, but adding a feature is best practice IMHO.

Signed-off-by: Rusty Russell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cdecker @rustyrussell @Roasbeef @josephpoon