no need to move away aslong u need 0.7, still this dosnt matter anymore. |
|
|
|
I can't downgrade the bitcoind that p2pool.info gets information from quickly. I may be able to do it in a day or two. Until then, FYI, that p2pool.info may be confused or just plain wrong about blocks and orphans (and luck and round duration).
in 1-2 days the invalid 0.8 chain is gone, u dont have to do anything in this case since ur bitcoind isnt mining. just wait in this case. |
|
|
|
They don't waste resource, a share is only rejected if it both arrives too late and doesn't solve a block so there's no,zero,0 income wasted by these rejects. I repeat: rejects don't reduce the pool's income.
most ppls are being scared of because they think their rejects are wasted work, donst matter how often u say it, dosnt help  we would need somewhat like a FAQ explaining it maybe. |
|
|
|
yes but if the PPLNS N is changed that it is around 7 days (according to the diff rules of p2pool), then its not day nor time based.
You mean set n to ~ 9 x Difficulty? (that's seven days shares at the moment) something like this yes, but we would have to test it first since it means holding a bigger sharechain -> more memory/traffic being used |
|
|
|
|
yes but if the PPLNS N is changed that it is around 7 days (according to the diff rules of p2pool), then its not day nor time based.
|
|
|
|
the PPLNS system should be changed to the last 7 days.
Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money. I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners. This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function. then rephrase it, set the PPLNS number so its rougly 7 days  I know what you mean, and it would help in the short term. But id n was set to (for example) 2 x current Difficulty, then you'd never have to change it. The PPLNS shouldn't be any number of days. What would happen if the pool's percentage of the hashrate increased significantly? You'd want to change the number of days back down in order to reduce the time it took to recieve payment. increasing it to a longer N would also help little miners, if they get a share and there is no block found they get nothing and are pissed, i saw that already some times. |
|
|
|
the PPLNS system should be changed to the last 7 days.
Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money. I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners. This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function. then rephrase it, set the PPLNS number so its rougly 7 days |
|
|
|
the PPLNS system should be changed to the last 7 days.
Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money. I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners. seems fine |
|
|
|
|
the PPLNS system should be changed to the last 7 days.
|
|
|
|
lets hope its down for a longer period  |
|
|
|
the examples, so beautiful since how long are you enjoying ur talent? |
|
|
|
Is this the right place to post suggested future features? Could Armory someday be made to access the bitcoin-d node running on a different machine? As it turns out, my 24/7 bitcoin-d node runs on a computer with insufficient ram to run Armory (along with everything else). So I would like to run Armory on a different machine on the LAN. FYI, Andreas Schildbach's latest Android wallet does this.
this already works (i do it myself), atleast the network thingy. i mount the .armory directory with NFS onto the local machine and forward the local bitcoind ports to the others machine with socat (nc works too). |
|
|
|
As mentioned in the other thread, it is called BBQ coin because it utilizes an innovative hybrid proof of steak and proof of wok system. dam I didn't know that now you are getting me hungry need to take bbq more seriously now  go mine some  |
|
|
|
you could set it to since SD losses are 1 satoshi. I heard the developers mumbling that after some mining pools began dropping tx with 1-satoshi outputs, SatoshiDICE responded by including a random amount of satoshis (from 2 to 9) instead of a 1-satoshi input. Regardless, from an economic standpoint there is no difference between a 1 or 10 satoshi output. in this case just set it to 10. if SD is going to include bigger outputs il happily greate a patch which remembers the biggest dust output and sets this+1 automaically (without restart) to this check. |
|
|
|
I think calling the amounts "unspendable" is not technically correct - provided an unspent output is old enough even one that contains a single Satoshi can be spent (at least that is the case currently AFAIA).
I don't see why these are unspendable? Couldn't you just have more incoming bitcoins land on that address, and then spend them as a group? u could, but the TX is getting big and you would have to pay a higher fee for it, altough u still can do it for free. scroll up or click here: https://bitcointalk.org/index.php?topic=150493.msg1601755#msg1601755If you can send transactions for free, is there any reason you would not be able to send a big transactions with a reduced fee? Just wondering: Is the size of the bitcoin transactionss cumulative, or does it reset after each transaction? What I mean is if I take a bunch of small amounts and send them to one address, that would be a big transaction, but if I then send the coins from the one address to somewhere else, does that also make a big transaction or does it become a small transaction because it is from only one address now? i once did send a TX which was around 53KB if remember this correct with 0 satoshis as feed, i could have set the fee to 0.0005 and it would still work. altough u would need to use the rawtx API, otherwise u cant do that. |
|
|
|
But the loss transactions will be blocked from relaying by the following rule, which in this case drops every transaction that is equal or less than 10,000 satoshis. I edited this part to only drop tx's with 5 or less satoshis. Still need to install all the deps to compile it now and see how well it works. if (txout.nValue <= 10000)
+ return error("CTransaction::IsStandard : ignoring transaction with dust output"); you could set it to since SD losses are 1 satoshi. |
|
|
|
I think calling the amounts "unspendable" is not technically correct - provided an unspent output is old enough even one that contains a single Satoshi can be spent (at least that is the case currently AFAIA).
I don't see why these are unspendable? Couldn't you just have more incoming bitcoins land on that address, and then spend them as a group? u could, but the TX is getting big and you would have to pay a higher fee for it, altough u still can do it for free. scroll up or click here: https://bitcointalk.org/index.php?topic=150493.msg1601755#msg1601755 |
|
|
|
As per my request, Gmaxwell wrote a patch to apply to the Bitcoin client that will drop all transactions to SatoshiDice and simply not relay or verify them. It will also drop all transactions that are less than 10,000 satoshis in value, so you might want to change that value to 1 or 2 satoshis, to only drop SD's losing bets tx's. Let's show them how the free market works and that not only miners have a say on this subject! diff --git a/src/main.cpp b/src/main.cpp
index 9a06dbf..d3fba73 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -384,8 +384,16 @@ bool CTransaction::IsStandard() const
BOOST_FOREACH(const CTxOut& txout, vout) {
if (!::IsStandard(txout.scriptPubKey))
return false;
+ if (txout.scriptPubKey.size() > 6
+ && txout.scriptPubKey[0] == OP_DUP
+ && txout.scriptPubKey[3] == 0x06
+ && txout.scriptPubKey[4] == 0xf1
+ && txout.scriptPubKey[5] == 0xb6)
+ return error("CTransaction::IsStandard : ignoring transaction with 1dice output");
if (txout.nValue == 0)
- return false;
+ return error("CTransaction::IsStandard : ignoring transaction with 0 value output");
+ if (txout.nValue <= 10000)
+ return error("CTransaction::IsStandard : ignoring transaction with dust output");
}
return true;
}
You may not be interested in the if (txout.nValue <= 10000) test, though it also gets the dice you-lost transactions and other UXTO set bloating flood. This will make the node not relay or mine these transactions. It will, of course, still accept them in blocks. you should get the patch of Luke-Jr, this only ignores tx's TO SD, payments back arent being ignored and as we know there will always be 2 tx's for each gamble try. reference: https://bitcointalk.org/index.php?topic=149668.msg1595281#msg1595281EDIT: u still process winnings because gmaxwell's patch only blocks losses. |
|
|
|
"SatoshiDICE" notifies gambling addicts of losing bets by sending them a transaction containing 1 satoshi back to their original address. A regular transaction fee is also included in this transaction. The problem is that this produces an unspendable and unprunable output. u can spend them, wait some time (so they arent "new coins" anymore, dunno how many blocks that would be) and send them even with 0 fees trough the raw tx API. |
|
|
|
Note this isn't really a problem if miners are responsible and filter out the SatoshiDice flooding.My git repository contains a "block_dice" branch to do just that. I didn't read the code, but I hope it prevents blockchain spam in general and not just satoshiDice (1dice... addresses). Does it? only SD, or fake SD adresses |
|
|
|
|
Show Posts
