FWIW this is all false.
Yes it's true the preimage for us only "exists" is known once the invoice is settled, because YOU have to reveal it in order to claim the payment that was made to the payment_hash (a hash of the PREIMAGE)

It's generated by your lightning software, but various implementations will allow you to set a custom preimage, and even if they didn't there'd be a way to do so.

Since a preimage is really just the equivalent of a random sha hash, you could start with a good secret and then make a hash of a hash n times, and replay that. Once the new bet is placed you can reveal the old hash to everyone in order to prove you're not alternating between hash chains.
Now that I think about it, this might be less than ideal since the kth+1 hash will be the payment_hash of the kth hash, though I don't see how this could be exploited really, just a funny gimmick.

I think you genuinely seem to misunderstand how payments are done through the lightning network, so I don't really get all the negative vibes in this thread here.

FWIW this is false.
Yes it's true the preimage for us only "exists" is known once the invoice is settled, because YOU have to reveal it in order to claim the payment that was made to the payment_hash (a hash of the PREIMAGE)

It's generated by your lightning software, but various implementations will allow you to set a custom preimage, and even if they didn't there'd be a way to do so.

I'm thinking: since a preimage is just the equivalent of a random sha hash, you could start with a good secret and then make a hash of a hash n times, and replay that. Once the new bet is placed you can reveal the old hash to everyone in order to prove you're not alternating between hash chains.
Now that I think about it, this might be less than ideal since the kth+1 hash will be the payment_hash of the kth hash, though I don't see how this could be exploited really, just a funny gimmick.

I think you genuinely seem to misunderstand how payments are done through the lightning network, so I don't really get all the negative connotation in this thread here.

FWIW this is absolutely false.

Yes it's true the preimage for us only "exists" is known once the invoice is settled, because YOU have to reveal it in order to claim the payment that was made to the payment_hash (a hash of the PREIMAGE)

Am I missing something obvious here or?


No need to worry though, since a preimage is just a random sha hash, you could start with a good secret and then make a hash of a hash n times, and replay that. Once the new bet is placed you can reveal the old hash in order to prove you're not alternating between hash chains.

If you want multiple currencies you should probably look into a payment processor such as coinpayments or btcpayserver.
If you just want BTC, use bitcoin core, assign an address to a user and enable walletnotify. On deposit you will get notified and you can process the deposit however you like.

Mysql and NodeJS should work perfectly fine?
OP you should do this yourself unless you want to shell out a couple thousand dollars. Run a full node, choose a language (JS) and enable walletnotify.
Assign address to user and let walletnotify hit a certain internal route (/make-deposit) where you credit the deposit and store the new balance in your DB.

Bad idea. the work will be half-assed and you will have no idea whether or not it functions correctly.
If I were you I would look into btcpayserver for certain deposit logic and then just keep track of balances using mysql.

This is not simple. You're asking someone to write a front-end that has sound registration logic, so a backend and mail server? and crypto payment logic. If you want this done well it's gonna cost you. Probably want to try and build your business around already existing solutions such as btcpayserver, though that's perhaps also a bit difficult if you don't want to use JS in your front-end.

Mysql and NodeJS work perfectly fine.

@OP you should do this yourself unless you want to shell out a couple thousand dollars. Run a full node, choose a language (JS) and enable walletnotify.

Assign address to user, and let walletnotify hit a certain internal route (/make-deposit) where you accredit the deposit and store the new balance in your DB.

Bad idea. the work will be half-assed and you will have no idea whether or not it functions correctly.

If I were you I would look into btcpayserver for certain deposit logic, and then just keep track of balances using mysql.

This is not simple. You're asking someone to write a front-end (Vue/Svelte/some framework?) that has sound registration logic (backend + mail server?) + crypto payment logic. If you want this done well it's gonna cost you. Again, probably want to try and build your business around already existing solutions such as btcpayserver, though that's perhaps also a tad bit difficult if you don't want to use JS in your front-end.

Pretty sure this guy was arrested earlier. I think there's actually two people of age 29 that got arrested, one of whom being the developer of TC.

Does this thread answer your questions?

Does this thread answer your questions?

Hmm. It's not foulproof but I guess you could publish all of the received individual donations in terms of invoices? If you exclude a certain invoice then that would be proveable by the individual who paid the invoice by publishing it?

Not sure what this would prove as it does not at all imply that you used the donated funds as intended, something that could much easier be tracked if you were to be using an on-chain address.
though here you could also most definitely probably publish the invoice of it going to charity xyz's node along with the preimage

https://www.smatmixer.io/

 

I mean it would be a cool feature notwithstanding that I personally have never seen a case where this could have prevented anything. Critical reading skills should prevent people from getting away with misquoting people, and lying about the contents of dms (or denying the existence thereof) would just cause a standoff where one party would look silly after theymos or any moderator? checks their PMs.

I'm guessing this might not happen in low-profile cases which I imagine would be the only reason something like this might be useful, but really in 99% of the cases it is immediately obvious who's the scammer and who's the actual affected party. (And again, if it turns out to not be that simple I imagine it would not be that hard for a mod to check the pms manually.)

I think the threat alone of an admin checking the actual contents of a pm would already make manipulation with on-site communication (pms) fairly unattractive. And really, wouldn't such a feature just cause a shift to other messaging apps like Telegram? Hard to see what exactly would be solved.

Perhaps development efforts would be better spent on finally making it look like this forum didn't come straight out of 2007, and more like their modern counterparts.

ms since epoch?

...

I have always been curious: do you have some sort of custom software with residential proxies that creates social media accounts and then have workers fill in the recaptcha and then you use those accounts to complete orders, or are you a reseller from another panel?

Or is it some sort of botnet where you use other people's social media?


Anyway the only thing that matters for these panels is price. Market is completely saturated with a lot of big players with bigger pockets than you. It seems to me that you're reselling?

There's some discussion here

If it's any help i'm pretty sure that blockchain.com uses https://github.com/dropbox/zxcvbn for their password strength guesstimation. Not sure if they also did so back in 2014 though.

I don't fully understand the issue, from the looks of your debug.log your RPC can't bind to the port specified in your bitcoin.conf, though it seems that this has not interfered with the syncing of your wallet and thus does not relate to your networking issues?



It's been a while since i prodded around and I currently don't have my node synced to try and replicate this getnetworkinfo output

The only thing I can think of is that the is not correctly cancelling out the
Or that your conf file is indeed not loaded at all.

---

Reduce the number of parameters to just and see if that resolves the issue.

Parse the json? (.json())

See https://developer.mozilla.org/en-US/docs/Web/API/Response/json

Uhh, the miner that mined your transaction?


http://de.schildbach.wallet/ ? Never heard of it and it won't load either.

you need to define rows (const rows = client.query)