I just want to point out (before people get into a conspiracy panic) that this doesn't make any technical sense.  The address of a traditional, single signature transaction, is a cryptographic hash of the public key that is used for signature verification in the spend transaction.  The address of a single signature transaction implemented with P2SH would be a cryptographic hash of the public key + an opcode (OP_CHECKSIG or OP_CHECKSIGVERIFY).  The notion that you couldn't create a crippled bitcoin client incapable of generating original addresses is nonsense…governments would have to ban general purpose computers (hell, they'd probably have to ban handheld calculators).

I hope people don't get turned off or frustrated by this process…that's exactly what this is, a process.  I think some people have allowed what should be an objective debate on technical merits to turn a little personal and have said things that they probably regret.  And people shouldn't allow themselves to get their identity wrapped up in a solution that they've proposed.  A rejection of a technical proposal is not a rejection of you as a person.  I have no reason to believe that anyone here is acting in anything but the best interests of bitcoin.


I want to voice my opinion against long-address multisig.  In my opinion, that's the last thing that should be implemented (actually, it's not the last thing that should be implemented…it should *never* be implemented…it's even more hacky than BIP-16).  P2SH is the proper way to handle multi-sig (and many other types of transactions).  And as I've said earlier in this thread, all transactions should eventually be P2SH.  P2PK (pay to public key…the current style transactions) is a just special case of P2SH.

Lastly, everyone should be in favor of implementing P2SH in some form.  The kind of transactions it enables will add great value to bitcoin.  In fact, if bitcoin doesn't do this, it will create an opportunity for a competing coin that does provide this innovation…this is the kind of fundamental improvement that could allow an alt-coin to overtake bitcoin.  So, everyone that has invested their time and/or money into bitcoin should be in favor to getting this implemented.

I'm glad that BIP-12 was abandoned, I'm not sure why Tycho would have preferred it.  OP_EVAL clearly complicates static analysis, which would complicate measures designed to combat script based DOS attacks.  It also doesn't really add anything of value (besides enabling p2sh transaction).  I can see why it's appealing to people though.  Everyone is used to scriptPubKey being the place where all the interesting script belongs and scriptSig being just a couple push operations.  OP_EVAL makes it "feel" like the interesting script is executing in the scriptPubKey.  This is a cargo cult.  I think people that have worked with the code in detail for a long time may be too close to the problem and need to step back a bit.

All transactions should have been p2sh type transactions from the very beginning.  There should never have been this concept of prepending scriptSig to scriptPubKey for execution.  ScriptPubKey should have always been just a hash value and validation should have always been to hash the script in scriptSig.  To get a bit beyond the confusing "scriptSig" and "scriptPubKey" terminology, outputs of a transaction should have always been just a hash (bitcoin address), not a script.  The inputs are where the script belongs…the script (which would typically include one or more public keys) must hash to the value specified in the corresponding output.  This allows the recipient to always specify the conditions for spending (they create the script, hash it, and that's the bitcoin address they give to the sender).  The script can be a simple, single signature, or something more interesting involving multiple signatures.

BIP-16 feels like BIP-12's little brother…still clinging to this flawed notion that all interesting script should be in the scriptPubKey.  And it requires special rules that implicitly execute code that was pushed on the stack in the scriptSig (if you read the script proposed in BIP-16, nowhere is there an opcode that says "execute that stuff on the stack" and yet, it must get executed…so you've created a special kind of script with special rules for what is executed).  BIP-17 is cleaner in my opinion…it doesn't try to push code onto the stack for the purpose of later execution, instead it just executes it as you normally would and code in the scriptPubKey verifies that the code that was just executed matches the hash (bitcoin address) in the scriptPubKey.

BIP-17 would seem to have a bit larger hole regarding the spendability of these transactions during the upgrade period (BIP-16 has a similar problem, but a bit less of a risk).  In neither case would I want to create one of these transactions with any significant amount of bitcoins before a super majority of miners support the new transactions (though BIP-17 is more risky).  Neither are really a problem once the super majority of miners are fully supporting the BIP.  I do fear that during the transition there will be an easy way for people to execute a double spend.  Both BIP-16 and BIP-17 make the following equally possible: you create a new style transaction that is mined by a miner supporting the new transactions (old nodes will accept those blocks).  You then deliberately create a transaction that spends out of this transaction, but put a bogus signature on it.  Old nodes/miners won't check the signature, but new nodes and miners will…your transaction will look perfectly ok to old nodes/miners…and you may even get lucky for a block or two if old miners mine your transaction (creating a chain split).  For this reason, I think it would be very advisable for everyone to upgrade their clients when either BIP-16 or BIP-17 get adopted.  The reason for wanting backward compatibility was to avoid requiring everyone to upgrade, but I think people that don't upgrade might be at risk even if a backward compatible approach is taken.

Overall, I think BIP-17 is the better proposal.

Note: one thing I think should be considered for standard BIP-17 style transactions is a test right after the code separator (so it's included in the hash) to ensure the proper number of arguments have been pushed onto the stack.  It seems that there is a hole where nodes could put additional things at the beginning of scriptSig without rendering a transaction invalid.  That seems bad.

We have corrected the bug that caused the country information to get dropped.  For those that have already ordered, you can either send an email to support@bit-pay.com with your invoice URL and your country, or we'll contact you (if we cannot determine your country ourselves).

As for the issue with Schildbach wallet, that's a wallet I'm not familiar with.  We have to put a deadline on the payments because either we need to sell those bitcoins for our merchants, or the merchants themselves need to sell bitcoins.  And as everyone is aware, the bitcoin price can be volatile at times.  Some wallets won't deliver transactions to the network unless it's fully caught up with the block chain.  Some of the online wallets (and exchange accounts) also can have delays in sending a transaction.  I'll look into Schildbach wallet and see whether that might be the case.  Note, Bitcoin Spinner seems to be very good about prompt delivery of transactions.

Edit: Just realized Schildbach wallet is "The Bitcoin Wallet" on Android.  That is a full client (downloads block chain) if I'm not mistaken.  I'm not that familiar with it, but it's likely that it works like the main bitcoin client in that it won't send out a transaction unless it is caught up on the block chain.

Also, this whole debate makes me wonder whether it wouldn't be worthwhile factoring out the script validation/execution engine to allow that bit to be independently upgraded from the rest of the bitcoin client.  It might also help with unit testing and verifying a critical bit of code to keep it separated from everything else.

Isn't it still possible for anyone to spend out of a BIP-16 transaction if someone has ever revealed the public key (so, if you ever spend from a BIP16 transaction, you would certainly want to spend out of every transaction funding that address to avoid a chance that someone will spend those other transactions)?  

So, let me see if I can sum up the choices when changing the protocol (regardless of which proposal is adopted):

1) Make things backward compatible in order to avoid a chain split - this creates a risk that coins can be stolen because old nodes/miners aren't performing full validation on the new transactions…to avoid this risk you do what?  wait until 100% of all mining capacity has upgraded before using the new transaction types?

2) Ensure that no nodes (old/new, miner or non miner) allow any transaction that doesn't pass all validation and accept that a chain split could (will) happen - this creates a risk that people who don't upgrade can end up with un-spendable coins in their wallets (a double spend could be executed by creating a transaction accepted in the new chain, but not in the old, then spend those coins again on the old chain).

I'm not sure which is the better approach…just trying to make sense of it.  However, it feels like it's better to ensure coins can't be accidentally spent and that full validation is always performed.  If the super majority of the network is switching, then people will upgrade or patch…that's just part of the deal with bitcoin IMO.  I also question the wisdom of OP_NOP bytecodes.  Seems like it would be smarter to make them cause a script to immediately fail (if that were the case, we wouldn't be having this discussion, we would be talking about a clean implementation and a proper transition of the network).

Wallets shouldn't really allow private keys to be imported easily…instead they should sweep the coins of a private key into other addresses that the wallet contains.  Similarly, they shouldn't easily allow private keys to be extracted from the wallet, instead they should allow funds to be transferred to a newly generated private key that is not considered a part of the wallet (though the wallet might want to remember them in case it becomes necessary to later sweep those coins back into the wallet).  You could think of the new private key as a wallet itself (or maybe like an envelope with cash in it).  With import/export, the risk of multiple wallets getting the same private keys in them and thoroughly confusing your typical user is too great.

Yes, I agree, very clever!  To get it to perform acceptably (since you'd be doing the actual mathematics for signing in script) you'd probably need a pretty sophisticated engine (i.e. one that JITs the functions)…but that could be left as an exercise for miners who would be strongly incentivized to run those scripts as efficiently as possible.

Can you elaborate why that's the case?  If true, I think it's very bad.  IsStandard() needs to be lifted at some point (probably when there is a suite of tests around each and every opcode that verify that it does the specified thing and leaves all execution context in a valid state).

Edit: by "lifted" I mean to not restrict scripts to a small set of well known ones…but limits on resource utilization by a script is definitely needed.

Actually, maybe it's really simple.  You could pull a satoshi in the sense that you're broadcasting most things throughout the p2p network, but I don't think you necessarily need all nodes to maintain a global view of the trust network…maybe it's as simple as this:

- a node (A) in the p2p network announces an order (not to be confused with the trust network)
- everyone hears about it and adds it to their order books
- another node (B) sees that they have a matching order (or someone places a matching order)
- node B announces that they've got a matching order to their trust neighbors
- the trust neighbors forward to all of their trust neighbors (other than B), appending info about the route back and fees, as well as the maximum size of the order that can be filled (if it's less that the total amount of the order…credit limits could make it such that some paths are only able to do a partial fill)
- original node starts hearing back about the matching order and various paths…it selects the path that is most ideal (able to fill entire order, has lowest fees, fewest hops in the trust network, etc)…it might execute along multiple paths if no single path is able to fill the entire order

Actually, the pool operators should investigate using p2pool themselves.  I think there are probably plenty of value add services that a pool operator could provide even when something like p2pool is out there (graphing, payout history, monitoring and alerting, etc).  P2pool should also lower the pool operators' costs substantially (not having to maintain as much server and bandwidth or do as much to defend against DDOS, etc).

I really like this idea…if a well known algorithm and tools to deploy it could be made open source, then people could apply some amount of funds to it.  Hundreds or even thousands of people putting a few hundred or thousand dollars each toward the task could earn them a small return while helping to stabilize the price of a bitcoin.

I did something similar with my Facebook friends…put a private key loaded with 1BTC on it and told them this was the virtual equivalent of leaving cash lying around in a public place.  I said the first one that can figure out what it is can have it.  I used the SIPA private key export format…it imports into blockchain.info's wallet just fine, but it doesn't sweep it.  I think mtgox will sweep it, but I'm not 100% sure.

Yeah, except Andy's neighbor isn't going to forget that Andy owes him money and he knows where Andy lives.

I don't think Ripple alone makes a lot of sense as a money system.  But the way it routes debt would be a great complement for bitcoin exchange (note: the intention of having and routing debt is just as a very short term way of recording and then settling the fiat side of a bitcoin trade).  When you deposit money with mtgox, you are trusting that they don't just run away with it.  Just like your example, mtgox could take as many deposits as they can and then just disappear and later setup a new site, mtgoxxed.com.

There are real world systems that work exactly like this, have been in place for centuries, and work extremely well.  Hawala is one such example.

Yes, but if what you say actually happened, all the people mining on those pools would drop out and switch to another pool (or mine solo).  Still, it would be quite disruptive (large scale attacks on pools have shown that it can have a very disruptive affect on network hash power).  A number of months ago someone came up with an idea that would allow individual miners in a pool to craft their own blocks (including any transactions they see fit, but the coinbase would deliver coins to the pool, not the individual miner).  P2pool is probably better though.  Good software on top of p2pool (with pretty graphs, reports and such) might help in attracting more people to it.

I like the idea of everyone issuing their own currency that works much like bitcoin (with the exception that the issuer determines the official chain of transactions instead of the mining network).  However, I don't think that's necessary to get a first version of a p2p exchange system up and running.  And a p2p exchange system is something I think is urgently needed.

Yes, the p2p communications network and credit network are separate things.  BGP was designed to decentralize routing on the internet.  I thought it might be a good thing to look at when figuring out how to do routing through the credit network (and do it in a decentralized manner).

I can't wait until we have a p2p exchange system.  I'm very intrigued to see how it evolves.  I suspect as adoption of bitcoin grows, people will simply stop bothering to settle up fiat debt, but instead use debts that are owed to them to buy bitcoin (which they then spend on various goods and services).  People might also just choose to leave debts outstanding (it's not really so different from having a bank account balance…which is also debt…it's just that your balance is with a trusted colleague, friend or relative instead of with a company).

If you belong to a pool, the pool will be putting a vote into the blocks it finds (well, most pools will).  You could think of the pool as being your representative for the purposes of voting on the protocol upgrade.  If you mine solo, each block you find is effectively is a non vote and may hinder the rollout of either solution (because a super majority of mining capacity is needed before the change will go forward).

The discussion in the mining forum and the upcoming transition to support p2sh is very interesting.  As a miner, you have a vote on such changes to the bitcoin protocol.  Your vote is proportional to the amount of mining capacity you control.  The mining pools are being asking to voice which of the proposals for p2sh they support by stating their preference in the blocks the create.  This got me thinking…as a pool operator, taking a position could be risky.  Miners in your pool that don't agree with your position might leave for another pool that was inline with their position.  So, one thing the pools could do is divide up their operations such that the miners could connect to one of several servers, each of which takes a different position on the issue at hand.  This lets the individual miners register their votes however they wish and they don't have to jump to another pool.  Good for the miners and good for the pool operator.

In the future, I would love to see mining hardware sold as a little solid state brick device for less than $100.  Just about everyone could run these miners to help secure the network and ensure they have a vote in its future direction.  Pools could make it simple for you to configure these devices.  They could also notify you about proposed protocol changes and let you register a vote by configuring your device accordingly.

I started thinking about this question when studying the proposals for p2sh implementations.  Here's how I would change it:

First, the scriptPubKey shouldn't be a script at all, it should just be a hash value (a bitcoin address).  All transactions would be a "p2sh" transaction.  Second, the scriptSig would not include the operations that setup the initial stack (the initial push operations that you typically see).  Instead, there would be another field that holds the values for the initial stack (which would typically just be a signature).  The scriptSig would also include an assertion at the beginning that verifies that the proper number of values are on the initial stack (this would prevent the hole that Gavin mentions that allows nodes to stick extra stuff at the beginning of a scriptSig).

You could probably mimic this in with bitcoin in the following ways:
1. Only allow 2 types of scriptPubKey transaction types (the traditional one, and one that verifies the code hash similar to the BIP-17 proposal)
2. Only allow PUSH operations before OP_CODESEPARATOR in the scriptSig
3. Add a bit of code after the code separator that verifies the number of items on the stack (note, I think this would close the hole that Gavin mentioned about pre-pending stuff to the scriptSig)
4. Add a new opcode for pushing a code hash onto the stack

So, a typical transaction would look like:

   scriptSig: [signature] OP_CODESEPARATOR OP_DEPTH [1] OP_EQUALVERIFY [pubkey] OP_CHECKSIGVERIFY
   scriptPubKey: OP_CODEHASH [20-byte-hash of {OP_DEPTH [1] OP_EQUALVERIFY [pubkey] OP_CHECKSIGVERIFY} ] OP_EQUAL

(note: OP_CODEHASH is a fictitious op code that computes the HASH160 of the code starting from the most recent separator and pushes it on the stack)

I agree (though I might suggest 64 or 70%…and maybe a month instead of 2 weeks for the activation).  It seems to me that people are compromising design out of an irrational fear of a chain fork.  If you get the overwhelming majority of people to add p2sh support (without actually activating it yet), you've then built a consensus that people want it.  If you then set a date for activation, you give everyone else that hasn't yet upgraded a chance to do so…and they will do it because the consequence of not doing so is that they end up with some unspendable coins in their wallet (it's also worth noting that the majority of coins in old wallets would actually still be usable on both chain forks long after the activation).  After activation, you can then begin the work needed to add support for these transaction in the user interface.