After experimenting for some time trying to set up a bitcoin full node using BTCD, an alternative full node implementation, I discovered a bug that in my opinion is a dealbreaker until the devs invest some effort into fixing it. While trying to sync my node to the network, I noticed the time to sync blocks continued to increase as the block height rises. My fear is that eventually the time to sync a block will exceed the rate that new blocks are generated. You can see this behavior in a plot of sync times collected from the log files - the two day gap in the data is from where I stopped syncing to mess with config files.
Community member l0k1verloren explains in the github issue thread that he believes the fixes required are quite extensive. The main developers have not said much on the issue.
Hmm, just in case it is worth to report a bug to Github, maybe one day somebody will fix it.
Thanks for the notice! I don't use btcd, but this is not good to see. I also read on that thread that btcd bootstraps from one peer!!! How can that be decentralized!? I hope that is not true!
Did you check the logs? What's the error if any?
The logs seem to indicate the program isnt receiving my input at all. Just "waiting for wallet encryption password" until i send an interrupt
2019-11-11 16:30:50.008 [INF] LTND: Version: 0.8.0-beta commit=v0.8.0-beta-163-gb222b6e6250be0adea1d880800fde60f6b8695d1, build=production, logging=default
2019-11-11 16:30:50.008 [INF] LTND: Active chain: Bitcoin (network=testnet)
2019-11-11 16:30:50.009 [INF] CHDB: Checking for schema update: latest_version=11, db_version=11
2019-11-11 16:30:50.016 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080
2019-11-11 16:30:50.016 [INF] RPCS: password RPC server listening on 127.0.0.1:10009
2019-11-11 16:30:50.017 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, or `lncli changepassword` to change the password of an existing wallet and unlock it.
2019-11-11 16:31:00.475 [INF] LTND: Received interrupt
2019-11-11 16:31:00.475 [INF] LTND: Shutting down...
2019-11-11 16:31:00.475 [INF] LTND: Gracefully shutting down.
2019-11-11 16:31:00.476 [ERR] LTND: Unable to set up wallet password listeners: shutting down
2019-11-11 16:31:00.476 [INF] LTND: Shutdown complete
looks like something to do with how docker handles the console shell. Can you ssh into your instance instead of using the docker command line and try it?
Are you starting LND with nohup lnd & ? That will ensure the process continues running in background.
Unfortunately, I won't help, but soon Lightning support will be in Electrum, so you will be able to configure the whole Electrum server.
"It`s easy to send btc on-chain to someone. You just need their address and nothing more. You can send to it as many times as you want. This hurts privacy, but makes everything really easy for the sender. A charity can simply put their Bitcoin address on their website for example and anyone could donate to them. It`s not the same for Lightning. Since a different invoice is required for every single payment, a youtuber would not be able to accept donations over the LN easily, just on-chain. The goal of this proposal is to make it possible to do both.
Since any message can be routed and sent through the LN we could also make a request and ask our recipient`s node to generate an invoice for an amount chosen by us and then send it to us, just like those text messages. Then we can decode this invoice and if everyone is OK (the amount is correct) we can attempt to pay it. All of this can happen under the hood. The UI/UX doesn't even need to change much. Instead of pasting an invoice in the "send" field of a wallet, we just paste a node's public key.
Allowing anyone to make our node generate invoices is a bad idea. They could send a million requests and crash it. To prevent denial-of-service attacks, we should implement the following measures:
Auto-Generated invoices should be with short expiration times. 10 minutes for example.
A maximum of X invoices can be generated for a given node at a time. Let`s say X = 10. Once a node has requested 10 invoices it can request another one only when a) at least one of the previous 10 invoices has been paid or b) at least one of the previous invoices has expired.
Nodes which have requested Y invoices, but haven't paid any of them could be banned from requesting new invoices for a day. If this behaviour continues the node could be permanently banned and any channels opened with it could be closed. Maybe an option to manually override this ban would be nice to have. A good value for Y might be 30.
Nodes which have no channels open should not be allowed to request invoices. This prevents an attacker from spinning up 1000 nodes and requesting 10000 invoices from us.
The idea is to be able to send bitcoins over the Lightning Network to a static node`s public key, instead of having to ask for an invoice each time. The LN itself could be used to route requests for new invoices and the answers to those requests between the sender's and the recipient's nodes. The recipient`s node still needs to be online though. Maybe if we combine this with something like Lightning Rod we could achieve the same experience as with on-chain Bitcoin payments.
It`s also worth mentioning that one would not be able to do this for every node. Older nodes which have not upgraded to newer software which supports this new protocol addition simply won't know what to do when they get such a request and they won't reply with an invoice. If we want consistency we need everyone to upgrade. Or the vast majority at least."
=== === ===
https://medium.com/breez-technology/introducing-lightning-rod-2e0a40d3e44a
https://www.reddit.com/r/Bitcoin/comments/dr94ui/lightning_network_improvement_proposal_a_way_to/
LND has sphinx payments which do this. I believe that ZapRead node should accept payments this way. I have not had time to test it. I agree that this is a much desired feature for LN.
There's a new lnurl-rfc that will provide a way to accept payments with only a qr code.
QR code withdrawal already exists and I even use on my site.
You just need a wallet that supports lnurl which Bluewallet, blw and wallet of Satoshi do.
https://github.com/btcontract/lnurl-rfc/blob/master/spec.md
Thanks - I like this since I have interest, but found the delivery quite dry. I think the space needs some technical instruction from a dynamic speaker - someone like Andreas Antonopolous. Or Roasbeef @ 25% speed.
Hi
I don't see this feature on Lightning Bitcoin Wallet? No settings called watchtower or so.
On LBW, it's called Olympus Server. They charge a small fee to watch your channels. It was discussed here in a medium post.
This is great @renepickhardt ! It looks like you've listed the main ones there already.
You can add my vote to getting AMP live. I really enjoy playing with the emulator on https://www.robtex.com/lnemulator.html. It really shows what may be possible.
My biggest request:
- Multi-channel on-chain transactions (batching). I would like to be able to open more than one channel with an on-chain transaction. Each channel now is funded with a transaction with N inputs, a change output, and a channel output script. With the work going on in things such as bip 174 I think we can do much better. I would like to be able to open a large batch of channels and have the counterparties exchange partially signed transactions and when fully signed, transmit the channel opens to the blockchain. The risk is when a connecting node is non-responsive, then we need to re-start the signing process, but I think this can be solved through a protocol. It's pretty cool to open channels at 1 sat per byte, but it would be even cooler to open 10 channels at 1 sat per byte.
I can also think of a few things which could be nice to have.
- Add a protocol for channel state query. This should be optional to enable (by channel?) but would allow query of a node for channel information beyond the total capacity, such as the current balance on each node. I think this is important for future channel state balance dynamics and would prevent inadvertent channel balancing causing other nodes to become unbalanced.
- Add a channel reserve. There could be a setting to allow excess capacity on some node channels to be used to rebalance nodes on the network. However, a channel may want to keep some capacity for own use only. For example, if I have a channel with 1 BTC capacity, I can release 0.5 BTC for forwarding, but reserve 0.5 BTC for the case when my node is either the origin or destination.
Those are off the top of my head. If I come up with more ideas, I'll add another post.
the multi channel on-chain transactions are something that I have also in mind and has already been discussed on the last lightningHackday in Berlin. I think that is a really good request! It is somewhat similar to what bitrefill is already doing: https://medium.com/@bitrefill/would-you-like-a-lightning-channel-with-that-48be63a4eef3 and it makes sense to take this into consideration when talking about splicing.
as for the channel state query. I would very much like that as it would help towards creating a distributed autopilote developing routing protocols like the BGP which we know from IP. However I sense there will be a strong opposing force since this can be used to compromise privacy of actors on the lightning network. also there is no way of knowing if the querried information is correct.
the channel reserve I feel should not become part of BOLT1.1 but rather be an implementation detail of the offered API (unless of corse channel state queries become reality)
Hi @renepickhardt, I agree that the channel state query is a bit controversial and you are correct that there may be privacy implications. However, I would push back on that.
Yes, if each and every time a channel state was updated - that would compromise privacy. However, if infrequently queried, I think this would not reveal very much useful information. 100 transactions could have taken place over the channel between queries - so tracking transactions would still not be feasible. I would also be ok with adding some "randomness" to the response so that it is not clear if any transaction happened - i.e. it gives only representative information and not exact.
Of those, it is not possible to derive if those transactions were forwards or direct payments.
My biggest concern with such a protocol addition is to prevent exploitation for DDOS. Maybe there should be some rate limiting or other constraints.
Anyway, if we did have such a thing, it would be easier to create algorithms for more efficient channel auto-balancing without adversely affecting the network as a whole. It may even be possible to identify "win-win" transactions for channel balancing. It can even help AMP.
In any case, it could be a good discussion.
whereabouts in Australia? im located in Melbourne, be nice if we can catch up
Zapread is updated. I wonder what's going to be revealed.