Skip to content

Replace keys API with Signer API to support hardware wallets eventually - #404

Merged
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom
TheBlueMatt:2019-11-signer-api
Dec 12, 2019
Merged

Replace keys API with Signer API to support hardware wallets eventually#404
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom
TheBlueMatt:2019-11-signer-api

Conversation

@TheBlueMatt

@TheBlueMattTheBlueMatt commented Nov 28, 2019

Copy link
Copy Markdown
Collaborator

Built on #403 cause I'm lazy (as always), so just the top two commits.

Its obviously insufficient, but its a decent size diff so figured should get the ball rolling by just getting it upstream.

@TheBlueMattTheBlueMatt changed the title 2019 11 signer apiReplace keys API with Signer API to support hardware wallets eventuallyNov 28, 2019
@TheBlueMattTheBlueMatt mentioned this pull request Dec 2, 2019
Closed
@TheBlueMatt

TheBlueMatt commented Dec 5, 2019

Copy link
Copy Markdown
CollaboratorAuthor

Process note: I'd like to land #347 before this and cut a release so that we don't have a partial API in a release that is needed to get important protocol features that other clients are requiring now.

@TheBlueMatt

TheBlueMatt commented Dec 5, 2019

Copy link
Copy Markdown
CollaboratorAuthor

Amended to use the new remote transaction signing API in the initial funding_signed signature generation.

@TheBlueMatt
TheBlueMattforce-pushed the 2019-11-signer-api branch 4 times, most recently from 3bbaec3 to 42e1d49CompareDecember 9, 2019 21:43
ariard
ariard reviewed Dec 10, 2019
View reviewed changes

@ariardariard left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this breaking anything for the new ChannelKeys::sign_remote_commitment method. The rest of the change are just templating.

I've taken my nits + better documentation of current assumptions of KeysInterface in commit ariard@95f666d

I think that's a good head start in making hardware-wallet support a first-class concern of RL.

Comment threadlightning/src/chain/keysinterface.rs Outdated
Comment threadlightning/src/chain/keysinterface.rs Outdated
@TheBlueMattTheBlueMatt added this to the 0.0.11 milestone Dec 11, 2019
TheBlueMattand others added 5 commits December 11, 2019 17:29
@TheBlueMatt
Bump bitcoin dep to 0.21
580a423
@TheBlueMatt
Bump versions to 0.0.10
8defcf1
@TheBlueMatt
Make ChannelKeys an API and template Channel with it.
f2a2fd0
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
@TheBlueMatt
Make commitment transaction signing a part of ChannelKeys.
262666a
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Antoine Riard@TheBlueMatt
Document more current security assumption of KeysInterface
35814b6
Improve some comments of interface methods.
@TheBlueMatt

TheBlueMatt commented Dec 11, 2019

Copy link
Copy Markdown
CollaboratorAuthor

Took your commit. Will merge after the 0.0.10 bump is done.

@TheBlueMatt
TheBlueMatt merged commit edab29e into lightningdevkit:masterDec 12, 2019
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
@ariardariardariard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

0.0.50

Development

Successfully merging this pull request may close these issues.

2 participants

@TheBlueMatt@ariard
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Replace keys API with Signer API to support hardware wallets eventually by TheBlueMatt · Pull Request #404 · lightningdevkit/rust-lightning · GitHub
Skip to content
Replace keys API with Signer API to support hardware wallets eventually - #404
Merged
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Dec 12, 2019
Merged
Replace keys API with Signer API to support hardware wallets eventually#404
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 28, 2019

Copy link


Copy Markdown

Collaborator
Built on #403 cause I'm lazy (as always), so just the top two commits.
Its obviously insufficient, but its a decent size diff so figured should get the ball rolling by just getting it upstream.
@TheBlueMattTheBlueMatt
changed the title
2019 11 signer apiReplace keys API with Signer API to support hardware wallets eventuallyNov 28, 2019
@TheBlueMattTheBlueMatt
mentioned this pull request
Dec 2, 2019

Closed

@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Process note: I'd like to land #347 before this and cut a release so that we don't have a partial API in a release that is needed to get important protocol features that other clients are requiring now.
@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Amended to use the new remote transaction signing API in the initial funding_signed signature generation.
@TheBlueMatt
TheBlueMattforce-pushed
the
2019-11-signer-api
branch
4 times, most recently
from
3bbaec3 to
42e1d49CompareDecember 9, 2019 21:43
ariard
ariard
reviewed
Dec 10, 2019
View reviewed changes
@ariardariard
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this breaking anything for the new ChannelKeys::sign_remote_commitment method. The rest of the change are just templating.
I've taken my nits + better documentation of current assumptions of KeysInterface in commit ariard@95f666d
I think that's a good head start in making hardware-wallet support a first-class concern of RL.
Comment threadlightning/src/chain/keysinterface.rs
Outdated

Comment threadlightning/src/chain/keysinterface.rs
Outdated

@TheBlueMattTheBlueMatt
added this to the 0.0.11 milestone
Dec 11, 2019
TheBlueMattand others
added 5 commits
December 11, 2019 17:29
@TheBlueMatt
Bump bitcoin dep to 0.21
580a423
@TheBlueMatt
Bump versions to 0.0.10
8defcf1
@TheBlueMatt
Make ChannelKeys an API and template Channel with it.
f2a2fd0
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
@TheBlueMatt
Make commitment transaction signing a part of ChannelKeys.
262666a
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Antoine Riard@TheBlueMatt
Document more current security assumption of KeysInterface
35814b6
Improve some comments of interface methods.
@TheBlueMatt
TheBlueMatt
commented
Dec 11, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Took your commit. Will merge after the 0.0.10 bump is done.
@TheBlueMatt
TheBlueMatt
merged commit edab29e
into
lightningdevkit:masterDec 12, 2019
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


1 more reviewer

@ariardariardariard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone

0.0.50

Development

Successfully merging this pull request may close these issues.

2 participants

@TheBlueMatt@ariard

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Replace keys API with Signer API to support hardware wallets eventually by TheBlueMatt · Pull Request #404 · lightningdevkit/rust-lightning · GitHub
Skip to content
Replace keys API with Signer API to support hardware wallets eventually - #404
Merged
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Dec 12, 2019
Merged
Replace keys API with Signer API to support hardware wallets eventually#404
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 28, 2019

Copy link


Copy Markdown

Collaborator
Built on #403 cause I'm lazy (as always), so just the top two commits.
Its obviously insufficient, but its a decent size diff so figured should get the ball rolling by just getting it upstream.
@TheBlueMattTheBlueMatt
changed the title
2019 11 signer apiReplace keys API with Signer API to support hardware wallets eventuallyNov 28, 2019
@TheBlueMattTheBlueMatt
mentioned this pull request
Dec 2, 2019

Closed

@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Process note: I'd like to land #347 before this and cut a release so that we don't have a partial API in a release that is needed to get important protocol features that other clients are requiring now.
@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Amended to use the new remote transaction signing API in the initial funding_signed signature generation.
@TheBlueMatt
TheBlueMattforce-pushed
the
2019-11-signer-api
branch
4 times, most recently
from
3bbaec3 to
42e1d49CompareDecember 9, 2019 21:43
ariard
ariard
reviewed
Dec 10, 2019
View reviewed changes
@ariardariard
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this breaking anything for the new ChannelKeys::sign_remote_commitment method. The rest of the change are just templating.
I've taken my nits + better documentation of current assumptions of KeysInterface in commit ariard@95f666d
I think that's a good head start in making hardware-wallet support a first-class concern of RL.
Comment threadlightning/src/chain/keysinterface.rs
Outdated

Comment threadlightning/src/chain/keysinterface.rs
Outdated

@TheBlueMattTheBlueMatt
added this to the 0.0.11 milestone
Dec 11, 2019
TheBlueMattand others
added 5 commits
December 11, 2019 17:29
@TheBlueMatt
Bump bitcoin dep to 0.21
580a423
@TheBlueMatt
Bump versions to 0.0.10
8defcf1
@TheBlueMatt
Make ChannelKeys an API and template Channel with it.
f2a2fd0
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
@TheBlueMatt
Make commitment transaction signing a part of ChannelKeys.
262666a
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Antoine Riard@TheBlueMatt
Document more current security assumption of KeysInterface
35814b6
Improve some comments of interface methods.
@TheBlueMatt
TheBlueMatt
commented
Dec 11, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Took your commit. Will merge after the 0.0.10 bump is done.
@TheBlueMatt
TheBlueMatt
merged commit edab29e
into
lightningdevkit:masterDec 12, 2019
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


1 more reviewer

@ariardariardariard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone

0.0.50

Development

Successfully merging this pull request may close these issues.

2 participants

@TheBlueMatt@ariard

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Replace keys API with Signer API to support hardware wallets eventually by TheBlueMatt · Pull Request #404 · lightningdevkit/rust-lightning · GitHub
Skip to content
Replace keys API with Signer API to support hardware wallets eventually - #404
Merged
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Dec 12, 2019
Merged
Replace keys API with Signer API to support hardware wallets eventually#404
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 28, 2019

Copy link


Copy Markdown

Collaborator
Built on #403 cause I'm lazy (as always), so just the top two commits.
Its obviously insufficient, but its a decent size diff so figured should get the ball rolling by just getting it upstream.
@TheBlueMattTheBlueMatt
changed the title
2019 11 signer apiReplace keys API with Signer API to support hardware wallets eventuallyNov 28, 2019
@TheBlueMattTheBlueMatt
mentioned this pull request
Dec 2, 2019

Closed

@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Process note: I'd like to land #347 before this and cut a release so that we don't have a partial API in a release that is needed to get important protocol features that other clients are requiring now.
@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Amended to use the new remote transaction signing API in the initial funding_signed signature generation.
@TheBlueMatt
TheBlueMattforce-pushed
the
2019-11-signer-api
branch
4 times, most recently
from
3bbaec3 to
42e1d49CompareDecember 9, 2019 21:43
ariard
ariard
reviewed
Dec 10, 2019
View reviewed changes
@ariardariard
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this breaking anything for the new ChannelKeys::sign_remote_commitment method. The rest of the change are just templating.
I've taken my nits + better documentation of current assumptions of KeysInterface in commit ariard@95f666d
I think that's a good head start in making hardware-wallet support a first-class concern of RL.
Comment threadlightning/src/chain/keysinterface.rs
Outdated

Comment threadlightning/src/chain/keysinterface.rs
Outdated

@TheBlueMattTheBlueMatt
added this to the 0.0.11 milestone
Dec 11, 2019
TheBlueMattand others
added 5 commits
December 11, 2019 17:29
@TheBlueMatt
Bump bitcoin dep to 0.21
580a423
@TheBlueMatt
Bump versions to 0.0.10
8defcf1
@TheBlueMatt
Make ChannelKeys an API and template Channel with it.
f2a2fd0
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
@TheBlueMatt
Make commitment transaction signing a part of ChannelKeys.
262666a
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Antoine Riard@TheBlueMatt
Document more current security assumption of KeysInterface
35814b6
Improve some comments of interface methods.
@TheBlueMatt
TheBlueMatt
commented
Dec 11, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Took your commit. Will merge after the 0.0.10 bump is done.
@TheBlueMatt
TheBlueMatt
merged commit edab29e
into
lightningdevkit:masterDec 12, 2019
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


1 more reviewer

@ariardariardariard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone

0.0.50

Development

Successfully merging this pull request may close these issues.

2 participants

@TheBlueMatt@ariard

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Replace keys API with Signer API to support hardware wallets eventually by TheBlueMatt · Pull Request #404 · lightningdevkit/rust-lightning · GitHub
Skip to content
Replace keys API with Signer API to support hardware wallets eventually - #404
Merged
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Dec 12, 2019
Merged
Replace keys API with Signer API to support hardware wallets eventually#404
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 28, 2019

Copy link


Copy Markdown

Collaborator
Built on #403 cause I'm lazy (as always), so just the top two commits.
Its obviously insufficient, but its a decent size diff so figured should get the ball rolling by just getting it upstream.
@TheBlueMattTheBlueMatt
changed the title
2019 11 signer apiReplace keys API with Signer API to support hardware wallets eventuallyNov 28, 2019
@TheBlueMattTheBlueMatt
mentioned this pull request
Dec 2, 2019

Closed

@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Process note: I'd like to land #347 before this and cut a release so that we don't have a partial API in a release that is needed to get important protocol features that other clients are requiring now.
@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Amended to use the new remote transaction signing API in the initial funding_signed signature generation.
@TheBlueMatt
TheBlueMattforce-pushed
the
2019-11-signer-api
branch
4 times, most recently
from
3bbaec3 to
42e1d49CompareDecember 9, 2019 21:43
ariard
ariard
reviewed
Dec 10, 2019
View reviewed changes
@ariardariard
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this breaking anything for the new ChannelKeys::sign_remote_commitment method. The rest of the change are just templating.
I've taken my nits + better documentation of current assumptions of KeysInterface in commit ariard@95f666d
I think that's a good head start in making hardware-wallet support a first-class concern of RL.
Comment threadlightning/src/chain/keysinterface.rs
Outdated

Comment threadlightning/src/chain/keysinterface.rs
Outdated

@TheBlueMattTheBlueMatt
added this to the 0.0.11 milestone
Dec 11, 2019
TheBlueMattand others
added 5 commits
December 11, 2019 17:29
@TheBlueMatt
Bump bitcoin dep to 0.21
580a423
@TheBlueMatt
Bump versions to 0.0.10
8defcf1
@TheBlueMatt
Make ChannelKeys an API and template Channel with it.
f2a2fd0
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
@TheBlueMatt
Make commitment transaction signing a part of ChannelKeys.
262666a
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Antoine Riard@TheBlueMatt
Document more current security assumption of KeysInterface
35814b6
Improve some comments of interface methods.
@TheBlueMatt
TheBlueMatt
commented
Dec 11, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Took your commit. Will merge after the 0.0.10 bump is done.
@TheBlueMatt
TheBlueMatt
merged commit edab29e
into
lightningdevkit:masterDec 12, 2019
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


1 more reviewer

@ariardariardariard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone

0.0.50

Development

Successfully merging this pull request may close these issues.

2 participants

@TheBlueMatt@ariard

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Replace keys API with Signer API to support hardware wallets eventually by TheBlueMatt · Pull Request #404 · lightningdevkit/rust-lightning · GitHub
Skip to content
Replace keys API with Signer API to support hardware wallets eventually - #404
Merged
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Dec 12, 2019
Merged
Replace keys API with Signer API to support hardware wallets eventually#404
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 28, 2019

Copy link


Copy Markdown

Collaborator
Built on #403 cause I'm lazy (as always), so just the top two commits.
Its obviously insufficient, but its a decent size diff so figured should get the ball rolling by just getting it upstream.
@TheBlueMattTheBlueMatt
changed the title
2019 11 signer apiReplace keys API with Signer API to support hardware wallets eventuallyNov 28, 2019
@TheBlueMattTheBlueMatt
mentioned this pull request
Dec 2, 2019

Closed

@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Process note: I'd like to land #347 before this and cut a release so that we don't have a partial API in a release that is needed to get important protocol features that other clients are requiring now.
@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Amended to use the new remote transaction signing API in the initial funding_signed signature generation.
@TheBlueMatt
TheBlueMattforce-pushed
the
2019-11-signer-api
branch
4 times, most recently
from
3bbaec3 to
42e1d49CompareDecember 9, 2019 21:43
ariard
ariard
reviewed
Dec 10, 2019
View reviewed changes
@ariardariard
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this breaking anything for the new ChannelKeys::sign_remote_commitment method. The rest of the change are just templating.
I've taken my nits + better documentation of current assumptions of KeysInterface in commit ariard@95f666d
I think that's a good head start in making hardware-wallet support a first-class concern of RL.
Comment threadlightning/src/chain/keysinterface.rs
Outdated

Comment threadlightning/src/chain/keysinterface.rs
Outdated

@TheBlueMattTheBlueMatt
added this to the 0.0.11 milestone
Dec 11, 2019
TheBlueMattand others
added 5 commits
December 11, 2019 17:29
@TheBlueMatt
Bump bitcoin dep to 0.21
580a423
@TheBlueMatt
Bump versions to 0.0.10
8defcf1
@TheBlueMatt
Make ChannelKeys an API and template Channel with it.
f2a2fd0
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
@TheBlueMatt
Make commitment transaction signing a part of ChannelKeys.
262666a
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Antoine Riard@TheBlueMatt
Document more current security assumption of KeysInterface
35814b6
Improve some comments of interface methods.
@TheBlueMatt
TheBlueMatt
commented
Dec 11, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Took your commit. Will merge after the 0.0.10 bump is done.
@TheBlueMatt
TheBlueMatt
merged commit edab29e
into
lightningdevkit:masterDec 12, 2019
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


1 more reviewer

@ariardariardariard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone

0.0.50

Development

Successfully merging this pull request may close these issues.

2 participants

@TheBlueMatt@ariard

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Replace keys API with Signer API to support hardware wallets eventually by TheBlueMatt · Pull Request #404 · lightningdevkit/rust-lightning · GitHub
Skip to content
Replace keys API with Signer API to support hardware wallets eventually - #404
Merged
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Dec 12, 2019
Merged
Replace keys API with Signer API to support hardware wallets eventually#404
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 28, 2019

Copy link


Copy Markdown

Collaborator
Built on #403 cause I'm lazy (as always), so just the top two commits.
Its obviously insufficient, but its a decent size diff so figured should get the ball rolling by just getting it upstream.
@TheBlueMattTheBlueMatt
changed the title
2019 11 signer apiReplace keys API with Signer API to support hardware wallets eventuallyNov 28, 2019
@TheBlueMattTheBlueMatt
mentioned this pull request
Dec 2, 2019

Closed

@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Process note: I'd like to land #347 before this and cut a release so that we don't have a partial API in a release that is needed to get important protocol features that other clients are requiring now.
@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Amended to use the new remote transaction signing API in the initial funding_signed signature generation.
@TheBlueMatt
TheBlueMattforce-pushed
the
2019-11-signer-api
branch
4 times, most recently
from
3bbaec3 to
42e1d49CompareDecember 9, 2019 21:43
ariard
ariard
reviewed
Dec 10, 2019
View reviewed changes
@ariardariard
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this breaking anything for the new ChannelKeys::sign_remote_commitment method. The rest of the change are just templating.
I've taken my nits + better documentation of current assumptions of KeysInterface in commit ariard@95f666d
I think that's a good head start in making hardware-wallet support a first-class concern of RL.
Comment threadlightning/src/chain/keysinterface.rs
Outdated

Comment threadlightning/src/chain/keysinterface.rs
Outdated

@TheBlueMattTheBlueMatt
added this to the 0.0.11 milestone
Dec 11, 2019
TheBlueMattand others
added 5 commits
December 11, 2019 17:29
@TheBlueMatt
Bump bitcoin dep to 0.21
580a423
@TheBlueMatt
Bump versions to 0.0.10
8defcf1
@TheBlueMatt
Make ChannelKeys an API and template Channel with it.
f2a2fd0
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
@TheBlueMatt
Make commitment transaction signing a part of ChannelKeys.
262666a
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Antoine Riard@TheBlueMatt
Document more current security assumption of KeysInterface
35814b6
Improve some comments of interface methods.
@TheBlueMatt
TheBlueMatt
commented
Dec 11, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Took your commit. Will merge after the 0.0.10 bump is done.
@TheBlueMatt
TheBlueMatt
merged commit edab29e
into
lightningdevkit:masterDec 12, 2019
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


1 more reviewer

@ariardariardariard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone

0.0.50

Development

Successfully merging this pull request may close these issues.

2 participants

@TheBlueMatt@ariard

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Replace keys API with Signer API to support hardware wallets eventually by TheBlueMatt · Pull Request #404 · lightningdevkit/rust-lightning · GitHub
Skip to content
Replace keys API with Signer API to support hardware wallets eventually - #404
Merged
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Dec 12, 2019
Merged
Replace keys API with Signer API to support hardware wallets eventually#404
TheBlueMatt merged 5 commits into
lightningdevkit:masterfrom 
TheBlueMatt:2019-11-signer-api
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 28, 2019

Copy link


Copy Markdown

Collaborator
Built on #403 cause I'm lazy (as always), so just the top two commits.
Its obviously insufficient, but its a decent size diff so figured should get the ball rolling by just getting it upstream.
@TheBlueMattTheBlueMatt
changed the title
2019 11 signer apiReplace keys API with Signer API to support hardware wallets eventuallyNov 28, 2019
@TheBlueMattTheBlueMatt
mentioned this pull request
Dec 2, 2019

Closed

@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Process note: I'd like to land #347 before this and cut a release so that we don't have a partial API in a release that is needed to get important protocol features that other clients are requiring now.
@TheBlueMatt
TheBlueMatt
commented
Dec 5, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Amended to use the new remote transaction signing API in the initial funding_signed signature generation.
@TheBlueMatt
TheBlueMattforce-pushed
the
2019-11-signer-api
branch
4 times, most recently
from
3bbaec3 to
42e1d49CompareDecember 9, 2019 21:43
ariard
ariard
reviewed
Dec 10, 2019
View reviewed changes
@ariardariard
left a comment


Copy link


Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this breaking anything for the new ChannelKeys::sign_remote_commitment method. The rest of the change are just templating.
I've taken my nits + better documentation of current assumptions of KeysInterface in commit ariard@95f666d
I think that's a good head start in making hardware-wallet support a first-class concern of RL.
Comment threadlightning/src/chain/keysinterface.rs
Outdated

Comment threadlightning/src/chain/keysinterface.rs
Outdated

@TheBlueMattTheBlueMatt
added this to the 0.0.11 milestone
Dec 11, 2019
TheBlueMattand others
added 5 commits
December 11, 2019 17:29
@TheBlueMatt
Bump bitcoin dep to 0.21
580a423
@TheBlueMatt
Bump versions to 0.0.10
8defcf1
@TheBlueMatt
Make ChannelKeys an API and template Channel with it.
f2a2fd0
Instead of having in-memory access to the list of private keys
associated with a channel, we should have a generic API which
allows us to request signing, allowing the user to store private
keys any way they like.
The first step is the (rather mechanical) process of templating
the entire tree of ChannelManager -> Channel impls by the
key-providing type. In a later commit we should expose only public
keys where possible.
@TheBlueMatt
Make commitment transaction signing a part of ChannelKeys.
262666a
This adds a new fn to ChannelKeys which is called when we generte
a new remote commitment transaction for signing. While it may be
theoretically possible to unwind state updates by disconnecting and
reconnecting as well as making appropriate state machine changes,
the effort required to get it correct likely outweighs the UX cost
of "preflighting" the requests to hardwre wallets.
Antoine Riard@TheBlueMatt
Document more current security assumption of KeysInterface
35814b6
Improve some comments of interface methods.
@TheBlueMatt
TheBlueMatt
commented
Dec 11, 2019

Copy link


Copy Markdown

CollaboratorAuthor
Took your commit. Will merge after the 0.0.10 bump is done.
@TheBlueMatt
TheBlueMatt
merged commit edab29e
into
lightningdevkit:masterDec 12, 2019
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


1 more reviewer

@ariardariardariard left review comments
Reviewers whose approvals may not affect merge requirements

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone

0.0.50

Development

Successfully merging this pull request may close these issues.

2 participants

@TheBlueMatt@ariard