X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=README.md;h=6a9369ea9b8ca8a7e35ace4a261f5cc0e0d38090;hb=refs%2Fheads%2F2018-10-oops-xxx;hp=ac512ed8d5045dc81cd8f24823b7a4ff623e8a14;hpb=6185a2819090bd077954244c5e2adaab5efcaa1a;p=rust-lightning

diff --git a/README.md b/README.md
index ac512ed8..6a9369ea 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,7 @@
 Rust-Lightning, not Rusty's Lightning!
 
-Currently somewhere near 5% towards usable, published to see if there is any
-real interest from folks in either contributing to or using a lightning rust
-library.
+Currently somewhere near 10% towards usable, published to see if there is any
+real interest from folks in using a lightning rust library.
 
 The goal is to provide a full-featured but also incredibly flexible lightning
 implementation, allowing the user to decide how they wish to use it. With that
@@ -20,46 +19,8 @@ non-optional/non-test/non-library dependencies. Really really do not add
 dependencies with dependencies. Do convince Andrew to cut down dependency usage
 in rust-bitcoin.
 
-Assorted random TODOs:
-
- * Create a general timer interface - this should be passed around in reference
-   form to most objects to allow them to register functions which are called on
-   a timer. By default we should provide an implementation of this which uses
-   some newfangled rusty promise-y library, but should generally ensure a
-   client can simply integrate this into whatever existing timer interface
-   they use.
-
- * Networking...having a simple bytes-in-bytes-out interface which does message
-   handling and calls our encryption layer is probably the right approach. We
-   should then also probably use the same promise-y library we use for timers
-   to do socket selection and reading/writing.
-
- * Figure out how to expose when-to-connect and who-to-connect-to.
-
- * Implement when-to-connect and who-to-connect-to based on route/node rumoring
-   and channelmanager state.
-
- * Some kind of serialization format for on-disk storage of things like
-   channels, channelmonitors, routing db, etc.
-
- * BOLT 10/network bootstrapping implementation.
-
- * Some kind of DoS thing including ban tracking and putting that info in
-   HandleError (and also rename HandleError) to be propagated up...and then
-   handled.
-
- * All the random TODOs and unimplemented!()s across the codebase.
-
- * BOLT 11 (invoice/address creation/generation) implementation
-
- * Type-ify our somewhat random usage of Uint256/[u8; 32]. Use Sha256dHash
-   where appropriate, create our own types for everything else.
-
- * Some kind of logging subsystem/API.
-
 Notes on coding style:
  * Use tabs. If you want to align lines, use spaces. Any desired alignment
    should display fine at any tab-length display setting.
 
-License is AGPL, but with agreement that Matt can relicense under any other
-OSI-approved license at will (and likely will with sufficient motivation).
+License is Apache-2.0.