Pruning in this case doesn't actually have too much to do with the merkle tree here.  Once a transaction has been spent, and the spend is burred in your chain, you'll never need any of it's inputs (or the outputs they spend) again and so you can save the storage.   (the connecting tree isn't relevant, because you've already validated the transactions for yourself, you don't need to continually prove to yourself that you weren't lying to yourself)

When you get a transaction you don't know when it will be spent— or _if_ it ever will be— maybe you'll need to store its outputs for 6 months or 60 years.   But you do know that you'll be able to forget about its inputs as soon as they're burred deep enough in the chain.   So given equal total sizes we should strongly prefer to put more of the bytes in the script signature (the input side).

The current reference software doesn't take advantage of this... but the chain is only a gigabyte now.  The storage requirements from these decisions have an impact for basically forever.

Any split would resolve, assuming a simple majority of the future hash power was enforcing the new rules. It's not an unresolvable split risk.

70 characters is more like the minimum address length for a non P2SH secure wallet address.  An actual complex transaction might be more like 1000-2000 characters.

I gave genjix a pretty nice list of reasons why P2SH is important other than the long addresses. Unfortunately, he decided to only quote from people saying negative things about P2SH in his post.  Here is what I wrote to him:

Nothing changed. Thats the point. You didn't correct the highly exaggerated an "political" representation which I  (and _many_ other people) pointed out was confusing and misleading.

You've continued with your misrepresentation here with your selective bolding in your quotation.  For example, I'd spent some time making what I thought was a pretty clear and non "political" explanation of the subject in #bitcoin-mining, which I recommended you borrow from.  But you've bolded my commentary in a way which presents a false description of my position.

Please completely unbold my comments or completely bold them. I consider it unacceptable that you skipped over things like "< gmaxwell> genjix: explaining what the P2SH stuff does is fantastic. People seemed to like it when I explained it in #bitcoin-mining the other day."  but then bold the "but" part of the statement that I said next.

You make it sound like you're somehow more neutral than anyone else. This is nonsense, you might be less informed than other people— but that doesn't make you more neutral.  I gain _nothing_ from any of the particular proposals, nor did I write any of their code.  (I've done more testing work on BIP17 (the proposal that I don't prefer) than BIP16, simply because Luke needed help with testing and asked for it).  But somehow you paint me as a partisan? thats weird to me.

You don't have the signature either (and you can always derive the public key from the signature).  The point is that the attacker won't know the public key/signature until its announced ... and a few minutes after the announcement it's too late to attack.  So, assuming single use addresses (as was always intended) an attack on ECDSA would only be useful if you could pull it off very fast.

If you're going to slander like that you at least owe the participants here a link to a specific message/a quote.

I think what you're saying is untrue and unfounded but if you go around and repeat it as a fact people who, unlike me, haven't read almost all the discussion are going going to believe it.

Please show me a statement made by Gavin which is inaccurate or a personal attack.

The whole characterization of Luke vs Gavin is nonsense to begin with. BIP16 arose out of combining a half dozen proposals, it was a _consensus_ proposal. At the regular development meeting that produced it no one was objecting to it at the end (partially no one because Luke had to leave early, before he left he indicated that he would only support it if some language about deprecating non-BIP16 transactions was added to the BIP).


Come on, you know it's not the same. A single BIP17 stealer hidden on tor with only one connection to the network will be 100% effective (in an network without P2SH validation, of course). A BIP16 stealer is only 100% effective if run by a large miner, otherwise it is only X% effective in cases where the stealer is on the shortest path between the spender and X% of the mining hash power.   I agree that it's a corner case, but there is a difference there.

This isn't true.  Yes, Gavin created a bot that exploits a differential weakness of BIP17 vs BIP16. This was pretty helpful as luke was insisting there was no difference, and this let us feel out how the difference actually mattered.

This doesn't make testing impossible, and there are in fact test transaction there. It actually aided testing and helped find some misbehavior in the software Luke was running with BIP17.

I have mined testnet for Luke several times to aid in his testing (and, in fact, did a costly 40 blockish reorg for him).

I think it's unfortunate that both Tycho and Genjix are both spreading overt misinformation here in order to create controversy.  (Tycho making insane claims that testing BIP17 is impossible, Genjix with falsely describing this as a "vote", claiming that people don't want you to know about this open and widely discussed matter, the over the top subject line)

The kind of hysteria being promoted here is a very big disincentive to contributing technically to bitcoin. I encourage everyone to be patient and thoughtful and recognize that bitcoin can not survive if people with powerful media presences are able to disrupt development and exhaust the developers at will.  Discussion is great, but consider whos interest panic is well aligned with: Certainly not the interest of the Bitcoin using community. Don't let your emotions be manipulated.

This isn't the case. QC only gives a sqrt(N) speedup for generic blackbox non-linear inversion.  So on a magical pixie dust computer a 256 bit hash function has the same security as a 128 bit hash function has on a classical computer that does the same number of operations per second.

There are QC strong versions of all the applicable cryptographic operations, we don't use them only because they have much higher overhead (like 16kbyte signatures), but the mass media loves to over-hype the capabilities of (still non-existent) quantum computers so you never hear about them.

The scheme of H(pubkey) addresses in Bitcoin is a bit of insurance against many kinds of ECDSA (classical or otherwise) weakining.

P2SH (of any kind) largely preserve this property, though they may slightly increase exposure to classical cryptanalytic attacks because they allow an attacker almost arbitrary stuffing to produce a matching address without also having to solve the discrete log problem. E.g. with current addresses an attacker doesn't just have to find a preimage, he'd have to find one that he knows the ECDSA private key for. Under P2SH there is a wider variety of acceptable inputs.

That said, even if we used the now-compromised MD5 algorithm the practical MD chosen prefix collision attack there couldn't be used to steal random people's money with P2SH (because it requires the attacker produce both messages, it's not a preimage attack) though it might permit an attacker to generate an unusual escrow script  which could also be redeemed under a second set of rules.  (Not that this weakness exists with our SHA256 much less the HASH160, but I think its useful to reason about how the system would work with parts replaced with compromised versions).

No, Luke didn't have to test on the real network.

He tested on the real network before he was aware of the stealing bot, in fact. He tested on the real network because he controls the content of the blocks of 400GH/s.  He tested on the real network because he could.

When the stealing bot was noticed and was causing Luke some trouble with continued testing I mined some 40ish blocks to reorganize testnet to undo the stealing bot so Luke could continue his testing there.  (something that I couldn't do on the real network, which is part of the reason testnet is so much better for testing)

CIDR could be implemented, as could lists... might make sense to do as part of IPv6 support.

The rate limiting I coded up is per-IP, and localhost is exempted. I also started with per-group (e.g. /16 for ipv4) but thought it too risky.

Anti-brute-force is really a protection of last resort— the attacker doesn't have to be impatient he could use dozens of IPs (e.g. tor) and scan you for months in slow motion, even if its fairly aggressive it does not have that much protective value, e.g. even it it only allowed one bad attempt per IP ever, getting 1000 IPs is not _that_ hard and would have been sufficient here. So this sort of feature has to be carefully weighed against the DOS vulnerabilities it might create.

The real hope of this kind of protection is to reduce the odds of success and increase the cost of attacking enough so that few people bother attacking in the first place... creating a kind of protective halo of disinterest around the few users where all of the other better protections have failed.

And in the process actually leaks information about the length of the password, though admittadly not much it's still kind of embarrassing since it lets the attacker know when their attack is likely to be profitable or not.

I have a patch in progress which improves logging and does the rate limiting. Being sure it doesn't create a dos and isn't gratuitously incompatible with the threaded RPC is why it's not already a pull request.  (also, I'm kinda uncomfortable about timeouts in the code since it's currently single threaded... any simple implementation of delays is an automatic DOS).

(the improved logging is important because it makes it slightly more likely that the attacker will get caught, but mostly because right now the vague logging causes people to open up allowip more than required because it's not clear why their requests are being rejected, especially as we have pretty weird wildcarding syntax)

And yes— m3ta had to do a lot of things to create this vulnerability.   But it isn't like he did them because he was _trying_ to get robbed, he did them because various tools and capabilities in our ecosystem put him in a position where the mistake was easy to make, and anytime that happens _someone_ will make the mistake eventually— it just happened to be him.  The fact that he was exploited was also because lots of other people are vulnerable too, otherwise the attackers wouldn't exist.

(And if you saw this thread and didn't go check your RPC and firewall settings, just to be sure, you're a fool— in my view)

If you look at industrial accidents there is a constant pattern in most of them— some stupendous feat of human error managed to bypass several safeties designed to prevent human error, all at the same time.   If you focus on the magnitude of the human error, you'll do nothing to reduce the incidence of failure in the future. Human error is a natural force as unstoppable as gravity.  We should build systems which have every worthwhile immunity, because the human failure is not going to go away. (It's going to get a lot worse, in fact, as more unsophisticated users adopt bitcoin)

In addition to some belts an suspenders in resisting basic brute-force attacks there are other things that could be done. There are _other_ daemons with similar RPC ports that don't have this problem because the daemon itself generates a default key and puts it in the file. e.g. Chrony.

This is an archived thread of P2Pool discussion.

See the new thread for more recent P2Pool discussion.

In the time since P2Pool's original announcement it has evolved considerably.  I thought  having to wade through hundreds of pages of inapplicable cruft about old versions of the software to get to useful information was a disservice to people here, so I split off the old discussion to a separate archival thread.

P2Pool has come a long way since its humble beginnings: It's now a completely realistic solution for a great many miners. The software is still rapidly developing but it is reliable, featureful, and, of course, P2Pool is critical for the health and welfare of the Bitcoin system: Our trust in the Bitcoin system depends on it being highly decentralized. P2Pool prevents the centralization that non-distributed pools create.  This is important enough to people that P2Pool miners are currently being paid by Bitcoin users to participate.  P2Pool pools payments but mining decisions are still left to all the miners just as bitcoin was intended to work.

This "pool" (really a decentralized/distributed network just like Bitcoin) is still attractive even for people who aren't thinking about the health of Bitcoin overall. P2pool's decentralization is accomplished without compromising on miner profits and, unlike solo mining, while still allowing stable income. The things which p2pool can't do, like provide the utmost low variance (PPS) are offset by the lack of fees and by removing the risk of cheating by pool operators (which is almost undetectable if only done in moderation).

P2Pool isn't ideal for low speed (e.g. CPU) miners, and may never be— but it's absolutely a no brainier for anyone who would even consider solo-mining and a good majority of the people in between.

I'm personally really happy about the new built in per-worker graphs:


I hope to see more useful monitoring features in the future.

Yup. And it bears repeating, it's an idiotic voting system— even if it weren't getting ignored as spam,  miners could just willy nilly pick the election outcomes by simply refusing to mine 'votes' for particular addresses.

POW chain systems are amazing, but they're not good for votes except of very specialized kinds.

I encourage people to work on cryptosystem powered voting. But while many in the bitcoin community will be interested in it and would be glad to use it, such systems shouldn't be build on bitcoin itself. It's not a good fit technically nor cramming unrelated data into bitcoin welcome by people who want bitcoin to be used as a decentralized currency.

This is true for regular pools too! The pool will only credit you for work matching a header they gave you.

Kudos to the writers. I think they covered the subject matter pretty reasonably.

The parody of the weusecoins video was a riot. Can we get a copy of that?

Ah!  Please nag the authors of that software to implement the same anti-dos fee rules as are in the reference client. The rules in the client are there to protect the client from the network not processing it's transactions. Your experience is an example of this— sometimes people miss the importance of it simply because so few txn hit the mandatory fee rules (though subcent output ones always do).

I don't know what the resend policy is for that client. In the reference client it will remember transactions forever that it was a party to (which I'm sure the android one does too), and it will rebroadcast them after a random delay with a maximum of 30 minutes every time a block has been solved since the last rebroadcast without including them.

This isn't weird in the _slightest_. Though just about all nodes will happily mine normal zero fee txn, most will not mine zero fee bitdust transactions because they are indistinguishable from a DOS attack.  (And this protection being insufficient is what litcoin's chain grew from like 50 MB to about 400MB in a week or so).

Look again at the original post: "few sub-cent tx with no fees "

As far as forgetting them— the advice upthread is bad.   If you modify the wallet to make it forget about them and then leave it off for a bit,   other nodes will forget about the transaction on their own after a few hours— the memory pool has a finite lifetime.  They only remember it because the owner node keeps reminding them.

After the network has forgotten the transactions and your own node has been mindwiped,  you can respend the inputs just fine. 

Of course, modifying your wallet to remove the transactions is a big pain in the ass... but since the OP obviously modified his client software to get it to create this suspiciously-DOS-attack-like transactions which the client would have refused to generate without modification, he should have no problem trimming the wallet on his own.

Cheers.

People have different motivations behind this general functionality.

Gavin wants it so that the bitcoin software can offer wallets that require two party signoff (or two of three, or whatever).  When you spend from such a wallet you'd ask one of your second parties for a signature and they might follow up with you via SMS or a phone call.  Perhaps you are the second party yourself, with software on your mobile phone.   In any case the effect is that a hacker or trojan on your system can not steal your bitcoins.

This solves a fundamental weakness bitcoin has right now:  The security of typical desktop computers is terrible and hard to fix.  You might get 0wned up with respect to a classical banking site but they can and _will_ reverse the transactions resulting from your machine being compromised, but we can't do that with bitcoin.  If we want bitcoin to grow we have to solve this problem— bitcoin is not going to grow if it's only safely usable by Linux using security experts.

Personally, (as a Linux using security expert wannabe) I'm more excited about the prospects of using the same functionality to do escrow transactions without requiring any new functionality in the bitcoin code.   I want to sell you a car,  you  don't want me to be able to run off with your funds if the car is a lemon.  We agree to form an address (using a separate tool or potentially a JS webpage) that can only be redeemed if both of us sign off on it.  You pay to the address, putting the funds into escrow— I give you the car— if it doesn't blow up you unlock the txn and I can spend it.

You can use the same functionality to implement trusts and other kinds of fancy payment rules, — and do this all without additional changes to the bitcoin software within the same framework (though you'd need small little external programs to create the special addresses).

These things can be done without P2SH but then they'd require direct support for them in the senders software or  scary (and unwieldy) serialized script addresses, and result in lots of output side chain bloat.

Also, for the wallet-protection use case, without P2SH the _sender_ has to pay the fees related to large transaction data due to complicated rules which are required by you.
 

If you don't think the blockchain size is an issue, I invite you to delete your copy of the chain and restart your client. In 20 hours, most likely, you can tell me if you still agree with that position.    

"alternate potential solutions" are additive with this, not exclusive.  P2SH makes a fundamental improvement to the storage requirements, by moving most of the storage to the input script side it makes the size of a pruned chain much smaller. This is especially important for the large scripts that complicated escrow/trust/wallet-security addresses will require.   It's basically not possible to make the output scripts smaller than BIP 16 (P2SH): they consist of only two bytes more than the payee-hash itself.  (and those two bytes are essential for compatibility with existing nodes).

Other improvements, like public key recovery can be combined with P2SH to make the inputs sides smaller. But thats independent— and applies equally if you're using P2SH or not.

Part of the reason why this isn't a secondary concern is that the use cases that we hope to enable with P2SH would result in transactions which are 2-3x (or more) larger than standard single party transactions with all that data in the script outputs (which are potentially never prunable), so its important that the feature that enables that functionality also contain the solution to the chain bloat it potentially enables.