BE200 Jet Stratum Miner V 5.47 programa controller does not see such lines as settings (stratum.mining.eligius.st:3334)
[Guide] Dogie's Comprehensive ASICMiner Tube Setup [HD]
Too bad...
Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 106. (Read 1061485 times)
Too bad...
the site is down!?!?!?
mining is still working, maybe just the website.
the site is down!?!?!?
LE: it's back!
LE: it's back!
When we were talking about the special transaction handling policies related to Eligius you were saying:
And I raised the concern:
You sort of assured to me it is public knowledge:
The policy discussion held last week indicates there was need for further discussion and clarification regarding this topic, but now I found out a similar patch was applied to the gentoo package of bitcoind/-qt:
https://bugs.gentoo.org/show_bug.cgi?id=524512
That's disappointing.
Quote
Nor should you try to force core devs or pool operators (I think you really mean miners) to do your bidding against their will.
And I raised the concern:
Quote
Without transparency (e.g. published blacklists), I don't see how this is a choice made by miners.
You sort of assured to me it is public knowledge:
Quote
Eligius uses my public spam filter branch, and miners are capable of seeing what they are mining at any given moment in full detail using GBT
The policy discussion held last week indicates there was need for further discussion and clarification regarding this topic, but now I found out a similar patch was applied to the gentoo package of bitcoind/-qt:
https://bugs.gentoo.org/show_bug.cgi?id=524512
That's disappointing.
BE200 Jet Stratum Miner V 5.47 programa controller does not see such lines as settings (stratum.mining.eligius.st:3334)
[Guide] Dogie's Comprehensive ASICMiner Tube Setup [HD]
BE200 Jet Stratum Miner V 5.47 programa controller does not see such lines as settings (stratum.mining.eligius.st:3334)
i use stratum+tcp://stratum.mining.eligius.st:3334
captain obvious 
(stratum.mining.eligius.st:3334) )))))try does not work
(stratum.mining.eligius.st:3334) )))))try does not work 
Have you tried stratum+tcp://stratum.mining.eligius.st:3334 +btc address
hi give advice))) can not run miner(ASICMINER Tube 800gh) used to run the line settings not run (stratum.mining.eligius.st:3334 (or http://gbt.mining.eligius.st:9337 mining.eligius.st:3334 ) 
please tell me the correct line settings 
please tell me the correct line settings 
Yeah, I have no idea what any of that means, but congratulations to whichever one of you got married or landed on the moon or whatever happened.
I landed on the Mun in Kerbal Space Program... does that count?
Did you see ArtForz? He's a Master Engineer in Kerbal Interstellar.
- Standard transactions:
- OP_RETURN: allow up to 80 bytes
pardon my ignorance & my french
Does that mean that Eligius will allow counterparty-XCP transactions (if encoded in OP_RETURN) or do you still plan to filter them out (I think you are treating them like spam because they're still multisig transactions) ? [/list]
OP RETURN would be appropriate. Abusing multisig is not.
So for those who aren't entirely sure what they're talking about (myself) what would constitute a violation of multisig? And how would this affect using a p2sh wallet? Or does this have nothing to do with p2sh wallets?
The conclusive results do nothing to hinder P2SH multisig use.
- Standard transactions:
- OP_RETURN: allow up to 80 bytes
pardon my ignorance & my french
Does that mean that Eligius will allow counterparty-XCP transactions (if encoded in OP_RETURN) or do you still plan to filter them out (I think you are treating them like spam because they're still multisig transactions) ? [/list]
OP RETURN would be appropriate. Abusing multisig is not.
So for those who aren't entirely sure what they're talking about (myself) what would constitute a violation of multisig? And how would this affect using a p2sh wallet? Or does this have nothing to do with p2sh wallets?
They're abusing multisig for arbitrary data storage instead of actual multisig transactions.
- Standard transactions:
- OP_RETURN: allow up to 80 bytes
pardon my ignorance & my french
Does that mean that Eligius will allow counterparty-XCP transactions (if encoded in OP_RETURN) or do you still plan to filter them out (I think you are treating them like spam because they're still multisig transactions) ? [/list]
OP RETURN would be appropriate. Abusing multisig is not.
So for those who aren't entirely sure what they're talking about (myself) what would constitute a violation of multisig? And how would this affect using a p2sh wallet? Or does this have nothing to do with p2sh wallets?
- Standard transactions:
- OP_RETURN: allow up to 80 bytes
pardon my ignorance & my french
Does that mean that Eligius will allow counterparty-XCP transactions (if encoded in OP_RETURN) or do you still plan to filter them out (I think you are treating them like spam because they're still multisig transactions) ? [/list]
OP RETURN would be appropriate. Abusing multisig is not.
- Standard transactions:
- OP_RETURN: allow up to 80 bytes
pardon my ignorance & my french
Does that mean that Eligius will allow counterparty-XCP transactions (if encoded in OP_RETURN) or do you still plan to filter them out (I think you are treating them like spam because they're still multisig transactions) ?
is it a good assumption the payout queue is down
Doing some maintenance
That last payout, seems to be taking a long time to verify, its only been seen by 1 peer after 4 hours.
Makes no sense since every Eligius payout is in a block. So, wherever you got that information from is providing useless info...
Could only part of the block take longer to confirm than other parts?
Nope.
Generation transactions always take >=100 blocks to confirm, while others are subjective to wallet/human decision on when they confirm.
Everything in the block receives the same numbet of confirmations though, which is what I was getting at.
I blame the core devs then for having a "confirmations" field in listtransactions RPC.
is it a good assumption the payout queue is down
Doing some maintenance
That last payout, seems to be taking a long time to verify, its only been seen by 1 peer after 4 hours.
Makes no sense since every Eligius payout is in a block. So, wherever you got that information from is providing useless info...
Could only part of the block take longer to confirm than other parts?
Nope.
Generation transactions always take >=100 blocks to confirm, while others are subjective to wallet/human decision on when they confirm.
Everything in the block receives the same numbet of confirmations though, which is what I was getting at.
I blame the core devs then for having a "confirmations" field in listtransactions RPC.
is it a good assumption the payout queue is down
Doing some maintenance
That last payout, seems to be taking a long time to verify, its only been seen by 1 peer after 4 hours.
Makes no sense since every Eligius payout is in a block. So, wherever you got that information from is providing useless info...
Could only part of the block take longer to confirm than other parts?
Nope.
Generation transactions always take >=100 blocks to confirm, while others are subjective to wallet/human decision on when they confirm.
Everything in the block receives the same numbet of confirmations though, which is what I was getting at.
is it a good assumption the payout queue is down
Doing some maintenance
That last payout, seems to be taking a long time to verify, its only been seen by 1 peer after 4 hours.
Makes no sense since every Eligius payout is in a block. So, wherever you got that information from is providing useless info...
Could only part of the block take longer to confirm than other parts?
Nope.
Generation transactions always take >=100 blocks to confirm, while others are subjective to wallet/human decision on when they confirm.
Everything in the block receives the same numbet of confirmations though, which is what I was getting at.
Jump to: