Before posting the question I decided to take a look in the blockchain.info... and even deepbit and Slush are attributing the generation coins to a single address, possibly to transfer them after the 120 blocks maturation period. Why? This is risky... Just send them immediately to the miners.
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. |
|
|
|
I was really looking forward to the import feature in bitcoind (don't care about sweep). Too bad the developers decided to be nanny for us.
Huh? GIT HEAD bitcoind supports import private key functionality: importprivkey <bitcoinprivkey> {label}I just took a look, and it turns out there are 6 new RPC commands in the GIT HEAD: addmultisigaddress <nrequired> <'["key","key"]'> [account]
dumpprivkey <bitcoinaddress>
getblock <hash>
getblockhash <index>
getmininginfo
importprivkey <bitcoinprivkey> [label] Just FYI. |
|
|
|
Why the House Always Wins"Researchers analyzed 27 million online poker hands and found an interesting result: the more hands a player wins, the less money they're likely to collect. That seems like a pretty obvious result. Poker players tend to lose, and tend to lose more the more hands they play. You don't get to win a lot of hands without playing a lot of hands, and losing a lot of hands. |
|
|
|
Is this what your 10% sacrifice is meant for?
No. I have 10,000 stolen BTC. I divide it up into 1,000 lumps of 10 BTC. I send 100 of those lumps to 100 different donation addresses I collect from the forum, and the other 900 to 900 different new addresses I create for myself. When I later spend one of those 10 BTC lumps and someone questions me about it, I say "I don't know who sent it to me - it just turned up one day", and checking the blockchain they can see that the same amount "just turned up" in lots of other well known addresses at the same time, lending evidence to my story that the thief just randomly distributed his ill-gotten gains to strangers. |
|
|
|
That said, I'll for sure switch to P2Pool as soon as I have a better understanding.
It's actually quite simple. [...] miners who have submitted shares for this block are paid in the generation transaction of this block, proportionally to how many shares they have found since the last Bitcoin block was found. Not quite. It's like this: Each share contains a generation transaction that pays to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve, which is proportional to the p2pool difficulty at that time.
|
|
|
|
Now, we have OP_HASH160 OP_HASH160 OP_XOR. This takes a hash of both Sig and Pubkey, and XORs them into a single number [...]
I don't think that's how OP_HASH160 works. If you have 2 things on the stack and then OP_HASH160 twice, you'll hash the 2nd thing twice, not both things once each. |
|
|
|
I agree with your assessment. You might win the award for the first serious argument against BIP 22 (at least from the set of those that I understand the ramifications of).
It was bugging me that Gavin had so quickly dismissed the idea without giving enough of an explanation for me to immediately understand what his objection to it was, and so I set about trying to find it. I don't know if the attack I proposed is the same as Gavin had in mind, or he just knows "forks are bad" and left it at that. A mitigating factor is that this could be protected against by creating an optional patch to the new client that ensures that, upon receiving a block, the individual transactions are relayed to old clients (as determined by version number).
I'm not sure that's enough. Because now I modify my attack like this: 1) mine block on new fork spending old coin without broadcasting transaction 2) mine block on old fork spending same old coin 3) publish both blocks at the same time That's going to be harder than the original attack, but should be possible for any reasonable sized mining pool to achieve given a day's notice. |
|
|
|
But since "sends" on both forks look identical, and old clients are still talking to new clients, the two forks essentially cross-contaminate each other (beneficially) with each other's unconfirmed transactions, which results in every unconfirmed transaction that would be considered valid by both clients making it into both forks independently.
What if I don't publish the transaction in which I spend an old coin, but wait until I can mine a block containing the transaction for myself. I'm an evil mining pool operator in this example, say, so that won't take too long. I make sure there are some multi-sig transactions in the block too. I publish the block, spending the coin on the new chain, but the old chain rejects the block, since it contains multi-sig transactions. Then I can spend the same coin again on the old chain. Your beneficial cross-contamination idea only works if everyone's playing fair... I think this is a realistic enough attack that it makes BIP 22 unworkable. |
|
|
|
No, bad idea, two chains cannot peacefully coexist for more than a few dozen blocks, they would eventually make a complete mess out of users' wallets.
It took me a while to understand why this would be the case, but perhaps it's the following: The 'old' chain will grow independently of the 'new' chain, generating 50 BTC per block which will spread to users of the old chain, and which they will believe is 'real' BTC. Then when they upgrade to a BIP 22 client, they find that the coins generated on the old fork are no longer valid. ie. the transactions look valid on both forks in terms of their format, but not in terms of their coinbases. Then again doesn't it take something like 100 blocks before newly minted coins are spendable? In which case I'm back to not understanding how BIP 22's chain split would "make a complete mess out of users' wallets" within "a few dozen blocks". |
|
|
|
dooglus: yep you are right. Meant the opposite. Will fix when not logged in via mobile phone
I edited it for you. Replaced 'fail' with 'succeed'. |
|
|
|
Just to toss something on to the fire, BIP 22 ( https://en.bitcoin.it/wiki/BIP_0022) is something I proposed as a potential answer to all of the prior BIPs on the multisig subject. It is one that I proposed way back when. "Hey, you're right, I agree". I like BIP 22 the best so far. I don't have a deep enough knowledge of the protocol to see what if anything is wrong with it but it feels a lot cleaner than either 16 or 17. I was confused by this part: A suggested implementation is to program the client such that the functionality is enabled only on Testnet, and on the main Bitcoin network once a certain level of voting consensus has been established into the block chain. So long as the functionality is disabled, OP_CHECKSIG shall fail so long as the expected parameters of one single signature and one single private key are provided.
Don't you want OP_CHECKSIG to succeed not fail when one single signature and one single private key are provided, even when the new functionality is disabled? |
|
|
|
I remember reading an old thread about when the idea of pooled mining came up, but I can't find it now. Could anyone please link it to me if you have it?
This? https://bitcointalk.org/index.php?topic=861It's from August 18, 2010, and is the first mention of pooled mining I can find. Or did you mean the idea of p2p pooled mining? |
|
|
|
Funds will be converted to a fiat currency(EUR,USD,GBP) so you won't be actually playing with BTC.
Why can't we play with BTC? I would think that's because the iPoker network doesn't support playing with BTC. Lots of different companies use the iPoker network and provide their own 'skin' to make it look like their own site. The players often don't realise they're playing on iPoker, because everything is branded to look like the site they registered with. The different companies are responsible for handling deposits and withdrawals, which iPoker provides the games. If you want to play for BTC, http://sealswithclubs.org/ offers that. They have hourly freerolls (with a 0.05 BTC prize to the winner). The rake on ring games is cheap too, at only 2.5%. The biggest problem is that there are very few players. Currently (11:20pm PST) it's saying: "Join 23 Bitcoin Poker Players Online at 3 Live Tables"... |
|
|
|
If the amount would be less than 0.0011 bitcoins, then I rounded the amount awarded up to 0.0011. Just because eleven is my favorite number (well, and because I like the idea of rewarding p2pool users, I think p2pool is neat).
That exactly explains what happened. Thanks Holliday! I did try googling for the transaction ID before posting, but nothing showed up. |
|
|
|
Miners (as a group) should not be given any say over issues like this.
Ultimately, miners are the ONLY people who have any say over issues like this. They're the only one who decide which transactions get into blocks. |
|
|
|
decompiled winmain
That's pretty impressive. What tool did you use to do that? |
|
|
|
Andreesen said that one mining pool had veto power over system changes. I don't think that, in itself, is a big deal. I know how to encrypt my wallet.
On the other hand, I have no real understanding of what he's talking about.
1. Where are the "rules" about these large mining pools? I didn't see it in Satoshi's white paper.
(please answer!)
The rules are everything about how bitcoin works, such as: Difficulty is calculated to set the block generation rate to about one every ten minutes. There are 50 bitcoins generated in each block. The reward halves every 4 years. And so on. 2. Why does this matter? Does the person who is awarded a block get to "control" it forever?
Gavin is wanting to change one of the rules, to allow multi-sig transactions. If there is a mining pool with >50% of the hashing power, they could refuse to accept the new rule, and reject any transaction that doesn't follow the old rules. The problem here is that the pool decides the content of the block being mined. They decide which transactions to include and which to reject. The miners have effectively given up any power they had on deciding the 'rules' to the pool operator. The advantage of p2pool over the traditional pools is that each miner uses their own bitcoind to decide which transactions to include in the blocks they mine. There's no central pool operator deciding whether to go with Gavin's rule or Luke's rule. Each miner in the pool downloads either Gavin's bitcoind or Luke's bitcoind, hence getting their own 'vote'. 3. Instead of some commie a$$ appeal (sorry, I'm and 80s kid) to donate to smaller mining pools (which some of you were making), why can't I loan them to these "more virtuous" mining groups and get kicked back some of the discovered blocks, thus receiving a return on my investment - rather than "DONATING?"
If so, could you please such an enterprise!
The idea of the donations in to incentivise miners to use p2pool instead on one of the traditional pools (as if saving the (up to) 10% fees that the traditional pools charge isn't enough). Having you loan some BTC only to have to pay you back more than you loan would be a disincentive. What's in it for me as a miner? I end up losing BTC to you. 4. Sorry if I sound like an arrogant buffoon that has a Bobby Knight poster on my wall, but I doubt I'm the only one who has the same misconception. I'm buying BTC to try to make $$$ and am "tech-challenged."
It's OK. I love David Hasselhoff's early work too. |
|
|
|
|
Show Posts
