PULL request #748 : Pay-to-script-hash (OP_EVAL replacement)

[Syke]

I run two kinds of nodes, a bitcoind node and a phoenix-miner node. Which one, or both, of these nodes needs to be updated to support P2SH?

Just he bitcoind node.

Very few miners still run bitcoind nodes. So all you need to do is get the top 2 or 3 pool operators to switch to the new code and you've secured the 55%. Are any of the pools on board so far?

[Luke-Jr]

I run two kinds of nodes, a bitcoind node and a phoenix-miner node. Which one, or both, of these nodes needs to be updated to support P2SH?

Just he bitcoind node.

Very few miners still run bitcoind nodes. So all you need to do is get the top 2 or 3 pool operators to switch to the new code and you've secured the 55%. Are any of the pools on board so far?

Thankfully, the majority of big pools are opposing BIP16.

[finway]

I run two kinds of nodes, a bitcoind node and a phoenix-miner node. Which one, or both, of these nodes needs to be updated to support P2SH?

Just he bitcoind node.

Very few miners still run bitcoind nodes. So all you need to do is get the top 2 or 3 pool operators to switch to the new code and you've secured the 55%. Are any of the pools on board so far?

Thankfully, the majority of big pools are opposing BIP16.

I dout that!  Dont' spread FUD.

[kjj]

I run two kinds of nodes, a bitcoind node and a phoenix-miner node. Which one, or both, of these nodes needs to be updated to support P2SH?

Just he bitcoind node.

Very few miners still run bitcoind nodes. So all you need to do is get the top 2 or 3 pool operators to switch to the new code and you've secured the 55%. Are any of the pools on board so far?

Thankfully, the majority of big pools are opposing BIP16.

I dout that!  Dont' spread FUD.

Just by grepping the blk0001.dat file, I see 4 votes for, and 8 votes against.  I'm pretty sure that means that Luke is still against it, one person is for it, and the entire rest of the mining world is uncommitted.

[Luke-Jr]

Just by grepping the blk0001.dat file, I see 4 votes for, and 8 votes against.  I'm pretty sure that means that Luke is still against it, one person is for it, and the entire rest of the mining world is uncommitted.

Just wondering, where do you see any votes for BIP16? I see 602 votes for BIP12/OP_EVAL, 8 against BIP16, and 4 for BIP17/CHV. But I was commenting on verbal discussions with other poolops.

[notme]

Just by grepping the blk0001.dat file, I see 4 votes for, and 8 votes against.  I'm pretty sure that means that Luke is still against it, one person is for it, and the entire rest of the mining world is uncommitted.

Just wondering, where do you see any votes for BIP16? I see 602 votes for BIP12/OP_EVAL, 8 against BIP16, and 4 for BIP17/CHV. But I was commenting on verbal discussions with other poolops.

I'm guessing from the fact he said this, but: in the blk0001.dat file.

[Luke-Jr]

Just by grepping the blk0001.dat file, I see 4 votes for, and 8 votes against.  I'm pretty sure that means that Luke is still against it, one person is for it, and the entire rest of the mining world is uncommitted.

Just wondering, where do you see any votes for BIP16? I see 602 votes for BIP12/OP_EVAL, 8 against BIP16, and 4 for BIP17/CHV. But I was commenting on verbal discussions with other poolops.

I'm guessing from the fact he said this, but: in the blk0001.dat file.

Yeah, that's where I got that. There is no "/P2SH/" in blk0001.dat...

[notme]

Just by grepping the blk0001.dat file, I see 4 votes for, and 8 votes against.  I'm pretty sure that means that Luke is still against it, one person is for it, and the entire rest of the mining world is uncommitted.

Just wondering, where do you see any votes for BIP16? I see 602 votes for BIP12/OP_EVAL, 8 against BIP16, and 4 for BIP17/CHV. But I was commenting on verbal discussions with other poolops.

I'm guessing from the fact he said this, but: in the blk0001.dat file.

Yeah, that's where I got that. There is no "/P2SH/" in blk0001.dat...

I looked... you're right.  Perhaps he just looked for P2SH and saw your NOP2SH spam.

[kjj]

Yeah, I just grepped out p2sh and saw 8 NOP2SH and 4 p2sh.  If the 4 strings I found are actually for BIP17 instead of BIP16, it doesn't change my conclusion in the least.

[chrisrico]

Here's what I see:

Code:

$ strings .bitcoin/blk0001.dat | grep -i p2sh
NOP2SH
NOP2SH
NOP2SH
NOP2SH
NOP2SH;p2sh/CHV
NOP2SH;p2sh/CHV
NOP2SH;p2sh/CHV
NOP2SH
p2sh/CHV

What's with those "NOP2SH;p2sh/CHV"?

[Luke-Jr]

What's with those "NOP2SH;p2sh/CHV"?

Voting against BIP16 (which uses "/P2SH/") and for BIP17 (CHV).

Code:

strings ~/.bitcoin/blk0001.dat|grep '\/P2SH\/\|NOP2SH\|OP_EVAL\|p2sh/CHV'|tr ';' '\n'|sort|uniq -c|sort -n

[piuk]

http://blockchain.info/p2sh

select count(*) from blocks where coinbase like '%/P2SH/%'

select count(*) from blocks where coinbase like '%NOP2SH%'

[finway]

http://blockchain.info/p2sh

select count(*) from blocks where coinbase like '%/P2SH/%'

select count(*) from blocks where coinbase like '%NOP2SH%'

Can you make a pool list for P2SH and NOP2SH,
I guess miners should know what their pools are voting for.

I know Eligius support NOP2SH, and i leave that pool.

[DiThi]

If a redeeming P2SH transaction (or any transaction for that matter) is validated by the network (and I know it hasn't been spent yet), do I need to keep the "in" part of the tx or can I scrap it out? If I understand the protocol, I can left it out; in that case I fully support P2SH as the space savings in the future will be HUGE.

[kjj]

If a redeeming P2SH transaction (or any transaction for that matter) is validated by the network (and I know it hasn't been spent yet), do I need to keep the "in" part of the tx or can I scrap it out? If I understand the protocol, I can left it out; in that case I fully support P2SH as the space savings in the future will be HUGE.

Well...  If you validate it yourself, and can be pretty sure that your database won't get corrupted or attacked, you could toss it, maybe.  I would need to read the chaining rules again to be sure.  But I would be very reluctant to prune that aggressively, even if the blockchain growth somehow manages to severely outpace the size growth of cheap hard drives.

[Gavin Andresen]

Once transactions are validated and buried "deep enough" in the blockchain you can forget their inputs, because the inputs are only needed for validation.

... although SOMEBODY on the network should remember them, in case I-don't-trust-anybody nodes want to validate the entire blockchain.

[DiThi]

Once transactions are validated and buried "deep enough" in the blockchain you can forget their inputs, because the inputs are only needed for validation.

... although SOMEBODY on the network should remember them, in case I-don't-trust-anybody nodes want to validate the entire blockchain.

That's exactly what I thought.

[Steve]

Once transactions are validated and buried "deep enough" in the blockchain you can forget their inputs, because the inputs are only needed for validation.

... although SOMEBODY on the network should remember them, in case I-don't-trust-anybody nodes want to validate the entire blockchain.

This is one of the things I find very cool about bitcoin.  You can have a kind of rolling history.  Only a relatively small number of nodes will need to retain the full history (though more than one just in case some bad fate befalls it).  And this is sufficient since anyone at any time could download and verify that entire history from the beginning.  All the other nodes just maintain an in motion picture of the network, allowing ancient history to expire off the back end.

Another related thought that I've had is that transactions with more outputs than inputs should somehow cost more since they increase the overall number of transactions that nodes need to retain for verification purposes (and transactions that have a fewer number of outputs than inputs decrease the number of transactions that the network needs to retain).

[MoonShadow]

Another related thought that I've had is that transactions with more outputs than inputs should somehow cost more since they increase the overall number of transactions that nodes need to retain for verification purposes (and transactions that have a fewer number of outputs than inputs decrease the number of transactions that the network needs to retain).

Be careful with such artificial transaction fees, because it's not really the number of transactions that a given transaction begets that is the problem, but the total bandwidth consumption and computational demand upon the network.  In the near term, a single transaction with numerous outputs is more efficient most of the time.  This is because, with a transaction fee that is higher simply because of the actual demands of resources, a send-to-many transaction is less burdensome in the short term, and the longer term results of future transactions are unpredictable.  As an example, it would generally be vastly less resource intensive for a large corporation to use send-to-many transaction for weekly payroll then to produce a standard two-output transaction for each employee.  In either case, however, what the employees do with those transactions next are not dependant upon how they are paid.  Such large send-to-many transactions take up a lot of space and bandwidth, but remain relatively efficient if compared to the space and bandwidth that those same outputs would have produced individually.  We can assume that the send-to-many transactions will have a much longer 'lifespan' in the blockchain before they can be pruned, but we can also assume that some percentage of the individual transaction would have lasted as long.

[piuk]

Can a pool operator please mine a block containing a P2SH transaction on main net and redeem it. I'd like to a do some P2SH preperation, but don't have Testnet setup.