Oh great, it's a mildly disguised all pay auction (after all, if you stand to win 100 BTC shouldn't you pay up to 99.999 to your own voting address to win, and once two have done that shouldn't you keep on paying to minimize your loss?)  which also encourages bloating the blockchain with tiny transactions.

There is no reason to conduct a "vote" using the blockchain. In fact, doing so is a pretty poor idea because it gives miners the ability to influence the outcome by rejecting transactions.  It doesn't even secure you against manipulation, because the recipient of the vote-funds can just pay themselves (anonymously) to get whatever result they want since they're just going to get the funds back.

In the case of CLC you could, you just have to pay a 100 CLC transaction fee.  In the case of other ones, you may have to start two nodes (if you are the only one) and mine them yourself if you want to process a transaction.

What reject rate does your rpc miner show?  Are you running NTP (is your clock correct)?

The big -/+ means you don't really have much data for the estimate.  Those ranges mean that in fact your true stale rate might actually be pretty low.

Because you're a bit behind when you start its usually to get a couple stales right away that makes the number start out poor but then it improves with time.  It's not unusual for me to see stales at 20% shortly after startup but by efficiency is usually at 100% by the next morning or so.  (converges a bit faster if you have more hash power though)

I have no freeking clue what you're talking about, in fact.

I was told that the >100% payout private pools were operating services which returned clean coins to people engaging in unlawful activities, which seemed like the only explicable purpose for them since they are effectively paying people $1.15 for a _chance_ at $1.

If this was true I think the participating miners would have a right to know, since they'd be potentially putting them in front of investigations for the unlawful activities connected to the coins they received (if there was no such risk, why launder the coins?). My message explained this quite directly.

I included child porn in the list of potentially unlawful activities that people may trade with Bitcoin that the recipient of laundered funds may be investigated for in my cautionary message just because "Guns and drugs" sounded like SR, and I didn't have any reason to think the laundering was related to SR specifically, nor were they there to defend themselves— and I'm aware there have been issues in the past with people offering child sex services in our related communities.

I was particularly concerned that the people proffering these services were not even making an _attempt_ to argue a legitimate lawful purpose to them.

How was I supposed to know that Goat was a expat living in Thailand (?) who people had been previously accused of being involved in child sex trafficking?  :-/   I had not been made aware of those particular accusations (though perhaps the people telling me that the >100% payouts were for laundering had been). I was not aware of the previous boondoggle with the supposedly underage undocumented cam girl.  Though perhaps I might point out that in most of the developed world the obligation is on the provider of sexual content to document that their models are of age rather than demanding that other people, without the benefit of knowing their identity, prove them to be underage.

Do we really want to be running a community here where people express a concern the accused offer assassination market payments to "uncover" evidence against their accusers? I don't think this is acceptable.

For whatever it's worth. You are not an idiot. We all make mistakes like this from time to time— though fortunately most of the time we're lucky to escape without any real consequences.  Looks like you were not.

In the future the software will hopefully make these mistakes harder, and awareness from your post may help other people avoid the similar mistakes too.

I hope you're able to get it back with the recovery tools— it's happened before so there is still hope.

Unfortunately we can't answer that question yet.  People often drastically overstate the theoretical power of quantum computers. Since the actual power of quantum computers is currently zero (they don't exist), the actual threat is zero and it's hard to reason about how big the ones that might it exist may be because we don't know how to build them.

That said— A very large and fast true quantum computer of a scale which may turn out to not be physically possible could create problems for our ECDSA signatures.

The design of Bitcoin minimizes the exposure there:  If you use bitcoin addresses only once (as is intended for privacy reasons) then your ECDSA public key is only exposed right when you spend, which is just minutes before an ECDSA attack would no longer be effective— so an attacker wouldn't just have to be able to compromise ECDSA they'd have to do it fast.  It's likely that once ECDSA attacks became feasible they would be slow for a long time.

(E.g. even though RSA-512 is crackable (enough so that crazy over computing powered people like me have done it at home) Bitcoin would not be fatally insecure right now if we used RSA-512)

Secondly, our scripting system allows for some kinds of backwards compatible changes. If QC ECDSA attacks started becoming threatening looking we could extend Bitcoin with a resistant signature algorithm (like lamport) and create transactions which require both ECC and Lamport keys. Old nodes would validate only the ECC key and ignore the lamport, new nodes would validate both. 

(The hash functions in bitcoin are probably secure— at least to QC specific threats— QC only provides a sqrt(n) for black box non-linear inversion— so a 256 bit hash has the same security under QC that as 128 bit hash has on classical computer, which is sufficient. This does imply that if miners got QC's which did as many operations per second as their classic computing hardware (a crazy assumption but whatever) then the difficulty would square— e.g. we'd go from difficulty 1,000,000 to 1,000,000,000,000)

Unfortunately I can't find any explanation of what this hashing power is used for which justifies paying greater than it's direct present value.

If you were operating a service which paid $1.15 for every $1 sold to it, which is what your service is precisely isomorphic to, the same concerns would be raised.

The accusations were already circulating before I brought up the question here. You should be happy to have the opportunity to answer them directly.


I did not intend it as accusation, I thought I was adequately clear: I do not know, and I'm looking for answers.  I posed a hypothetical— If you are not in, in fact, engaging in a business which facilitates flimsy bitcoin laundering via mining then I am apologetic for implying otherwise.

Certainly you must agree that when someone sells mining or bitcoin for instant returns _in bitcoin_ of greater than 100% without cautiously evaluating the business they are getting involved with that there is a _risk_ that their funds could be used to launder for these sorts of activities and that the kind of caution I was encouraging is advisable. No?

I see that you did not, in fact, answer my questions:

Are you using this mining power to engage in bitcoin laundering?
If so, are you personally aware of the details of the transactions which you are laundering for? Can you certify that your service is not facilitating any unlawful or unethical activity?

Will your activity potentially bring unwanted attention by authorities to your mining employees?

I can find no answer to these questions in your documents. Nor does your your veiled contract offering fairly large sums to manufacturer fake "evidence" against me, inspire great confidence on my part.

I'll go hide the first paragraph of my message if it is a distraction which is preventing you from controlling your emotion long enough to give straight factual answers to these questions which I believe are of great interest to the community here.


I have very little clue about you personally. Your response here and in other places I've seen you interact does not inspire me with any confidence about your character— but thats irrelevant.  You have previously ignored private message, so I haven't really had a chance to get to know you. I did not intend to attack your character here (you're doing a good enough job of that yourself), I only intended to ask some serious questions.  

If you look at my posts you can see that I'm not a great advocate of Luke's— and I don't harbor any ill will against you related to that.  I asked because I'm concerned about the health of the bitcoin community, the well-being of my fellow miners, and the reputation of Bitcoin itself.

DWave's system, even believing 100% of their claims, is not a "quantum computer" by the definition used by scientists.  It can't be usefully applied to things like cryptographic puzzles because it just doesn't do that kind of computation.  It would be like calling a machine which can _only_ add integers a computer. Yes, it computes things, but it can't compute in the general sense.  Nor is their engineering approach actually applicable to build something which could properly be called a quantum computer.

So what should someone who's been mining for you do when after they use their mined coins to buy Alpaca Socks law enforcement shows up and tells them that their coins were the marked proceeds from a sting operation related to drugs, arms sales, child porn trade, or that they were bitcoins reported previously stolen and that they have a warrants to seize all their computers to look for evidence?

The word on IRC is that these private services which pay >100% PPS in BTC for mining are doing this because they're attempting to get rid of 'dirty' coins which could potentially be traced in exchange for freshly mined coins.  Certainly this is the only thing I've heard that makes any economic sense at all, but if it's true don't the miners have a right to know what role they're playing in this and what risk they're taking?

Have I got it wrong?  Can you help me understand what the business is here?

BIP16 transactions are simply accepted as valid by old clients. They can't become isolated due to this.

The users choose, not the miners.

I don't think any particular issue is the end of the world— but the representation that we can just use big addresses and it's no big deal is ignoring that there are other issues. I know you know about some of them. But I don't believe most people saying "oh, big addresses are no big deal" do.


Interesting thought, I hadn't considered that possibility. But "We can handle longer ones" isn't the same as "don't care" by doing that the minimum length for a 2of2 simple secured wallet, pretty much the simplest case, probably won't fit in a tweet anymore (for example), they won't fit in the small QR codes anymore, etc.

Do you have a magic solution to recipients losing the freedom to have complicated rules because the sender doesn't want to handle the TXN fees or risk of slow processing?  The concentration of more data in unprunable unspent outputs? etc.   Thats it— it's just not simply "big addresses", there are other issues even if they aren't super major.

BIP17 advocates (mostly Luke) argue that BIP17 is more conservative, because the change in behavior is conceptually more clean and less "special".  BIP16 advocates counter that the BIP16 change is more focused and narrow (And point out that old nodes still do at least superficial validation of BIP16, and other minor technical details) and that this makes it more conservative. BIP17 points out that its patches are somewhat smaller, BIP16 could counter that thats because BIP17 leaves some minor technical shortcomings open.  I don't think there is an objective way to settle that, they're all earnest perspectives.

During the discussion that was to become BIP16 I suggested that we satisify Luke by simply sticking a completely pointless OP_NOP at the end.. an OP_MAKEITSO, if you will:

09:35 < gmaxwell> sipa: okay, so lets end this argument and add a freeking op_code for this for luke.
[...]
09:36 < gavinandresen> I don't like adding an extra byte to make luke-jr feel better.

But doing this would perpetually bloat the blockchain a bit just so that Luke (and now a few others) would feel better about the cleanliness of the solution.  It's a real cost that will cost bitcoin users real money now and in the future and will contribute to the loss of decentralization as bitcoin grows.

I think Gavin is also rightly concerned about placating Luke for the sake of placating Luke. Luke's argument style is a bit like terrorism: He's a hard working contributor, and sometimes easy to compromise with, but sometimes when things don't go his way he just keeps turning up the rhetoric until everyone else burns out or folds.

Ignoring the bloat issue, it's good to avoid burning up NOPs:  We only have 10 of them, 9 really because the first one has been randomly used in toy transactions, when people really weren't thinking about what the NOPs were actually there for. Because they are our only method for adding explicit behavior in a backwards compatible way we must steward them carefully.

Luke's BIP17 avoids creating that bloat by making his new OPcode also do what two of our existing opcodes (HASH160, OP_EQUAL) do in addition to the MAKEITSO part.  The primary cost of this is that his transactions look like pay to anyone, rather than pay to hash-secret to old nodes.

In discussion Luke also indicated that he'd find BIP16 more acceptable if it was written so that BIP16 style transaction were expressed in the documentation just as a series of special bytes, not as a script and if old style transactions were deprecated (at least for new usage). His opinion there is that doing this would just make BIP16 the new way of doing things, not a special case (but rather the old outputs would be the special case).  I think Gavin made a political error by not just going along with that.   (Luke would point out that he's glad Gavin didn't because it caused him to propose BIP17 which he believes to be better than BIP16 with the "right" description).

It's not possible to bypass the scripting system while remaining compatible with bitcoin.

BIP16 uses the script "OP_HASH160 [20-byte-hash-value] OP_EQUAL"

BIP17 uses the script " [20-byte-hash-value] OP_CHECKHASHVERIFY OP_DROP"  but OP_CHECKHASHVERIFY isn't something that existed already, it's something that Luke made up for the purpose of BIP17.  In order to make it compatible it's overlaid on top of OP_NOP2.

From the perspective of prior software nodes BIP16 transactions say "Check that the data the redeemer is providing hashes to this value from the address, if so then allow redemption" and BIP17 transactions say "allow redemption" (no condition).

From the perspective of new nodes both say "Check that the provided bitcoin script hashes to the value from the address, then execute it".   The execution is implicit in both cases, the BIP16 style uses an existing way of saying hash some data and check it (which is why old nodes are able to do that much validation) but gives it special meaning for this case, the BIP17 style introduces a completely novel way of checking hashes which is ignored by old nodes in order to make the implied execution special to just the new opcode it introduces.

If the transaction has any output less than 0.01 it is considered suspiciously spamlike and will need to provide a fee, at least by most of the software out there (see also: https://en.bitcoin.it/wiki/Transaction_fees). It isn't just mining nodes you need to worry about, without meeting this anti-DOS rule most nodes won't even forward your transactions along.

The unmodified reference client will automatically add the small fees it believes are _required_ by the network due to the anti-dos rules, even if you have paytxfee set to zero.

I encourage you to maintain a balance, and if you have auto-payout only pay when the users hit some fairly large threshold on the order of 0.1 to 1.0.  By maintaining some balances and doing bulk operations you'll also increase your ability to use sendmany, which will reduce chain traffic and require less fees from you (less risk of looking spamlike).

A great number of users only run their clients intermittently and if they've been offline for a bit no transaction is going to be instant to their client from their perspective as they'll need to catch up.  They probably won't see it at all until it's mined, which may be an especially long time if your payments look spammy.   Payments within your system will always look instant to your users of course.

More importantly, you do your users a disservice by paying them tiny amounts frequently.  When they go to respend those coins they'll each add to the input data size of their spending transaction— and the user will end up paying more fees overall then if they'd just been paid in bigger chunks a little less frequently.

Cheers,

Since no one has given you a serious reply—  No, this is completely unrelated.

At the level of similarity you're perceiving there the already existing bitcoin system also fits.   BIP16/BIP17 don't change the behavior of the scripting system except in changing _when_ the script requirements for the disposition of a transaction are provided. With P2SH you commit to your requirements when you pay (by giving a hash of them) but they're provided by the spending transaction.

It doesn't change the scripting language, make it more powerful or turing complete.  BIP12 did increase the expressive power some by adding limited recursion, but no one wants to go that way now.

I challenge you to demonstrate how well informed you are on this sub-subject by linking to posts giving at least three total distinct arguments against that position.

This thread was locked, but I couldn't figure out why— no closing message nor anything I could find in the staff forum. People complained to me so I've unlocked it. I apologize if I've missed something obvious. Cheers.

Man, I wish this were true, but it's not. (and I'm basically informed about EC math )

The problem we need to address with wallet security is this:  We can't trust a service provider to have control over our private keys (see mybitcoin) and (many users) can't really trust their own computers because of viruses and trojans (which even superhuman effort don't completely prevent unless you go the offline dedicated hardware route, with poor usability). These are also problems for traditional banking, but in traditional banking transactions are reversible— which stinks but hides a lot of security sins by user and the banking infrastructure.

You absolutely can have two people create a key in two parts which must be combined to sign via multiplication of the public/private parts (I use that property in the type-2 deterministic wallets I describe in the link above).  The problem is that they must actually be combined to use them, meaning that somewhere there must exist a single computer with the final private key in memory. ... but in our threat model above no such ultimately trustworthy computer exists.  People also have good reasons for needing things like "Two of {A,B,C}, or D" which doesn't fit into a simple combined key/threshold model. So we must use multisignature transactions for this purpose.

There do exist threshold signature schemes which allow for independent processing, but the ones I'm aware of have other compromises (like being large) and, more critically, aren't compatible with our ECDSA.   This is sad because as nice as multisig is, you couldn't do crazy things like have a transaction directly controlled by 50,001 out of 100,000 people with it (the spending transaction would be too big).

P2SH does nice things for other kinds of complicated transactions— not just multisignature. So even though multisignaure is the main end-user use for the here and now it's still a good direction independent of that.

Grrrrr.  This is rubbish.  I'm quite irritated with Genjix promoting this horrible misunderstanding of the Bitcoin system as being based on some kind of majority election in his post by taking "one cpu, one vote" out of context and applying it to parts of the system where it does not apply.

(FWIW, I'm the anonymously quoted person in his latest essay.)

Please go (re-)read this post:  http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source


The Bitcoin system is _NOT_ up for a majority election. Not a majority of hashpower, not a majority of people, not a majority of money.

For example, what happens if a super-majority—even 100%—of the current miners decide that the subsidy should be 50 BTC forever?  NOTHING. Miners who change that rule in their software simply stop existing from the perspective of the bitcoin network.  What happens if a super-majority—even 100%—of the current miners decide that they're going to mine a transaction that takes all of your Bitcoin and gives it to them?  NOTHING.  Miners who violate the protocol rules stop existing from the perspective of the bitcoin network. What happens if a super-majority—even 100%—of the current miners decide that they're going to lie about the current time in order to mine 20 million BTC this year instead of over the next decades? NOTHING(* ignoring the timewarp bug).  Miners who produce objectively incorrect blocks are ignored by the Bitcoin software run by everyone else.

Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what.

Now—it would have been Satoshi's dream to make the entire system work completely like this but sadly Einstein came along and screwed everything up: relativity says that the temporal ordering of events is different for every observer and depends on your mutual locations in spacetime.  A decentralized system does not exist in just one place and thus there can be no single constant decentralized view of the flow of time and ordering of events.

(Bitcoin needs to reach a consensus about order so that it can decide which of multiple attempts to spend the same coin is the single valid one, in the rare case that someone would attempt to fraudulently spend the same coin more than once)

To solve this, Satoshi introduced a very limited form of a specialized kind of voting: miners express their view of the ordering of events in a way which is fully decentralized, attack resistant, and inevitably convergent.  This voting is very limited—miners can decide the order of transactions (including orders which place transactions infinitely far in the future). But that is it. They do not get to do anything else. This is powerful, yes, but it's also still very limited. As absolutely limited as possible.

The vision of Bitcoin is not a vision of democracy, where the wolves can vote to have the sheep for supper, it's a vision of independence and autonomy.  We use a "vote" where we have no choice, but the Bitcoin system itself is a consensus of deterministic rules.

P2SH is only possible because it takes things that were previously permitted and makes them not permitted—to old clients P2SH transactions look like "anyone who knows this hash puzzle can spend this coin" (BIP16/BIP12) or "anyone at all can spend this coin" (BIP17). Going the other way—from forbidden to permitted—would be akin to boiling the oceans.  We are very fortunate that Satoshi had the foresight to add many No-op instructions to the script in order to make additions like this possible.

In the case of P2SH, the development team could easily deploy this functionality against the will of the miners: they'd simply issue a new client that enforces the BIP16 rule and send an alert which would pop up a message for every bitcoin user telling them to update.  Miners that failed to update would eventually extend a chain containing a contradictory transaction and from that moment they would no longer be miners from the perspective of the majority of Bitcoin users,  no matter how many yottahashes they had.  Done.

(If users reject the change too—well, they can get themselves some new developers, but the miners never come into that picture except as users)

There are some reasons that this wouldn't be quite so simple. First—miners are Bitcoin users too, they are probably more technical than average, and change to Bitcoin needs to be adopted by the users by general consensus. Having their support is good and prudent. Secondly—P2SH is secure only if either >>50% of the miners have it or the vast majority of the clients do (thus making the miners who don't have it irrelevant). The former is easier to get (and easy to objectively measure, so long as people don't misrepresent the purpose of the coinbase tags), so it's a prudent path for making P2SH secure as fast as possible.

None of this translates into Bitcoin protocol being driven by a majority vote, and certainly not a majority vote of miners (who may or may not be well-aligned with the majority of the users).  

The next point which is irritating me is the false controversy being made here.  There is some minor disagreement, centered primarily on one person, over some technical minutia which was small enough that Genjix didn't bother to explain it and which is boring enough that you probably don't want to hear it from me an Nth time.

Among competent and involved parties there is pretty much consensus over the direction, though a little less about the timing.  This is partially due to the core development team being too busy developing and testing (and shooting the shit on IRC ) to communicate effectively to the broader community. Luke has been building a useful matrix of involved developers' views.  Gavin has started making some better public-facing documentation of the thoroughness of the work so far, and Luke has created a parallel page for BIP17. I hope these measures and more like them will fill up some of the communications vacuum which has recently created a niche for a few uninformed hysteria promoters.

Cheers,