@spiccioli

>> pool of private keys
There are no hidden keys (i.e. a pool) in MultiBit.   The only private keys in a wallet are the ones listed (as bitcoin addresses) in the 'Request/ Receive' screen.
That being said, if you do want a whole load of private keys added it is quite easy to do.   There is a screen added for support of MultiBitMerchant (web software Gary is working on) where you can add a 1000 private keys to the active wallet in one go.
To enable the 'Merchant' option just add "showMerchantMenu=true" to the multibit.properties.

In the next couple of months there will be quite a bit of work done on wallets/ keys so if you have any ideas or specific use cases in this area I would be interested to hear about them.

I know many bitcoiners are bitcoiners in the first place because of hatred towards banks. But that was not the point at all.

It's not being like banks. It's that banks address the same concerns when they process transfers:

- they want to collect a fee
- they don't want to discourage transfers as that means no fee
- they know they can collect more when transfers are bigger, because it means more money is involved
- they try not to over-collect over a point as their cost is the same and big players can start looking for different channels

So basically trying to collect in a similar way to banks is not being like banks. It means banks have to address the same problem.

I came with the transfer fee scheme (as usually happens in Europe) and DeathAndTaxes countered with a check fee scheme. Checks are not the same as typical checks are all within a quantity big enough that's worth to go and collect, and not so big it's crazy to pick such amount of money in cash. So a fixed scheme suits that well.

Bankers also pee and sleep? do you sleep or do you try to avoid behaving like a banker?


This involves dealing with network implementation concerns. Thing is, it's not really trivial to determine if a miner has not seen a transaction or he has simply ignored it. It's probably a feasible mechanism within some accepted % error.

All this extra networking work would not be compensated though. Remember miners have no obligation to include transactions. I can understand big miners will try to use this opportunity to enforce some fees, and rightly so. You are basically asking the miners to do extra work to guarantee that freeloaders can continue to use their work for free, and that they will compete with botnets and "free electricity dorms" with no compensation whatsoever.

Banks charge for transfers exactly how I described:

- A minimum fee.
- A % fee for most cases (usually added to the minimum fee, but sometimes not if said % fee exceeds an amount) then...
- A maximum fee (because otherwise their clients would simply try their best to avoid transfers for such quantities and the processing cost for the bank is the same).

A purely fixed fee is simple and attractive to miners but it would make a sufficiently small transaction too expensive. Therefore this fee should be very small, which is why I'm talking about a minimum fee (say 0.01 or even less).

Basing it on KB would have a similar effect.

When I said obfuscation is not free in terms of resources, I meant that adding outputs means adding KB. Adding just 1 output is probably negligible, but then you're doing a really crap obfuscation job as adding 1 single address more to track is trivial. If you had to obfuscate/launder a significant sum in a big number of said steps, paying a fixed fee you'd be paying through your nose to have a decently sized tree.

The thing is, if you make it on KB in a trivial way, then most people will make their transactions the simplest they can. Which destroys anonymity as any extra obfuscation would cost you. Obviously this depends on how much do you plan to charge per extra byte, but in the end you might end up with something very similar to what I describe above, in practice ([min,%/some function,max] ranges).

Would it be possible to code in where miners can define a password for their graphs?

I did say "suggest" (ie, the user could always override it, because he can anyway) and "for larger transactions".
Someone sending 1000BTC is not going to switch to western union when he is kindly asked to pay 0.1 BTC fees instead of 0.001. Whether he lives in Congo or Monaco doesnt change a thing either.

But of course almost no one will. Its like asking people to pay their taxes voluntarily.
A protocol change might be a bridge too far, but it might not be a bad idea to have the default client at least  suggest a higher fee for larger transactions.

Does that seem right? I've pushed this to my nodes list, so if it looks wrong let me know.

I don't understand your code where it shows:


[Edit]: Just added some JavaScript to the nodes list for even faster page-load times. "Page generated in 4.9437 seconds"
Now, if I can just get it under 1 second...lol.

[Edit 2]: Forgot to cache 1 remote call and saved a LOAD of the time. "Page generated in 1.1933 seconds."
Still not under 1 second load times. xD

 Local: 680MH/s in last 10.0 minutes Local dead on arrival: ~3.2% (1-9%) Expected time to share: 1.3 hours
2012-03-21 08:53:53.332823  Shares: 91 (2 orphan, 3 dead) Stale rate: ~5.5% (2-13%) Efficiency: ~104.0% (96-108%)

What makes you think you have the right to ANY transaction information on any customer?

If this attack works (in the sense that it really is one and we fail to stop it) I want it to work now, not in 5 years when the harm is probably much more substantial (I mean harm to society, not harm to bitcoin itself)

We better make bitcoin as solid as possible before we really depend on it. People like Luke-Jr and ArtForz attacking alt-chains is part of this hardening-process.

I don't think so. And anyway: from a bitcoin perspective there are no "laws" against using a botnet to mine, are there? Neither are there any "laws" against tx-free blocks. The "laws" of bitcoin (bitcoin in terms of the blockchain) are the rules governing the blockchain implemented in the majority of the mining nodes.

If anyone wants to go after the botnet operator/owner through legal system, they are free to do so, but don't count on mtgox disclosing info without a court requiring them to do so.

you really want mtgox to tell publicly about their customers and to act like a bitcoin police?
for me this would be a reason to leave bitcoin completely.

but i dont have a big problem with this miner anyway... its just interesting

Is that really a road we want to go down?

i think something went wrong for me, my guiminer shows me right now 30 accapted shares, but my p2pool still says 0



anyone knows whats wrong?

I think the bigger question here is how is our new MM cashing out?

To cash out $90k a month on mtgox.com is multiple steps in verifying your identification.

There are no individual graphs.  You can set each miner to a unique username, and use the VIP password to get something like this:



by going to http://<your p2pool nodes ip>:9332/graphs


Now, if anyone knows how to edit the order, or remove old names from these graphs, that would be great.

[Edit 4]: Added current hash rates per pool.
Gotta <3 code...gotta love not sleeping. *snooze*

Yeah, I'm going to grab some rest to and when I get time in the morning I'll post something as well if there hasn't been any response.
Thanks for testing on my node.

Frequently Asked Questions

Q: "Why does cgminer report so many longpoll events when mining on p2pool? - P4Man"
A: "Once every ~10 seconds is normal. That is how often p2pool shares are generated (as opposed to ~10 min for bitcoin blocks) - cabin" 

I'm not barking at the p2pull specifically written in this thread to learn more. If luck is with me personally dropped - then why the speed? is also my speed reduced? (1440->930) Or is it the same? P2pul as always "accumulated" 17000 share and no more than "hoard" (in console), but after restarting it shows "Loading shares 22000)?? What is wrong?  Where are the other 5000 my shares?

2012-03-17 09:55:56.765012  Local: 1632MH/s in last 10.0 minutes Local dead on arrival: ~2.2% (0-6%) Expected time to share: 28.8 minutes
2012-03-17 09:55:56.765050  Shares: 307 (17 orphan, 2 dead) Stale rate: ~6.2% (3-10%) Efficiency: ~100.2% (96-103%)

A "hard fork" is, practically, just an update to a new version of p2pool. So most miners wont see any problem in that.

And, if we all switch to the new version/chain/fork at the same time, we wouldnt receive less per found block, since we all begin at zero.

New miners joining p2pool would of course cry out "I have 1gh, found three shares, the pool got a block but I only got a few cents, scam!!". If people constantly ask why they dont get paid out even though they found 100 shares [diff 1, that is], start explaining them that it takes days, weeks to have a steady income per block.. ;-)

Anyway, sounds good to me, I would do either way, 24h-averages or 7d-averages.

Ente