I decided it was about time I retire to an island somewhere in the Bahamas... or a CPPSRB failsafe, which is much more likely. lol
Reward system is catching up, no worries. Manual payout soon after.
Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 102. (Read 1061417 times)
thanks for the info 
Is there an issue with the Payout Queue? When I go to check it, it is empty.
Pool is in Fail-Safe mode following orphan block 327,848
All mined BTCs go to cold storage
4 blocks and no pay 
Is there an issue with the Payout Queue? When I go to check it, it is empty.
I'm looking for some help with my namecoin merge mining. I've done everything I've read about signing the message and all that, and it's saved in my Configurable Options in My Eligius but I have never received any namecoin transactions. I last entered the info on 9/20 (ie signed and saved it) so that's over a month ago and I've been mining between 200 and 400 gh/s (which I know isn't much) consistently at least since then.
Any reason I wouldn't be getting transactions?
Thanks
Any reason I wouldn't be getting transactions?
Thanks
Namecoin is broken. Read back through the thread, it was discussed not that long ago, a few pages back.
I'm looking for some help with my namecoin merge mining. I've done everything I've read about signing the message and all that, and it's saved in my Configurable Options in My Eligius but I have never received any namecoin transactions. I last entered the info on 9/20 (ie signed and saved it) so that's over a month ago and I've been mining between 200 and 400 gh/s (which I know isn't much) consistently at least since then.
Any reason I wouldn't be getting transactions?
Thanks
Any reason I wouldn't be getting transactions?
Thanks
Hello Luke-Jr and wizkid057,
I heard that Eligius did implemented the child pays for parent feature but I recently made this https://blockchain.info/tx/ad870af22eb05a85c4660db9ba29c7fedef37933611e5a171265f1955e68ee47 there have been mined a few blocks by Eligius but none of them included that transaction.My questions are did Eligius really implemented Child pay for parent? If yes than why that transaction didn't appeared in blocks? And if Eligius did implemented it than how does the transaction should look like I mean how much btc should it pay as a fee?If next time I would push this kind of transaction directly here http://eligius.st/~wizkid057/newstats/pushtxn.php would it fix the problem?
EDIT: I just tried to spend this transaction https://blockchain.info/tx/3f5497c1ab9973b8b51f13d9c1b4c8d989101c5f5298f337c18008f70b71fc87 with this one, this is it's raw As you can see it is non-standard as it has a 0btc output and spend unconfirmed coins from transaction 3f5497c1ab9973b8b51f13d9c1b4c8d989101c5f5298f337c18008f70b71fc87 this transaction is only 225bytes and the previous transaction is 3682bytes in total that is just 3907bytes so a simple 0.0004fee would be enough but that transaction uses a 0.0029fee but still I got this when I tried to push it directly to Eligius Why does Eligius rejects that transaction is that because it spends an unconfirmed transaction which is a low priority tx and Eligius doesn't keep them at their memory pool or is there any other reason?
I heard that Eligius did implemented the child pays for parent feature but I recently made this https://blockchain.info/tx/ad870af22eb05a85c4660db9ba29c7fedef37933611e5a171265f1955e68ee47 there have been mined a few blocks by Eligius but none of them included that transaction.My questions are did Eligius really implemented Child pay for parent? If yes than why that transaction didn't appeared in blocks? And if Eligius did implemented it than how does the transaction should look like I mean how much btc should it pay as a fee?If next time I would push this kind of transaction directly here http://eligius.st/~wizkid057/newstats/pushtxn.php would it fix the problem?
EDIT: I just tried to spend this transaction https://blockchain.info/tx/3f5497c1ab9973b8b51f13d9c1b4c8d989101c5f5298f337c18008f70b71fc87 with this one, this is it's raw
Code:
010000000187fc710bf70880c137f398525f1c1089d9c8b4c1d9131fb5b87399abc197543f010000006a4730440220698c2fb147cf7dbec10b8d41d4c913a97b54291f8cf85025a208cb5729cc96ac0220172973332ddbcf5bae07d61038fad059d81a5e7c340a3a5f92385e0f5c7f7357012103d6d14809877d01d0d6696e6f03eaf076302c3efb3b2196511b4f29e3e3f6c169ffffffff0210270000000000001976a914551f77fa76877ae763c9d12342d96043cc10a77688ac00000000000000001976a91468c746e27282b076aafe4131a8df6f0a857d7e6388ac00000000
Code:
{
"lock_time":0,
"size":225,
"inputs":[
{
"prev_out":{
"index":1,
"hash":"3f5497c1ab9973b8b51f13d9c1b4c8d989101c5f5298f337c18008f70b71fc87"
},
"script":"4730440220698c2fb147cf7dbec10b8d41d4c913a97b54291f8cf85025a208cb5729cc96ac0220172973332ddbcf5bae07d61038fad059d81a5e7c340a3a5f92385e0f5c7f7357012103d6d14809877d01d0d6696e6f03eaf076302c3efb3b2196511b4f29e3e3f6c169"
}
],
"version":1,
"vin_sz":1,
"hash":"e9d38afa428bc3f9ca672248c9cc07a76c678d824ece07ddd29ca680be2ea463",
"vout_sz":2,
"out":[
{
"script_string":"OP_DUP OP_HASH160 551f77fa76877ae763c9d12342d96043cc10a776 OP_EQUALVERIFY OP_CHECKSIG",
"address":"18m68ndnYc3cDFHaEjFv6P6Nfz61vqS89G",
"value":10000,
"script":"76a914551f77fa76877ae763c9d12342d96043cc10a77688ac"
},
{
"script_string":"OP_DUP OP_HASH160 68c746e27282b076aafe4131a8df6f0a857d7e63 OP_EQUALVERIFY OP_CHECKSIG",
"address":"1AZ1zxCE6e4GT74Fu8EPM5sRxgN9Y7Luyv",
"value":0,
"script":"76a91468c746e27282b076aafe4131a8df6f0a857d7e6388ac"
}
]
}Code:
Trying to send...
array(3) {
["result"]=>
NULL
["error"]=>
array(2) {
["code"]=>
int(-22)
["message"]=>
string(11) "TX rejected"
}
["id"]=>
string(1) "1"
}
Response = 0
Is there a problem with the webpage? My hashrates haven't updated(not to zero either) nor has my unpaid balance in the last 2 rounds. The payout queue seems to be empty.
is there maintenance going on the stats page
I have not been paid for the last 3 blocks
I've never reached the maximum reward before, but yesterday was SO close! 
pool luck average 1400.+% 
I guess pool is blessed with its Saint...
I guess pool is blessed with its Saint...
11blocks today? YAHOOOOOOOOOOOOOOOOOOOOOO 
If you're looking at the entire blockchain history, I suspect you need to figure out what other addresses they've used in the past.
Also, IMO you should make sure you're only counting each "false positive" address once.
Also, IMO you should make sure you're only counting each "false positive" address once.
My initial intend wasn't actually to show how good or bad the prefix approach works, but simply to get an overview of all transactions and this was rather a by-product.
But now that we are at it: I run a specific analysis which solely targeted the SatoshiDice prefix range and stored all unique addresses that were found on mainnet: http://pastebin.com/DadRD9CL
According to satoshidice.com there are 15 addresses in use: http://pastebin.com/Pr5juKC0
I have absolutely no idea, if the other hits are or were used by SD, but in total 173 unique addresses were found and if those 15 addresses are the only ones used by SD, then the other 158 hits are false positives.
Edit: the number of half a million was related to the number of transactions that were sent or received by those 158 "others".
Edit: it looks like those 15 addresses were not the only ones ever used and there are some hits with significant volume, e.g. 1dice2xkjAAiphomEJA5NoowpuJ18HT1s.
Half a million transactions by a mere 158 addresses might not be SatoshiDice, but it would likely count as 'spam' by any definition.
If you're looking at the entire blockchain history, I suspect you need to figure out what other addresses they've used in the past.
Also, IMO you should make sure you're only counting each "false positive" address once.
Also, IMO you should make sure you're only counting each "false positive" address once.
My initial intend wasn't actually to show how good or bad the prefix approach works, but simply to get an overview of all transactions and this was rather a by-product.
But now that we are at it: I run a specific analysis which solely targeted the SatoshiDice prefix range and stored all unique addresses that were found on mainnet: http://pastebin.com/DadRD9CL
According to satoshidice.com there are 15 addresses in use: http://pastebin.com/Pr5juKC0
I have absolutely no idea, if the other hits are or were used by SD, but in total 173 unique addresses were found and if those 15 addresses are the only ones used by SD, then the other 158 hits are false positives.
Edit: the number of half a million was related to the number of transactions that were sent or received by those 158 "others".
Edit: it looks like those 15 addresses were not the only ones ever used and there are some hits with significant volume, e.g. 1dice2xkjAAiphomEJA5NoowpuJ18HT1s.
He means the "total number of transactions up until 327'115". I think these results are very unlikely - he implies that of the ~50 million transactions recorded, 1% of them are prefix collisions between Satoshidice addresses and non-SatoshiDice addresses.
dexX7 can you share your results and method?
dexX7 can you share your results and method?
The results:
https://docs.google.com/spreadsheets/d/1R_Tk8P6rs8pYUPOQ_0qxDeZNmu0IiITH_uA-1xp4IJM/pubhtml
The method:
https://github.com/dexX7/bitcoin/commit/51f9f62f4ccff78a6fa81a8bd9e441785bef888c
If the first four bytes of a P2PKH payload fall into the range of 0x06f1b600 - 0x06f1b6ff, then it's a hit for SatoshiDice. I cheated when checking, if a transaction is a transaction that spends from a targeted entry and instead of fetching the actual transaction inputs, I just take the second scriptSig piece, compare it's length and first byte to determine, if it may qualify as public key and if it does, then I treat it as payload and follow up with a similar prefix comparison.
The prefix comparison and prefixes were adopted from Luke-Jr's blacklisting solution.
Please let me know, if this - or anything else - is flawed.
Also, IMO you should make sure you're only counting each "false positive" address once.
He means the "total number of transactions up until 327'115". I think these results are very unlikely - he implies that of the ~50 million transactions recorded, 1% of them are prefix collisions between Satoshidice addresses and non-SatoshiDice addresses.
dexX7 can you share your results and method?
dexX7 can you share your results and method?
The results:
https://docs.google.com/spreadsheets/d/1R_Tk8P6rs8pYUPOQ_0qxDeZNmu0IiITH_uA-1xp4IJM/pubhtml
The method:
https://github.com/dexX7/bitcoin/commit/51f9f62f4ccff78a6fa81a8bd9e441785bef888c
If the first four bytes of a P2PKH payload fall into the range of 0x06f1b600 - 0x06f1b6ff, then it's a hit for SatoshiDice. I cheated when checking, if a transaction is a transaction that spends from a targeted entry and instead of fetching the actual transaction inputs, I just take the second scriptSig piece, compare it's length and first byte to determine, if it may qualify as public key and if it does, then I treat it as payload and follow up with a similar prefix comparison.
The prefix comparison and prefixes were adopted from Luke-Jr's blacklisting solution.
Please let me know, if this - or anything else - is flawed.
Hey Luke-Jr,
FYI: I was curious how many non-financial transactions there are and used your prefix list to identify gamble transactions. Then I compared the total number of transactions for SatoshiDice with the sum of the total number of transactions of the 15 addresses listed on satoshidice.com based on the data provided by blockchain.info.
Turns out the prefix based filter identified 11'677'989 transactions at height 327'115 while the actual number based on full hashes was 11'124'066 at height 327'120 +-2.
Under the assumption those 15 addresses are the only relevant ones, then that's about half a million false positives.
I don't understand how you came to that conclusion, or why you think that assumption is even probable...FYI: I was curious how many non-financial transactions there are and used your prefix list to identify gamble transactions. Then I compared the total number of transactions for SatoshiDice with the sum of the total number of transactions of the 15 addresses listed on satoshidice.com based on the data provided by blockchain.info.
Turns out the prefix based filter identified 11'677'989 transactions at height 327'115 while the actual number based on full hashes was 11'124'066 at height 327'120 +-2.
Under the assumption those 15 addresses are the only relevant ones, then that's about half a million false positives.
And how do you get 11 million transactions in a block, when blocks can only have at most 4.5 million at most*?
* Unless they have non-standard transactions, which can't possibly be dice spam.
He means the "total number of transactions up until 327'115". I think these results are very unlikely - he implies that of the ~50 million transactions recorded, 1% of them are prefix collisions between Satoshidice addresses and non-SatoshiDice addresses.
dexX7 can you share your results and method?
Hey Luke-Jr,
FYI: I was curious how many non-financial transactions there are and used your prefix list to identify gamble transactions. Then I compared the total number of transactions for SatoshiDice with the sum of the total number of transactions of the 15 addresses listed on satoshidice.com based on the data provided by blockchain.info.
Turns out the prefix based filter identified 11'677'989 transactions at height 327'115 while the actual number based on full hashes was 11'124'066 at height 327'120 +-2.
Under the assumption those 15 addresses are the only relevant ones, then that's about half a million false positives.
I don't understand how you came to that conclusion, or why you think that assumption is even probable...FYI: I was curious how many non-financial transactions there are and used your prefix list to identify gamble transactions. Then I compared the total number of transactions for SatoshiDice with the sum of the total number of transactions of the 15 addresses listed on satoshidice.com based on the data provided by blockchain.info.
Turns out the prefix based filter identified 11'677'989 transactions at height 327'115 while the actual number based on full hashes was 11'124'066 at height 327'120 +-2.
Under the assumption those 15 addresses are the only relevant ones, then that's about half a million false positives.
And how do you get 11 million transactions in a block, when blocks can only have at most 4.5 million at most*?
* Unless they have non-standard transactions, which can't possibly be dice spam.
@dexX7, your block designators are perfectly understandable as a height, not a containment. Thanks for the info.
4.5% of all hanged men innocent. Sounds like the US justice system.
Jump to: