 Show Posts
|
|
Pages: [1] 2 »
|
Introducing an opportunistic cache of the last 100.000 transactions gave such a boost to the server that I thought it is worth writing about.
Apparently outputs die generally rather young and saving the db roundtrip for them is the single biggest boost I found until now...
Yep, pynode figured many of these things out, long ago. A block (including TXs) cache is very useful. For long running nodes, the signature cache is also very helpful. Over time, transactions are accepted into the memory pool and signature cache. When a new block arrives, the majority of transactions found in that block will have had their signatures pre-checked and cached, making acceptance of that block go more rapidly. are you honestly adding more info.. or just trying to point out that your "pynode" is *so* ahead ?? |
|
|
|
is there any particular reason why you use edu.emory.mathcs.backport.java.util.Arrays ? the one from java.util works just fine imo.
That must have been a false auto import by eclipse. Thanks for pointing out, I delete it. it seems there are still imports using edu.emory.mathcs.backport.java.util.Arrays like in AddressConverter.java maybe you can fix those too  |
|
|
|
great work grau! I like the way you code, and your attitude! keep it up |
|
|
|
Connectivity from the people having trouble at home should be fixed. The routing table got set to a class A address somehow. It should work now... sorry about that! I have no idea how that would have even happened.
awesome! confirmed it works now! |
|
|
|
SatoshiDICE is about to hit 1,000,000 BTC paid out. You could be the one to do it!! yey! it was me !  there's one thing though.. I know *BIG* numbers are fun... but that bet I made to make it go to 1,000,000 was 16 BTC on the less than 64000 .. and i got in return 16.07... so I didnt win 16.07 btc.. I actualy won 0.07 btc .. it should in my opinion only count the profits (of course not count the losses lol that would put a negative number haha) What if I bet 1 BTC on "lessthan 32k" and 1 BTC on "lessthan 64k" in the same transaction, and get lucky number 40000? <32k returns 2 BTC, <64k returns 0. Did I win 1 BTC and lose 1 BTC? Or did I win 0 BTC? Either way, you were clearly paid out 2 BTC. It's just that you also paid IN 2 BTC. There are several ways you can count the "pay out" amount. Using the way which gives the biggest number seems to make sense in terms of the PR it generates. well even if the bets are in the same transaction they count as different bets... they just have the same lucky number.. personally I would count only the profit of won bets.. but not substract the lost bets of course! |
|
|
|
SatoshiDICE is about to hit 1,000,000 BTC paid out. You could be the one to do it!! yey! it was me ! there's one thing though.. I know *BIG* numbers are fun... but that bet I made to make it go to 1,000,000 was 16 BTC on the less than 64000 .. and i got in return 16.07... so I didnt win 16.07 btc.. I actualy won 0.07 btc .. it should in my opinion only count the profits (of course not count the losses lol that would put a negative number haha) |
|
|
|
That's pretty strange. Can you run a traceroute on it?
here are a traceroute of eclipsemc.com and us1 linux~ # traceroute eclipsemc.com
traceroute to eclipsemc.com (96.43.135.180), 30 hops max, 60 byte packets
1 orion (192.168.5.1) 0.162 ms 0.186 ms 0.220 ms
2 * * *
3 10.170.169.161 (10.170.169.161) 12.519 ms 12.529 ms 12.529 ms
4 216.113.122.17 (216.113.122.17) 12.875 ms 12.881 ms 12.882 ms
5 216.113.123.222 (216.113.123.222) 33.327 ms 33.337 ms 33.342 ms
6 216.113.125.38 (216.113.125.38) 31.200 ms 31.104 ms 31.088 ms
7 10gigabitethernet1-1.core1.mci1.he.net (72.52.92.2) 40.967 ms 35.352 ms 40.483 ms
8 10gigabitethernet1-1.core1.mci2.he.net (184.105.213.2) 41.748 ms 41.417 ms 41.419 ms
9 joe-s-data-center-llc.10gigabitethernet1-4.core1.mci1.he.net (216.66.79.14) 39.271 ms 34.789 ms 38.432 ms
10 DC2SW1.KCMODATACENTER.COM (96.43.134.38) 39.281 ms 41.079 ms 41.950 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
linux~ # traceroute us1.eclipsemc.com
traceroute to us1.eclipsemc.com (208.110.68.114), 30 hops max, 60 byte packets
1 orion (192.168.5.1) 0.153 ms 0.179 ms 0.217 ms
2 * * *
3 10.170.169.165 (10.170.169.165) 13.785 ms 13.800 ms 13.794 ms
4 216.113.122.37 (216.113.122.37) 14.246 ms 14.256 ms 14.268 ms
5 216.113.124.118 (216.113.124.118) 37.166 ms 37.188 ms 37.184 ms
6 216.113.125.38 (216.113.125.38) 32.848 ms 32.736 ms 32.702 ms
7 10gigabitethernet1-1.core1.mci1.he.net (72.52.92.2) 42.560 ms 35.772 ms 40.002 ms
8 10gigabitethernet1-1.core1.mci2.he.net (184.105.213.2) 42.213 ms 41.771 ms 41.774 ms
9 wholesale-internet-inc.10gigabitethernet1-3.core1.mci2.he.net (216.66.78.90) 39.527 ms 36.818 ms 51.145 ms
10 69.30.209.1 (69.30.209.1) 51.153 ms 46.915 ms 46.920 ms
11 us1.eclipsemc.com (208.110.68.114) 46.874 ms 41.374 ms 36.434 ms
|
|
|
|
Everything seems to be up and running at the moment. Are you still having issues?
i've actually been having problems going to the website itself from my home connection.. but i can connect to the pools... it just seems to be the web service i cant reach.. but I can from work .. and other friend on the same provider also works.. this is the resolved ip for eclipsemc.com: 96.43.135.180 im getting connection timeouts over port 80: Connecting to 96.43.135.180:80... failed: Connection timed out. |
|
|
|
There is now a filter on address pages to show confirmed transactions only (Including filtering orphans)  like I said in an earlier post.. even if we choose different filtering options.. as soon as we change "pages" that filter gets reset to default |
|
|
|
ok so my previous example was good for wallet transactions.. so instead I made a more "general" implementation for it to be in getrawtransaction of the bitcoin client here is a patch-like mod of the code of TxToJSON in rpcrawtransaction.cpp which is used to output a verbosed version of getrawtransaction or decoderawtransaction: (added code has + in front) void TxToJSON(const CTransaction& tx, const uint256 hashBlock, Object& entry)
{
entry.push_back(Pair("txid", tx.GetHash().GetHex()));
entry.push_back(Pair("version", tx.nVersion));
entry.push_back(Pair("locktime", (boost::int64_t)tx.nLockTime));
Array vin;
BOOST_FOREACH(const CTxIn& txin, tx.vin)
{
Object in;
if (tx.IsCoinBase())
in.push_back(Pair("coinbase", HexStr(txin.scriptSig.begin(), txin.scriptSig.end())));
else
{
in.push_back(Pair("txid", txin.prevout.hash.GetHex()));
in.push_back(Pair("vout", (boost::int64_t)txin.prevout.n));
+ CTransaction txPrev;
+ uint256 hashBlock;
+ GetTransaction(txin.prevout.hash, txPrev, hashBlock); // get the vin's previous transaction
+ CTxDestination source;
+ if (ExtractDestination(txPrev.vout[txin.prevout.n].scriptPubKey, source)) // extract the destination of the previous transaction's vout[n]
+ {
+ CBitcoinAddress addressSource(source); // convert this to an address
+ in.push_back(Pair("address",addressSource.ToString())); // add the address to the returned object
+ }
Object o;
o.push_back(Pair("asm", txin.scriptSig.ToString()));
o.push_back(Pair("hex", HexStr(txin.scriptSig.begin(), txin.scriptSig.end())));
in.push_back(Pair("scriptSig", o));
}
in.push_back(Pair("sequence", (boost::int64_t)txin.nSequence));
vin.push_back(in);
}
entry.push_back(Pair("vin", vin));
Array vout;
for (unsigned int i = 0; i < tx.vout.size(); i++)
{
const CTxOut& txout = tx.vout[i];
Object out;
out.push_back(Pair("value", ValueFromAmount(txout.nValue)));
out.push_back(Pair("n", (boost::int64_t)i));
Object o;
ScriptPubKeyToJSON(txout.scriptPubKey, o);
out.push_back(Pair("scriptPubKey", o));
vout.push_back(out);
}
entry.push_back(Pair("vout", vout));
if (hashBlock != 0)
{
entry.push_back(Pair("blockhash", hashBlock.GetHex()));
map<uint256, CBlockIndex*>::iterator mi = mapBlockIndex.find(hashBlock);
if (mi != mapBlockIndex.end() && (*mi).second)
{
CBlockIndex* pindex = (*mi).second;
if (pindex->IsInMainChain())
{
entry.push_back(Pair("confirmations", 1 + nBestHeight - pindex->nHeight));
entry.push_back(Pair("time", (boost::int64_t)pindex->nTime));
entry.push_back(Pair("blocktime", (boost::int64_t)pindex->nTime));
}
else
entry.push_back(Pair("confirmations", 0));
}
}
} |
|
|
|
Just as a reminder, while this like it should work, the concept of a sending address does not exist in bitcoin. What this is doing is finding the last address to have received these funds. This is occasionally what you expect, but not always. If you are thinking that this address is owned or controlled by the person that sent you a transaction, you will be wrong fairly often.
I'm only interested in the address.. not the owner.. I know this will not always resolve to an address.. but in most case it will.. I will just catch the errors of when it is not the case and handle it gracefully |
|
|
|
Ok from the help of the people on freenode/bitcoin-dev I was able to resolve the addresses from the inputs of a transaction using the vin.prevout so just for other people to know... exmaple to find out the first input's address CWalletTx wtx;
pwalletMain->GetTransaction(uint256(txid), wtx); // get current transaction
CTxIn vin = wtx.vin[0]; //get first input
CWalletTx wtxPrev;
pwalletMain->GetTransaction(vin.prevout.hash, wtxPrev); // get the vin's previous transaction
CTxDestination source;
ExtractDestination(wtxPrev.vout[vin.prevout.n].scriptPubKey, source); // extract the destination of the previous transaction's vout[n]
CBitcoinAddress addressSource(source); // convert this to an address
print addressSource.ToString() // might as well print it!
|
|
|
|
Im trying to find the input address of a transaction but i can't seem to find out how.. anyone ?
Transactions do not have an input address. They have one or more inputs, which may or may not correspond to one or more addresses. If you have a CScript, then you can call: bool ExtractDestination(const CScript& scriptPubKey, CTxDestination& addressRet);
bool ExtractDestinations(const CScript& scriptPubKey, txnouttype& typeRet, std::vector<CTxDestination>& addressRet, int& nRequiredRet);
What are you trying to do? Im just trying to output more info on the getrawtransaction rpc command for my personal bitcoins ... lets say i have this transaction output (testnet): {
"hex" : "0100000001241514a48241f8af8abde6e6e3a657a6ff67beb2febdd5c1f4c62a71a1fb81c3000000008b483045022100a84c1b1a89938c4b16ec7749e9afc16f1a5ec26ddbb16e44739818f4bb85b74c02205d5ce610e0b9d80a373f305dbe67d7347d47470e4b3f6bd98e670ae511d98b920141043ac715efdea8815afc64d7441549e9114ba5d2658f0dcc1a75a8420e8af4791ad8ac46b2eec0463bc54946662e860717d92afe137f0a9fb1b7e1eea812487285ffffffff0200a3e111000000001976a9144988abbeb751dcd6e9f4ec40d50b84c99ed1426d88ac00c2eb0b000000001976a914539862a4bc81786df288265752e12bd7c0c0a6c488ac00000000",
"txid" : "6aeb3de625830fcc45f675042e1ed98d2c08af72119f81a6e7819d55a6f8ab83",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "c381fba1712ac6f4c1d5bdfeb2be67ffa657a6e3e6e6bd8aaff84182a4141524",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100a84c1b1a89938c4b16ec7749e9afc16f1a5ec26ddbb16e44739818f4bb85b74c02205d5ce610e0b9d80a373f305dbe67d7347d47470e4b3f6bd98e670ae511d98b9201 043ac715efdea8815afc64d7441549e9114ba5d2658f0dcc1a75a8420e8af4791ad8ac46b2eec0463bc54946662e860717d92afe137f0a9fb1b7e1eea812487285",
"hex" : "483045022100a84c1b1a89938c4b16ec7749e9afc16f1a5ec26ddbb16e44739818f4bb85b74c02205d5ce610e0b9d80a373f305dbe67d7347d47470e4b3f6bd98e670ae511d98b920141043ac715efdea8815afc64d7441549e9114ba5d2658f0dcc1a75a8420e8af4791ad8ac46b2eec0463bc54946662e860717d92afe137f0a9fb1b7e1eea812487285"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 3.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 4988abbeb751dcd6e9f4ec40d50b84c99ed1426d OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9144988abbeb751dcd6e9f4ec40d50b84c99ed1426d88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mnDmM7j73HEqo746F1cLQZXwTXNPzLxc3W"
]
}
},
{
"value" : 2.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 539862a4bc81786df288265752e12bd7c0c0a6c4 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914539862a4bc81786df288265752e12bd7c0c0a6c488ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"mo8xvtom7uyCwjh3MHzjdc8ZtWqAQp6xW7"
]
}
}
],
"blockhash" : "00000000235841896dc9856e8a3ef214df8f5e4f2127e534ff18199616f8da00",
"confirmations" : 103,
"time" : 1349331390,
"blocktime" : 1349331390
}
well i would like it to display the vin's address ... a bit like what blockchain.info displays! |
|
|
|
Im trying to find the input address of a transaction but i can't seem to find out how.. anyone ? CWalletTx wtx;
pwalletMain->GetTransaction(uint256(txid), wtx);
CTxIn vin = wtx.vin[0];
CScript scriptSig = vin.scriptSig;
how can I get the source address of that vin .. I dont seem to understand how I can get the address of the scriptsig .. |
|
|
|
I'm not the one having problems...
is that a general statement?  |
|
|
|
Update.. just got paid! |
|
|
|
no don't change the math , it's perfect, hes talking about how the "effective" payout multiplier is written on the game table ... so on your "Less than 32768, 50%" pays 2x minus house percent [ 2 * 0.9835 = 1.967 ] so in the table you should write 1.967x multiplier but for the ones that the payout minus house percent give a long decimal number , still use the correct math , but round up the displayed number on the table page. looks at this comparison table | odd/65536 | Even multiplier | Effective multiplier | Displayed multiplier | | 1 | 65536 | 64454.656 | 64454.656 | | 2 | 32768 | 32227.328 | 32227.328 | | 4 | 16384 | 16113.664 | 16113.664 | | 8 | 8192 | 8056.832 | 8056.832 | | 16 | 4096 | 4028.416 | 4028.416 | | 32 | 2048 | 2014.208 | 2014.208 | | 64 | 1024 | 1007.104 | 1007.104 | | 128 | 512 | 503.552 | 503.552 | | 256 | 256 | 251.776 | 251.776 | | 512 | 128 | 125.888 | 125.888 | | 1000 | 65.536 | 64.454656 | 64.455 | | 1500 | 43.6906666667 | 42.969770667 | 42.970 | | 2000 | 32.768 | 32.227328 | 32.227 | | 3000 | 21.8453333333 | 21.4848853333 | 21.485 | | 4000 | 16.384 | 16.113664 | 16.114 | | 6000 | 10.9226666667 | 10.7424426667 | 10.742 | | 8000 | 8.192 | 8.056832 | 8.057 | | 12000 | 5.46133333333 | 5.37122133333 | 5.371 | | 16000 | 4.096 | 4.028416 | 4.028 | | 24000 | 2.73066666667 | 2.68561066667 | 2.686 | | 32000 | 2.048 | 2.014208 | 2.014 | | 32768 | 2 | 1.967 | 1.967 | | 48000 | 1.36533333333 | 1.34280533333 | 1.343 |
So for the page aesthetics you can display a rounded effective multiplier to 3 decimals so it looks nice.. but don't change the real math behind the calculation of the payout! I hope this helps out |
|
|
|
yeah I guess that makes alot of sense! I guess im just eager to get my winnings! I don't know if I'm really lucky but all in all with SD and BTCDice I have won about 83btc |
|
|
|
Satoshidice shows multiplier less the house percent. I show multiplier prior to house percent.
Your help page at http://btcdice.com/howitworks.html says: If you win, your bet is multiplied by the prize multiplier and that amount is sent back. But that's not correct. If you win, your bet is multiplied by the prize multiplier, then the house edge is subtracted, and that amount is sent back. It would be best if you showed the actual multiplier the user gets. i.e. take the house edge off the prize multiplier before stating it. That way people can compare your odds with SD's to easily see which is better odds. For example, on "lessthan 16000", instead of saying the payout is "4.096x", calculate 4.096*(1-edge/100): >>> 4.096 * (1-1.650/100)
4.028416 and state that the payout is 4.028x. That way people can make a direct comparison with SD's quoted multiplier of 4.003x. Yeah I think your suggestion is the best thing to do.... less confusion! |
|
|
|
|
