Thanks!
Yes,
alias and color would be trivial to add because they are in the GetNodeInfo RPC method response. I didn't add them because I thought they had no value and could be easily changed, do you think they should be added?Regarding
min_node_age, that kind of information is not provided by the LND RPC but can be obtained by checking that the node's oldest channel is at least 103,680 blocks old (not complex neither).There is a worth mentioning workaround that requires no changes and uses the
node.channels.block_height field. For example:policies: - request: channel_capacity: min: 3_000_000 node: hybrid: true channels: block_height: operation: range min: 103_680 # 720 days * 144 blocks per day
However, that would be true only if the oldest and newest channels were created 103,680 blocks from each other.
100 sats \ 0 replies \ @aftermath OP 16 Nov 2023 \ parent \ on: BTRY - Lottery powered by Bitcoin bitcoin
Thank you for your questions, perhaps I wasn't clear enough in the second part of the post but I will try to explain all your doubts.
it seems like the winner is chosen by the server completely at random. How is that verifiable?
When I mentioned provably fair random numbers I was referring to the Battles implementation, which is a completely different service.
As you said, the winning numbers are generated using an RNG (
/dev/random in linux).However, I did create an issue https://github.com/aftermath2/btry/issues/20 which changes the way in which lotteries duration are measured.
Switching to block-based lotteries would allow the numbers to be generated using the last block hash as an entropy source and that way the users would be able to verify that the numbers are fair.
Even though the source code is honest, the actual deployed server might be colluding to award prizes to specific player(s).
You are right, users have to trust BTRY that the deployed source-code is the one in the repository, unfortunately, I'm not sure it's possible to guarantee that the binary is not tampered.
I did include the current commit at the bottom of the page to make it harder for the server to cheat.
the server could abstain from distributing prizes at all, keeping all the money paid into a lottery for itself. How can players tell if a prize was paid correctly, or paid at all?
Prizes withdrawals are not listed because I wanted to avoid showcasing any information that could be considered sensitive.
However, you could listen to the SSE stream at
{url}/api/events?stream=events to the messages of type "payments" and receive updates every time a user makes a withdraw. All you will be able to see is the payment_id and status though.It would make more sense to me if the winner was selected by hashing some undisputable but unpredictable future data, like the hash of a yet-to-be-mined block
I'm not sure I understood this completely. If the data is unpredictable how can users verify it? A hash of a yet-to-be-mined block can be whatever the server wants to, so we wouldn't solve the problem.
As I mentioned before, we could use the latest block hash as a source of entropy because picking the numbers the server wants in that short period of time would be nearly impossible.
With BitVM, you might even be able to set up a contract to punish the server if someone can prove the wrong winner was chosen. With a well-designed n-of-n multisig contract, the server could commit money to revealing a winner before a given date (or else be punished by players).
That's a great idea! I haven't digged into BitVM much yet, but I would love to learn more about it and to implement something like that.
Happy to chat anytime if you find these ideas interesting. My github is here if you wanna tag me in any issues.
I'll tag you in the ones I mentioned above. I'm really interested in having technical conversations and discussing about any Bitcoin topic or even contributing to any projects you may have. I'm open to chatting if you want to!
101 sats \ 0 replies \ @aftermath OP 15 Nov 2023 \ parent \ on: BTRY - Lottery powered by Bitcoin bitcoin
Thanks! I pronounce it "bee-try" because it sounds better to me, but initially the name was "Bittery" so I guess both ways are valid.
500 sats \ 1 reply \ @aftermath OP 15 Nov 2023 \ parent \ on: BTRY - Lottery powered by Bitcoin bitcoin
I opted to use Telegram because there are many Bitcoin communities there, it can be proxied over tor and was super simple to integrate.
But I agree with you and will take into consideration the options you suggested. I have created the following issue to fix this https://github.com/aftermath2/btry/issues/23.
Thank you for the feedback!
10 sats \ 0 replies \ @aftermath OP 15 Nov 2023 \ parent \ on: BTRY - Lottery powered by Bitcoin bitcoin
Absolutely, my intention is to help the network and this community to grow. Thank you for you words!
CC @Paulysats and @lightning_roulette who were interested in this project
21 sats \ 1 reply \ @aftermath OP 15 Nov 2023 \ parent \ on: BTRY - Lottery powered by Bitcoin bitcoin
I 100% agree with you, I never gamble myself and will never do. But some people find it entertaining and there were no similar solutions so I though it would be a good project to get started.
Check out #163372, it has a list with services offering swaps and their fees.
I'm going to publish a post here, perhaps a note in nostr and a telegram message in some Bitcoin group, not much more really. I expect it to grow organically if there's enough demand.
I'm working on something like this, it is not decentralized and it is custodial (sadly I couldn't figure out a way to avoid this) but it offers many features that the fiat system lacks:
- Open source, fully auditable
- Private (tor hidden service). It does not require an account, just an ed25519 key pair. The private key never leaves the client.
- Globally available and permissionless
- Uses lightning payments to bet/withdraw (with plans to support on chain)
- Users participate for the 99.609375% of the prize pool
I'm actually pretty close to getting everything ready. I'll be posting all the details about it in the next few weeks, hopefully.
I also want to mention that the next iteration of the project includes developing non-custodial real time events betting by using HODL contracts, which would allow users to bet against each other (1v1) with the service never taking custody of the funds.
I've seen a lot of demand for a service like this, I hope I can deliver.
That's right, I was referring to the swapping implementation itself (if the service has access to the funds at any point in time) but we could definitely consider all closed source services as trusted, regardless of what the code is actually doing.
My situation is pretty much like yours. I do not particularly dislike my current job but I would much rather prefer to work on Bitcoin full time. However, I'm not actively looking for a job in the industry yet.
Instead, I've recently decided to dedicate some of my spare time to contribute to open source projects (there are a lot of great ones out there) and to work on some personal ones (that I will hopefully be able to release soon), all related to Bitcoin and Lightning. So far it has been a lot of fun and I've learnt a lot as well.
I do recommend to start experimenting and playing with a full Bitcoin+Lightning node if you haven't yet, as it helps you understand how everything works in practice and to discover potential use cases or points to improve that no ones has found or cared to exploit/fix yet. If you can't land a job that focuses on Bitcoin, why don't you try creating it? :)
I'm also alone in this journey and doing anonymous contributions with one-time-use accounts didn't help much in that regard, so I decided I would make them all under the same nickname, which may help developing a "relationship" with other people in the space (the downside is you have to be really careful not to leak any personally identifiable information).
Also, joining development or node runners communities/chats has helped me relate to other bitcoiners and discuss many topics with them.
Unfortunately I cannot modify the post anymore. Also, differentiating between trusted and trustless solutions would require to verify the source code of all of them (some are closed source so it's not possible), and that takes way more time than I currently have.
Congrats @ekzyis!!
Judging by your fingers, you are a young man. Judging by the soda, you live near Munich, Germany. Judging by the soda's reflection, you have a nice room :). Haha I probably went too far
Thanks for the feedback! I'm sorry for the typo and for not making the point clear with the fees (rn I'm not sure where I got that Breez charged 0.1 more, perhaps I counted the miner fee as well by mistake).
Regarding trusted and trustless swaps differentiation, you are right. I limited the post to cover the functionality of non-custodial swaps as those are the ones tools like Loop and Boltz use (robosats isn't even a swap service but a P2P exchange that uses HODL invoices for example).
I didn't have enough time to review all the implementations and some of them are closed source, but I included them in the list anyway so everyone has got a picture of how much the market is charging.
sudo nano /etc/systemd/system/acceptlnd.servicesudo systemctl enable acceptlndandsudo systemctl start acceptlnd.