[feature]: give payment hash in subscribehtlcevents

[felix-urban]

trafficstars

It is unclear why we can't get the hash when subscribing to Htlc events. The only way to get it is on settle events we need to manually hash the preimage. It would be beneficial to be able to have this for all htlcs

[ziggie1984]

I will take this one

[pmuls99]

Hi @ziggie1984 , I was searching for good first issues to get familiar with this codebase since I want to start contributing to lnd, and I stumbled upon this issue, I see a PR open but not merged? How can i contribute to this issue?

[guggero]

@pmuls99 the biggest bottleneck in open source usually isn't code contribution but code review. So reviewing the open PR, testing it out, suggest improvements to the documentation around the PR and so on would be greatly appreciated. That of course goes for any PR. Good reviewers are almost more rare than Bitcoin itself :)

[ziggie1984]

@pmuls99 thanks for reaching out, so I underline guggero's statement here that review's are very precious. This PR is ready for review (needs a rebase and a sync to current master) so you could help give me a hand in reviewing/testing the changes. Let me know if you plan to do so, so that I can rebase it.

[guggero]

Oops, I just noticed I tagged the wrong person :sweat_smile: Fixed...

[pmuls99]

@guggero , @ziggie1984 oh thats great , I would like to help. But I was thinking I am fairly new to this community and software development in general, so if I get familiar with the code base and the practises being used in this community I can actually help with reviews? Do you have any beginner friendly issues in mind as per my background , I have previous experience with Golang as a LFX intern under Jaeger, an open source organization and other internships in startups , but I am not much familiar with the bitcoin ecosystem other than the basics. I am currently reading the contributor guidelines and the prerequisites as mentioned in the README.

[guggero]

I couldn't name any specific guides from the top of my head. And it really depends on how much time you're willing to invest. If you want to deep dive into a new project, this is what I would recommend in general:

• Pick any small to medium sized pull request
• Find out why the pull request was created. What problem does it address? Usually there is an issue linked that explains it, or the body of the pull request explains it. If you can't figure out why the pull request is needed in the first place, that might already be a feedback you could give as a reviewer.
• Once you understand the goal of the PR, go through the code and try to answer the following questions for yourself:
  • How does each changed line contribute to the goal?
  • Do I understand what each change does?
  • Do I understand what the different files/modules/components changed in the PR do and how they interact?
• To answer all the questions above, you might already need to dive deep into the project code and read a lot of it. This part might take a lot of time and effort to work through but will get easier the more familiar you are with the project.
• Once you understand the code side, you might want to look into testing the code on your local machine. There are many approaches to this, but what I usually do is one or more of the following steps:
  • Fist, make sure you can step-by-step debug Golang code in your IDE. Depending on which IDE you use, find a tutorial for that using Google. I for example use GoLand by JetBrains which is great (and not super expensive IMO).
  • See if there are unit tests covering the changed areas. Try to run these unit tests locally and step through the code to see how it behaves at run time. Do you understand how the changes in the PR have an impact on the unit tests? Were the tests updated accordingly in the PR? If not, that might be a good feedback.
  • See if there are interation tests (see the itest/ directory) that cover the changes in the PR? If yes, try to run and understand them. Same question as above, do the integration tests sufficiently cover the changes in the PR?
  • Finally, you might want to manually test things in a local regtest setup where you create a small Lightning Network with a couple of nodes on your local machine. A great starting point for that is here: https://github.com/lightningnetwork/lnd/tree/master/docker
• Now that you are fairly familiar with all the code in the PR, do you see anything that needs to be updated in the documentation?

I think that should get you started. Since you very likely will have questions, a good place to hang out and ask those questions probably is our community Slack server: https://lightning.engineering/slack.html

EDIT: Oh, and one very important resource I forgot to mention is our documentation: https://docs.lightning.engineering/

[CryptoSnowPrince]

I will try to fix the issue on my weekend.

[ziggie1984]

I will try to fix the issue on my weekend.

I am not sure what you are referring to but the issue is already solved in: https://github.com/lightningnetwork/lnd/pull/7309 and would need some review.