Topic: PULL request #748 : Pay-to-script-hash (OP_EVAL replacement) - page 2. (Read 12717 times)
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.
http://blockchain.info/p2sh
Quote
select count(*) from blocks where coinbase like '%/P2SH/%'
Quote
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.
http://blockchain.info/p2sh
Quote
select count(*) from blocks where coinbase like '%/P2SH/%'
Quote
select count(*) from blocks where coinbase like '%NOP2SH%'
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
Here's what I see:
What's with those "NOP2SH;p2sh/CHV"?
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"?
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.
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.
I looked... you're right. Perhaps he just looked for P2SH and saw your NOP2SH spam.
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.
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.
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 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.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.
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.I dout that! Dont' spread FUD.
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.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.
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 the bitcoind node.
I'm wondering if the following scenario is possible with P2SH:
"Ex: I want to buy a FPGA miner for 100 bitcoins.
I put 100 in escrow. The seller is required to put some amount, maybe 10% along with mine in to escrow. Range could be a sliding scale from 1% to 100% of the amount I put in escrow. Escrow now contains 110 coins.
You would have to be a pretty rich jerk to maliciously scam people repeatedly. Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions."
quoted from:
https://bitcointalksearch.org/topic/m.701749
"Ex: I want to buy a FPGA miner for 100 bitcoins.
I put 100 in escrow. The seller is required to put some amount, maybe 10% along with mine in to escrow. Range could be a sliding scale from 1% to 100% of the amount I put in escrow. Escrow now contains 110 coins.
You would have to be a pretty rich jerk to maliciously scam people repeatedly. Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions."
quoted from:
https://bitcointalksearch.org/topic/m.701749
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?
I think you're correct (I think it's just that changes like this make people nervous). What then is the next step to enable multi-sig? Is everything needed already in the scripting language? Is it just a matter of updating clients and miners to no longer reject such transactions?
Yes, the next step is to get miners and clients to recognize a new 'standard' transaction type that does multisig. BIP 11 describes them, they're already supported in git HEAD and by the p2sh code, and old miners and clients will recognize and validate blocks that contain OP_CHECKMULTISIG transactions.
P2SH is the best solution I've seen (or thought of) for moving redemption logic to the redeemer. I'm far more comfortable with it than the old OP_EVAL proposal. I think BIP 16 is a move in the right direction although I haven't thoroughly reviewed the pull request.
I only say something because there seems to be a lot of opposition in this thread. I figured a +1 from the gallery might be more valuable in that case.
I think you're correct (I think it's just that changes like this make people nervous). What then is the next step to enable multi-sig? Is everything needed already in the scripting language? Is it just a matter of updating clients and miners to no longer reject such transactions? I only say something because there seems to be a lot of opposition in this thread. I figured a +1 from the gallery might be more valuable in that case.
P2SH is the best solution I've seen (or thought of) for moving redemption logic to the redeemer. I'm far more comfortable with it than the old OP_EVAL proposal. I think BIP 16 is a move in the right direction although I haven't thoroughly reviewed the pull request.
I only say something because there seems to be a lot of opposition in this thread. I figured a +1 from the gallery might be more valuable in that case.
I only say something because there seems to be a lot of opposition in this thread. I figured a +1 from the gallery might be more valuable in that case.
Jump to: