[li]Tried to access boot information[/li]
[li]Tried to access file system (ie /etc/passwd)[/li]
[li]Various SQL injection techniques[/li]
[li]javascript injection[/li]
[li]Tried executing system commands with buffer over-runs [/li]
[/list]
It's kinda funny that they never tried to find my wallet.dat file :-)
He's almost certainly using a program that does all that stuff automatically for him. I've seen the same pattern of attacks myself. If you look in the logs closely, you'll see the same word coming up over and over. Google it - it's the name of the hacking tool he's using. That's what I found, anyway. I don't remember the name now though sorry. |
|
|
|
I play at http://pokerstars.com/ (US dollars, 95k players on 15k tables) and http://sealswithclubs.org/ (Bitcoin, 40 players on 6 tables). They're both great in their own way. Seals only accepts Bitcoin deposits. I don't know what deposit methods Stars supports. I built my roll from freerolls. |
|
|
|
Willful ignorance
Such a nice turn of phrase ! Permission to re-use ? That's from 2 Peter 3:5. That's a weird looking IP address. |
|
|
|
Selection runs again looking for 1.01
Good point. I missed that. |
|
|
|
If it is just random pick I'm thinking to have two wallets running. One to accept payment and leave there, another to send payments. Once in a while swap their functions.
it's not random. It's designed to maximize coin age and reduce inputs. Where did this meme originate? It's not true. The official client will use coins with more than 6 confirmations if it can, but other than that makes no effort to use old coins. It tries to find the set of coins which has the smallest value above the value you're trying to send, which usually results in a small 'change' output being left in your wallet, which can tend to increase future fees. The idea of using two wallets is a reasonable one and should work. Bear in mind that to avoid fees, each coin you spend should be at least one "bitcoin day" old. i.e. multiply the coin's value in BTC by its age in days, and it that's more than about one then you can probably spend it for free. That's just a rough rule of thumb, because the number of outputs also affects the transaction size, but only about 20% as much as the number of outputs does. (Each input adds 179-181 bytes to the transaction size, while each input only adds 34 bytes). Alternatively, if you feel comfortable building the client from source, you can modify it so that it prefers older coins. Find the bit in wallet.cpp that says: return (SelectCoinsMinConf(nTargetValue, 1, 6, setCoinsRet, nValueRet) ||
SelectCoinsMinConf(nTargetValue, 1, 1, setCoinsRet, nValueRet) ||
SelectCoinsMinConf(nTargetValue, 0, 1, setCoinsRet, nValueRet));
and add a few more lines, so it tries the oldest coins first. Something like this would work: return (SelectCoinsMinConf(nTargetValue, 1, 6*24*30, setCoinsRet, nValueRet) || // try just using 30 day old coins first
SelectCoinsMinConf(nTargetValue, 1, 6*24*7, setCoinsRet, nValueRet) || // then 7 day old
SelectCoinsMinConf(nTargetValue, 1, 6*24, setCoinsRet, nValueRet) || // then 1 day old
SelectCoinsMinConf(nTargetValue, 1, 6, setCoinsRet, nValueRet) || // then 1 hour old
SelectCoinsMinConf(nTargetValue, 1, 1, setCoinsRet, nValueRet) ||
SelectCoinsMinConf(nTargetValue, 0, 1, setCoinsRet, nValueRet));
Depending how 'micro' your coins are, and how old your wallet is, you might want to go further still, but I'm sure you get the point. |
|
|
|
The wallet always attempts to reduce the fee using older coins as necessary to minimize or eliminate any fee.
Are you sure about that? I thought it didn't. Read CWallet::SelectCoinsMinConf() in wallet.cpp. It tries to spend as little as possible, ignoring coin age. |
|
|
|
The wallet always attempts to reduce the fee using older coins as necessary to minimize or eliminate any fee.
Are you sure about that? I thought it didn't. |
|
|
|
ten blocks one every 10 seconds and one block once every 100 seconds gives you exactly the same amount of security if the overall hash rate is the same.
That might be true if the blocks were chained together, with each one depending on the previous one. But in P2Pool the share chain doesn't require this. The transactions appearing in one share may or may not appear in the following share in the sharechain and it just doesn't matter. So it's possible you see your transaction in a share in the sharechain, and then see 10 more shares follow it, each of which not containing your transaction. All that seeing your transaction in a share tells you is that a miner somewhere has accepted your transaction into his pool and is trying to mine it at the moment. It absolutely doesn't tell you that it will ever be successfully mined. |
|
|
|
That assumes the same salt and passphrase were used to produce all your paper wallets. If it were one salt per page, or one salt per address, that wouldn't be the case. If each address had its own salt, and you knew that you needed to redeem salt+passphrase, then you could do that (for example) directly on MtGox (which allows redemptions of arbitrary strings as private keys, which it converts via sha256 to a 256-bit value).
I think I was probably using the terminology wrongly, mixing "keys" with "wallets", etc. the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys
That's the part that made me think a single salt plus the passphrase would give up all the private keys in the wallet in one fell swoop. But if the salt was long enough to not be brute-forceable, and each address in the wallet had its own salt, that could work nicely. |
|
|
|
Of course, it's not as elegant as the feature you have described. The current functionality is one passphrase to one bitcoin address versus what you proposed sounds like one passphrase to many bitcoin addresses.
Nice workaround, but you're right; I was thinking of having the same passphrase for all the wallets on a single sheet of paper. I want multiple addresses, and don't want to have to remember multiple passphrases for them. Maybe it would be useful to have the option to print the same page of addresses twice - once encrypted (for my bookshelf) and once unencrypted (for the bank vault in the event that I lose the wetware copy of the passphrase). I see AES as unnecessary. If there is a demand for an "encrypted" paper wallet (that presumably requires a memorized key), then why not just print a deterministic paper wallet with no private keys (all of which can be recreated with a memorized key). To quell the concern that the memorized key might not have enough entropy, the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys.
The problem I see with that approach is that if I try to redeem one of my paper wallets on a compromised machine, I lose them all, not just one. Once you have the salt and my passphrase you have all my paper wallets. |
|
|
|
I think strongcoin.com and blockchain.info/wallet are doing something similar. Would be great to see it in bitaddress as well, since its a simple standalone tool.
Yes, but BitAddress has the unique feature of working entirely offline once you've saved a copy of the webpage. I can copy the saved page using a USB stick to an offline computer and run it there. Then my private keys are never on a machine connected to the Internet. |
|
|
|
|
I have a feature request:
I like the idea of using a paper wallet, but I don't like that to keep funds safe I have to keep the paper somewhere inaccessible, like a bank vault. That's inconvenient when I need access to the funds.
I'd like to be able to provide a passphrase to BitAddress, and have a sheet of paper wallets generated which have the private key encrypted using that passphrase.
Then I can keep a copy of the paper wallets in my house and not worry about having the funds stolen in the event of a burglary, since the passphrase (which is only in my head) would be needed to get at the real private key.
The 'Wallet Details' tab could then recognise when I typed in an encrypted private key and prompt for the passphrase before decrypting it and showing the same details that it currently shows.
What do you think?
|
|
|
|
Here's the class I use to do the same thing: https://github.com/dooglus/intersango/blob/aud/mtgox_api.phpIt's more complete, offering functions like buy_btc, sell_btc, cancel_order, etc. Use it if you like, but I can't offer any guarantees as to its correctness, but it works well enough for my purposes. |
|
|
|
Hi Thiago. Can I suggest you put "total=0.5/0.0001" instead of "total=0.5". If you put a / and then a number, that changes the smallest amount that goes to any miner. If you don't, it defaults to 0.1, and anyone whose share would be less gets nothing. When you're sending such small amounts, only the top few miners in the pool will get anything if you leave the cutoff at the default of 0.1. (And one lucky other miner will get all the other guys' bitcent fractions in a lump sum, at random, like a lottery). Check the output of the wget command on its own to see the difference it makes... |
|
|
|
Funny right? A person should not get in the gambling game unless they understand statistics.
Maybe the plan was to put up a 'play money' game with a 400% payout then adjust the odds when it went live. |
|
|
|
I just calculated the expected payoff of this game. It's 416%. No wonder we're all winning! Symbol layout: wheel 1: 1 1 3 1 5 2 1 6 2 1 4 3 0 1 2 3 4 0 7 1 2 1 3 1 1 3
wheel 2: 1 0 2 1 3 4 0 2 6 0 3 1 4 7 0 5 0 3 2 0 1 0 2 1 0 2
wheel 3: 3 0 1 3 2 5 0 2 1 6 0 3 1 0 1 0 2 4 7 3 0 0 1 3 0 1
Symbol distribution: | 1 2 3
--+----------
0 | 2 8 8
1 | 10 5 6
2 | 4 5 3
3 | 5 3 5
4 | 2 2 1
5 | 1 1 1
6 | 1 1 1
7 | 1 1 1
Payouts: 7 7 7 500
6 6 6 250
5 5 5 150
4 4 4 100
6 5 4 80
3 3 3 80
3 3 . 50
2 2 2 50
2 2 . 40
1 1 1 30
1 1 . 15
0 0 0 10
0 0 . 5
0 . . 2
Calculation: >>> (500 + 250 + 150 + 100*4 + 80 + 80*5*3*5 + 50*5*3*(26-5) + 50*4*5*3 + 40*4*5*(26-3) +
30*10*5*6 + 15*10*5*(26-6) + 10*2*8*8 + 5*2*8*(26-8) + 2*2*(26-8)*26) / 26.0 / 26 / 26
4.1603322712790165
It turns out that if the 40 payout was the only winning combination, we would still win with a 104% payout: >>> 40*4*5*(26-3) / 26.0 / 26 / 26
1.0468821119708696
|
|
|
|
you all know, that it needs a wining chance lower than 50% to finance the site
if this site would be alredy up, (playble with money) they would never be able to pay all the winnings...
myself played few times with free 5 coins, but won everytime 100+
-> system would collaps
You would think that a 98% payout should mean a 2% profit on turnover, but it seems the variance is massive. The first few times I played I lost the 5 BTC I 'deposited'. Then I got on a lucky streak: 14:38:05 Won 4000 coins. Balance 51651 coins.
14:38:02 Bet: 100. Balance 47651 coins. So I lost about 15 and won 47k - and it seems from this thread that plenty of others are also winning big. How can that be? Maybe rather than setting the payout to around 50% the answer to achieving an affordable variance is not to allow bets of 50 or 100 times the minimum. |
|
|
|
Reward in p2pool are higher than in most pool (ppl in deepbit pay 10% to mine LOL, poor noobs, wasting money), that is an incentive for ppl to switch to it.
Variance? P2pool find some blocks everyday, no problem about variance...
http://blockexplorer.com/address/1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 lists all the blocks found by p2pool. 6 blocks yesterday, 5 so far today. It's been a lucky couple of days when the expected "Average time between blocks" is 0.36 days. |
|
|
|
As a miner I would prefer that the pool sends the generated coins to itself and pays me in mature coins. That way I don't have to wait for 120 blocks before I can spend the coins.
It doesn't make sense. You'll have to wait anyway. Either you wait with the money in your wallet, or you wait with it in the wallet of the pool operator. I find the former more secure. I presume the pools have a buffer of mature coins which they use to pay their miners. I don't have to wait; I can withdraw mature coins as soon as the pool finds a block. |
|
|
|
|
Show Posts
