From rusty at rustcorp.com.au  Wed Apr 12 20:03:14 2017
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 12 Apr 2017 13:03:14 -0700
Subject: [Lightning-dev] RFC new BOLT proposal for creating and
	closing	channels using cold storage
In-Reply-To: <CAMpN3mKWR9j3vX4NfZuW6wvbheLhLhS+tdOs_DNmK0JM21d7Nw@mail.gmail.com>
References: <CAMpN3mKWR9j3vX4NfZuW6wvbheLhLhS+tdOs_DNmK0JM21d7Nw@mail.gmail.com>
Message-ID: <8737dd75rx.fsf@rustcorp.com.au>

Hi Jonathan,

        The issue of hotwallet security is a real one: great to see you
thinking deeply about it!  The ideal case would be that all keys are
offline, but of course we need the funding secret key and payment
basepoint secret for channel updates.

Note that before and after the channel, security is fairly easy: mutual
close can pay straight to a cold wallet address, and open waits for
several blocks anyway, so you can have the secret key offline until that
point and wait for someone to press a button to release it.

Once open, the following avenues are open to a malicious party who has
key access:

1. With cooperation of the peer, simply create a transaction which spends
   the funding tx.

2. If you can control the compromised node, you don't need cooperation
   of the peer: create an HTLC sending maximum amount out to some other
   place.

So we can mildly increase security with additional requirement where we
tell the other node "don't allow me to spend more then X without a
signed message from this other key".  That's mildly better than nothing.

In addition, a future Trezor firmware could also hold the channel
secrets and various enforce rules, too.  We've nominally got an HSM
daemon for this in our new implementation, but we don't use it for this
so far: more research needed!

Thanks!
Rusty.
        
Jonathan Underwood <junderwood at bitcoinbank.co.jp> writes:
> Hello all,
>
> I have written up a very primitive BOLT for consideration.
>
> https://gist.github.com/junderw/f6d0c023d7cefc1107a9c58d6d58aa5e
>
> If you would please let me know what you think of it, and especially ways
> we could possibly mitigate (or at least give the channel owners a fighting
> chance) the scenario where a single attacker compromises both sides of the
> channel, I would appreciate it.
>
> Thank you,
> Jonathan
>
> -- 
> -----------------
> Jonathan Underwood
> ??????? ??????????????
> -----------------
>
> ???????????????????????????????
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Comment: http://openpgpjs.org
>
> xsBNBFTSV/kBB/9FyhUaxI/2bfJ0pBp+y6YAim4LyOXeFDdtZL2C04T2eWBB
> +n2HXD3r9CIifdqefnc0VCKwPe2hpbGXKNVy33tnp3m76CPVwKvIooE/gCcI
> LJUIKwbdj1ydsuUiErOhuRaral+iDhEaWuZmSZc1SiBANcufQvTru6o3Ne1M
> hozenpFHdyUXL4zIgifglEKRRsQiqxpF8vyIo/A7u5bDZQPq1HAc9vL13Oe0
> 5ZhgXDMp0sgTfHVond6gNSJxWb7PqDLunY+kvINawqePEADkAJlvcZbXpc07
> RuX8+/FSRI0LPmZin6w0DuvzRAYAE/f1/OcqabWTIXbcmG3F32OmPS4PABEB
> AAHNMUpvbmF0aGFuIFVuZGVyd29vZCA8anVuZGVyd29vZEBiaXRjb2luYmFu
> ay5jby5qcD7CwHIEEAEIACYFAlTSV/0GCwkIBwMCCRCpJzta0+R7RQQVCAIK
> AxYCAQIbAwIeAQAAQXgH/jZh+WLLxx4Sznw5o53nROMn+WChasZ1cOoFzfAX
> RpFC5UZTXyTS1fMsA1vMA21B88FX/+UCxvCB3EHN6MrUIinc8SFh/oZX/041
> dwfFOFaN2LsWJ5xF9pZpRdz4e+Bzbfyhe7MC/7d7KsfwyiEWgPbH8N869SWd
> Qqu8WIH9hIDyyWU4rNx9Un440lZJhN79Z58vaw1q3FRq8qy+hKkMU7vi6PYq
> /D4WPrztfguqHe3vmtmlWaC8WGvy+AG7KEzinkc7VeIXdFtuLV70t3L9GyAV
> NPM+RVxi/nDhQ2FW9tYA0jJ0VYpRltkrMHTvlnP+VRqb/qbvss0ghaD3C7bi
> zCnOwE0EVNJX/QEH/2LRn75y2UIPVVd9Og6gT6Hfwh6CK2PcmjRzmGtY0ZU1
> wu/07CpAk3SP+5jm/o9FSVU46tE7d/VPw1gxj2vLryzsE8ticnUYtOVGzCgF
> mZgzcj+E8HNGLo5BiNaVqFVc1sf/bf3bGytVFWRsPoJmNgLTvwtJOZNXtOD/
> 3IAAdiFRifeKDvElMlNhNNYOFncr+O16pnyesmQpg95nVbvww4t8QUjy5c2p
> g+9W1ZLzlEY2GC8bsvhrQsikycyV/pRqzDJo3D+DPLlEB4xASmHnJh6vw0Og
> VieAt1CcWyzPZQRcEBUQ9TVemvoQ+CBeVEAlivXXHyGu4OPV9miV66G2WTkA
> EQEAAcLAXwQYAQgAEwUCVNJYAgkQqSc7WtPke0UCGwwAAAsUB/sGC6hlR5t1
> zTJkJlSJb2Rg4iX1BXHpf/8DKFCrZ5UjsLkeAIJQxpSLtCKPFArPHLGLUowq
> HtpCFRg30pCRSKdzlTTM4ossrnHjQj3AFyedodPeoYbWSUNgHiM7pY9m5uNL
> I1Xg1K5AuAtrsD66vAtha5vL/ZIEmMkGl4mwC1dj4ueSCvfGP+xG5iGKiq8f
> P+PDscI99YtbeaLknXjTEYZMkqCYOsEstWx6YLu13Ee8rwrk2TkeavUiybD+
> PnaP3kISoaMPew3LNvnfc6ZJ/UxcEwmGf3UchSYRp3g/lMWcyFF624sszOQY
> ULPn8N650ejg39n11SmCwk7aHoyYxfjs
> =RpF5
> -----END PGP PUBLIC KEY BLOCK-----
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev