FaucetBOX.com Discussion - page 150.

ranlo

legendary

Activity: 1988

Merit: 1007

Quote from: Kazuldur on July 09, 2015, 01:17:13 AM

Quote from: ranlo on July 09, 2015, 01:03:00 AM

It does lead to the question, though... why are later transactions still coming through? The one from the 7th should have more "weight" as it's older, and should go through before the new ones from FaucetBox, being that they both paid the same (relative amount of) fees.

Take this transaction as an example:
https://btc.blockr.io/tx/info/03d6e645fba49e07f3a4d8f173dce3ae590a5e0b06f28b367e29d7e64926019d
has 0.00339447 BTC fee for 15164 bytes, and it's almost 6% of what was actually transfered to users (0.05664565 BTC).
So the fee is ~0.0002260 BTC/kB

Another one is:
https://blockchain.info/tx/1d8e35cbcad0c7814fde8c0e775259107e5adc32900263d9cc1358626a0ecb0b
0.0052392 BTC fee for 17561 bytes, so it's ~0.00030819 BTC/kB

Now example that didn't get through:
https://www.biteasy.com/blockchain/transactions/e9ee41881cb7d38308ac80bb204b55da3877d7b64084872b7d78a4fc9aa9747e
0.00194831 BTC fee for 17426 bytes, so it's ~0.00011460 BTC/kB.

What matters is the fee/kB and you can see that we increased fees ~2-3x.

Quote from: ranlo on July 09, 2015, 01:03:00 AM

This is definitely an interesting situation. I'm guessing if worst comes to worst, you can just re-broadcast it or revert things back (add the funds back to each address to be sent out again once everyone's new transaction is ready) though.

We continuously rebroadcast it. We would rather avoid reverting it though, as it could get messy. What's more plausible is that we'll just send double-spends with increased fees. Does anyone know a tool that'll make that easier? I don't want to mess around with raw transactions by hand

Increased fees definitely make a difference -- I wasn't aware that you changed them,

.

So essentially, right now the weight is still growing, and "should" be a priority soon. Hopefully.

Kazuldur

legendary

Activity: 971

Merit: 1000

Quote from: ranlo on July 09, 2015, 01:03:00 AM

It does lead to the question, though... why are later transactions still coming through? The one from the 7th should have more "weight" as it's older, and should go through before the new ones from FaucetBox, being that they both paid the same (relative amount of) fees.

Take this transaction as an example:
https://btc.blockr.io/tx/info/03d6e645fba49e07f3a4d8f173dce3ae590a5e0b06f28b367e29d7e64926019d
has 0.00339447 BTC fee for 15164 bytes, and it's almost 6% of what was actually transfered to users (0.05664565 BTC).
So the fee is ~0.0002260 BTC/kB

Another one is:
https://blockchain.info/tx/1d8e35cbcad0c7814fde8c0e775259107e5adc32900263d9cc1358626a0ecb0b
0.0052392 BTC fee for 17561 bytes, so it's ~0.00030819 BTC/kB

Now example that didn't get through:
https://www.biteasy.com/blockchain/transactions/e9ee41881cb7d38308ac80bb204b55da3877d7b64084872b7d78a4fc9aa9747e
0.00194831 BTC fee for 17426 bytes, so it's ~0.00011460 BTC/kB.

What matters is the fee/kB and you can see that we increased fees ~2-3x.

Quote from: ranlo on July 09, 2015, 01:03:00 AM

This is definitely an interesting situation. I'm guessing if worst comes to worst, you can just re-broadcast it or revert things back (add the funds back to each address to be sent out again once everyone's new transaction is ready) though.

We continuously rebroadcast it. We would rather avoid reverting it though, as it could get messy. What's more plausible is that we'll just send double-spends with increased fees. Does anyone know a tool that'll make that easier? I don't want to mess around with raw transactions by hand

ranlo

legendary

Activity: 1988

Merit: 1007

Quote from: Kazuldur on July 09, 2015, 12:59:20 AM

Quote from: ranlo on July 09, 2015, 12:38:23 AM

Quote from: Kazuldur on July 08, 2015, 11:19:13 PM

Quote from: horace0812 on July 08, 2015, 09:44:17 PM

I don't know why I did not received my payout for 7/7, even the payout for 8/7 is already received few hours ago.
Any 1 have the same issue above too Huh

It was already mentioned in this thread. It's because of the spam attack on Bitcoin network: https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/ . It should get confirmed as soon as the number of unconfirmed transactions drops to something sane: https://blockchain.info/unconfirmed-transactions .

It looks like it was actually blocked. Here's an example of my personal transaction coming from FaucetBox:

https://blockchain.info/tx/e9ee41881cb7d38308ac80bb204b55da3877d7b64084872b7d78a4fc9aa9747e/359

I'm wondering if this isn't a bigger issue than just it being lagged... according to BlockChain, it's blocked because it has too many outputs and the server rejects it.

I believe that's not related, it was happening since the beginning of FaucetBOX.com (only that earlier Blockchain.info simply showed 'Transaction not found' message) and it looks like it's Blockchain.info's not-standard behavior. Other nodes relay our transactions just fine, while Blockchain.info only acknowledges our transactions after they're included in block.

Ahhh, interesting! I did notice that the transaction was already pending to the wallet it's going to, and other explorers (like blockr.io) show it fine, just figured maybe Blockchain's error was a bit more verbose than most of these others.

It does lead to the question, though... why are later transactions still coming through? The one from the 7th should have more "weight" as it's older, and should go through before the new ones from FaucetBox, being that they both paid the same (relative amount of) fees.

This is definitely an interesting situation. I'm guessing if worst comes to worst, you can just re-broadcast it or revert things back (add the funds back to each address to be sent out again once everyone's new transaction is ready) though.

Kazuldur

legendary

Activity: 971

Merit: 1000

Quote from: ranlo on July 09, 2015, 12:38:23 AM

Quote from: Kazuldur on July 08, 2015, 11:19:13 PM

Quote from: horace0812 on July 08, 2015, 09:44:17 PM

I don't know why I did not received my payout for 7/7, even the payout for 8/7 is already received few hours ago.
Any 1 have the same issue above too Huh

It was already mentioned in this thread. It's because of the spam attack on Bitcoin network: https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/ . It should get confirmed as soon as the number of unconfirmed transactions drops to something sane: https://blockchain.info/unconfirmed-transactions .

It looks like it was actually blocked. Here's an example of my personal transaction coming from FaucetBox:

https://blockchain.info/tx/e9ee41881cb7d38308ac80bb204b55da3877d7b64084872b7d78a4fc9aa9747e/359

I'm wondering if this isn't a bigger issue than just it being lagged... according to BlockChain, it's blocked because it has too many outputs and the server rejects it.

I believe that's not related, it was happening since the beginning of FaucetBOX.com (only that earlier Blockchain.info simply showed 'Transaction not found' message) and it looks like it's Blockchain.info's not-standard behavior. Other nodes relay our transactions just fine, while Blockchain.info only acknowledges our transactions after they're included in block.

ranlo

legendary

Activity: 1988

Merit: 1007

Quote from: Kazuldur on July 08, 2015, 11:19:13 PM

Quote from: horace0812 on July 08, 2015, 09:44:17 PM

I don't know why I did not received my payout for 7/7, even the payout for 8/7 is already received few hours ago.
Any 1 have the same issue above too Huh

It was already mentioned in this thread. It's because of the spam attack on Bitcoin network: https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/ . It should get confirmed as soon as the number of unconfirmed transactions drops to something sane: https://blockchain.info/unconfirmed-transactions .

It looks like it was actually blocked. Here's an example of my personal transaction coming from FaucetBox:

https://blockchain.info/tx/e9ee41881cb7d38308ac80bb204b55da3877d7b64084872b7d78a4fc9aa9747e/359

I'm wondering if this isn't a bigger issue than just it being lagged... according to BlockChain, it's blocked because it has too many outputs and the server rejects it.

Kazuldur

legendary

Activity: 971

Merit: 1000

Quote from: horace0812 on July 08, 2015, 09:44:17 PM

I don't know why I did not received my payout for 7/7, even the payout for 8/7 is already received few hours ago.
Any 1 have the same issue above too Huh

It was already mentioned in this thread. It's because of the spam attack on Bitcoin network: https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/ . It should get confirmed as soon as the number of unconfirmed transactions drops to something sane: https://blockchain.info/unconfirmed-transactions .

horace0812

member

Activity: 70

Merit: 10

★YoBit.Net★ 200+ Coins Exchange & Dice

I don't know why I did not received my payout for 7/7, even the payout for 8/7 is already received few hours ago.
Any 1 have the same issue above too Huh

asmoday

member

Activity: 129

Merit: 10

International Digital Asset Platform

Why I can't login in my admin panel on FaucetBox? (manage faucets)
When login, I can see a white page.. Huh

yvesp110

hero member

Activity: 1092

Merit: 501

Quote from: Kazuldur on July 04, 2015, 01:44:50 PM

Do all these faucets use script customized by RaphaelM again?

EDIT: looks like they do. Well...:

https://bitcointalksearch.org/topic/m.11504183
https://twitter.com/MakingMoneybtc/status/605329412251369472

LOL funny if it is Raphael script there is a bug but one of faucetbox script don't have a bug yeah right. Kazaldure is too funny anyway glad I am done with him and passed on my faucet using his script to my techs who sees it is not worth it running them

dart vader

full member

Activity: 182

Merit: 100

Quote from: BitHell.io on July 08, 2015, 05:24:14 PM

Login does not work on FaucetBox at the moment. After inserting the credentials , I get redirected to a blank screen.

Hope it gets fixed soon.

same here

MakingMoneyHoney

hero member

Activity: 504

Merit: 500

Quote from: BitHell.io on July 08, 2015, 05:24:14 PM

Login does not work on FaucetBox at the moment. After inserting the credentials , I get redirected to a blank screen.

Hope it gets fixed soon.

I just went to the old thread, to post that. I forgot there was a new thread. Hope this gets fixed soon. But I'm glad it wasn't just me, lol.

BitHell.io

full member

Activity: 186

Merit: 100

Login does not work on FaucetBox at the moment. After inserting the credentials , I get redirected to a blank screen.

Hope it gets fixed soon.

ptrio

newbie

Activity: 14

Merit: 0

Quote from: Kazuldur on July 08, 2015, 03:26:33 PM

Quote from: ptrio on July 08, 2015, 03:22:13 PM

Quote from: Kazuldur on July 08, 2015, 01:31:23 PM

Quote from: ptrio on July 08, 2015, 11:57:14 AM

I myself wouldn't trust referer headers as they could be fabricated.

While I didn't trust them too for FaucetBOX.com, how could they be fabricated in context of CSRF? If I were to attack you using CSRF I wouldn't be able to force your browser to fake the referrer.

You are right. Referer check seems to be good enough to protect against CSRF. However there's ways to get in control of someone's browser and then spoof the headers(is XSS + CSRF possible?). Also what about HTTPS or if someone's browser doesn't send the referer headers (guess 99% do but still)? That would be considered as an attack.

BTW Do you guys support p2sh for litecoin yet?

If you control someone's browser, why bother with CSRF? You can just attack directly

. HTTPS isn't a problem, referrer will be correct on the site itself and possibly not set/empty when coming from other sites (then one just assumes it's invalid). If someone's browser doesn't send headers, too bad. It's not perfect solution, it's just easiest. You should generate a token, save it in session, add it as hidden input in form and compare it on request. But that require more changes, while referrer check will be sufficient for most.

Still no P2SH for Litecoin yet. No ETA either.

Touche

I tried to come up with something but shot myself in the leg instead.

Kazuldur

legendary

Activity: 971

Merit: 1000

Quote from: ptrio on July 08, 2015, 03:22:13 PM

Quote from: Kazuldur on July 08, 2015, 01:31:23 PM

Quote from: ptrio on July 08, 2015, 11:57:14 AM

I myself wouldn't trust referer headers as they could be fabricated.

While I didn't trust them too for FaucetBOX.com, how could they be fabricated in context of CSRF? If I were to attack you using CSRF I wouldn't be able to force your browser to fake the referrer.

You are right. Referer check seems to be good enough to protect against CSRF. However there's ways to get in control of someone's browser and then spoof the headers(is XSS + CSRF possible?). Also what about HTTPS or if someone's browser doesn't send the referer headers (guess 99% do but still)? That would be considered as an attack.

BTW Do you guys support p2sh for litecoin yet?

If you control someone's browser, why bother with CSRF? You can just attack directly

. HTTPS isn't a problem, referrer will be correct on the site itself and possibly not set/empty when coming from other sites (then one just assumes it's invalid). If someone's browser doesn't send headers, too bad. It's not perfect solution, it's just easiest. You should generate a token, save it in session, add it as hidden input in form and compare it on request. But that require more changes, while referrer check will be sufficient for most.

Still no P2SH for Litecoin yet. No ETA either.

ptrio

newbie

Activity: 14

Merit: 0

Quote from: Kazuldur on July 08, 2015, 01:31:23 PM

Quote from: ptrio on July 08, 2015, 11:57:14 AM

I myself wouldn't trust referer headers as they could be fabricated.

While I didn't trust them too for FaucetBOX.com, how could they be fabricated in context of CSRF? If I were to attack you using CSRF I wouldn't be able to force your browser to fake the referrer.

You are right. Referer check seems to be good enough to protect against CSRF. However there's ways to get in control of someone's browser and then spoof the headers(is XSS + CSRF possible?). Also what about HTTPS or if someone's browser doesn't send the referer headers (guess 99% do but still)? That would be considered as an attack.

BTW Do you guys support p2sh for litecoin yet?

Kazuldur

legendary

Activity: 971

Merit: 1000

Quote from: ragi on July 08, 2015, 11:50:42 AM

Quote from: Kazuldur on July 08, 2015, 11:02:36 AM

We are experiencing issues with transaction confirmations due to the recent change in Bitcoin network fees. We're working on it, but transactions can take a long time to confirm for now.

This sucks. I want this test/attack to be over with.

It's more because of the new floating fees than the stress test, which I think is long gone now.

EDIT: I know see that it's happening again: https://www.reddit.com/r/Bitcoin/comments/3ck5z9/80000_unconfirmed_transactions_right_now/ . Also here: https://bitcoinfees.github.io/#3h . Does anyone knows anything more about it?

Quote from: ptrio on July 08, 2015, 11:57:14 AM

I myself wouldn't trust referer headers as they could be fabricated.

While I didn't trust them too for FaucetBOX.com, how could they be fabricated in context of CSRF? If I were to attack you using CSRF I wouldn't be able to force your browser to fake the referrer.

ptrio

newbie

Activity: 14

Merit: 0

Quote from: ranlo on June 28, 2015, 02:21:25 AM

Quote from: Kazuldur on June 21, 2015, 04:31:09 PM

Quote from: minifrij on June 21, 2015, 04:15:59 PM

Either way, it seems pretty easy to implement. Just checking against the referrer and returning to the homepage if it was found to be elsewhere should be sufficient.
Something like this maybe:

Code:

if($_SERVER['HTTP_REFERER'] != 'http://yoursitewhatever.com'){
header('Location: /');
}

Once the form has submitted (~line 1138 on index.php).

I'm not that good with PHP, but I think that

Code:

header('Location: /');

won't end the script. So it will send the coins either way and only redirect to main page after that.

Code:

header('Location: /'); die();

should work though.

As soon as that header hits, the page forwards, so there's no need for closing out the PHP connection -- it's done by default. Even if you have other code after that, it will stop parsing at that line.

I myself wouldn't trust referer headers as they could be fabricated.

Quote from: minifrij on July 08, 2015, 06:15:53 AM

Quote from: ranlo on July 08, 2015, 03:02:39 AM

Even with your code changes (such as escaping strings), there are many vulnerabilities still open. I'm actually somewhat surprised something as important as dealing with people's finances (in the sense that the script has access to the wallet's funds) is even using SQLi, much less in a very unsecure method. real_escape_string only prevents a small portion of injections from being possible, and if you really want to use that route, you should fix all of them.

As I said, the best way to do it without completely changing the DB software would be to use prepared statements, though that would still leave the script open to some forms of injection. What would you suggest to fix it?

I think PDO would do just fine. That plus validating the input (which in this case is only a wallet address) with base58 encoding/decoding (if anyones interested I can provide a simple script).

Anyway, you're doing a great job guys! Keep it up.

ragi

hero member

Activity: 686

Merit: 500

Quote from: Kazuldur on July 08, 2015, 11:02:36 AM

We are experiencing issues with transaction confirmations due to the recent change in Bitcoin network fees. We're working on it, but transactions can take a long time to confirm for now.

This sucks. I want this test/attack to be over with.

Kazuldur

legendary

Activity: 971

Merit: 1000

We are experiencing issues with transaction confirmations due to the recent change in Bitcoin network fees. We're working on it, but transactions can take a long time to confirm for now.

minifrij

legendary

Activity: 2352

Merit: 1268

In Memory of Zepher

Quote from: ranlo on July 08, 2015, 03:02:39 AM

Even with your code changes (such as escaping strings), there are many vulnerabilities still open. I'm actually somewhat surprised something as important as dealing with people's finances (in the sense that the script has access to the wallet's funds) is even using SQLi, much less in a very unsecure method. real_escape_string only prevents a small portion of injections from being possible, and if you really want to use that route, you should fix all of them.

As I said, the best way to do it without completely changing the DB software would be to use prepared statements, though that would still leave the script open to some forms of injection. What would you suggest to fix it?

Topic: FaucetBOX.com Discussion - page 150. (Read 237020 times)