Topic: Old P2SH debate thread - page 3. (Read 19708 times)

i kinda agree, can't see too much consensus in the dev team either so a little more brainstorming could be needed 

But not in the form of BIP 16.

After reading all of this discussion, I have now upgraded bitcoind to 0.5.2 on my miners (I mine solo), and encourage all other miners to do the same.  I will also encourage pool operators to upgrade and announce support for their pools.  Bitcoin needs this functionality now, not later.

Individual miners do not have a horse in this race.

Since most miners go where the money is (lowest fee/Highest return of BTC with a smidgen of reliability thrown in) they have no say. The pool op's will be deciding with whatever bitcoind they choose to run.

The right thing to do would be for pool op's to have their own poll for their pool's miners and then support what ever decision the majority chose. I doubt that will ever happen.

I personally would like the whole damn thing shelved for six months until there has been a proper amount of time to decide on a solution and to test it out on testnet.

There is way too much at stake for this to be rushed into the live chain/code.

If the other pool ops didn't agree with "my way", they certainly wouldn't be voting that was just because I said to. The only pool op I know of that plans to vote for BIP 16 is doing so because Gavin said to and he doesn't want to look into the details.

For most of us miners, it really does not matter. Despite the way we voted above, Luke-jr will win and it will be Bip-17 or what ever he comes up with. Luke-jr is lining up pool ops to go his way on it. Since miners go where the money is, there is little chance that miners will move from one pool to another just to encourage their pool's op to vote a certain way. Since pools have greater than 51% of the hashing power, they (the pool op's) will be deciding what which way it goes. And right now, it looks like Luke-jr has most of them in his pocket. Basically, it is Luke-jr's way or the highway and all others be damned.

In my opinion, you give up your right to vote when you mine at a pool. The pool can choose to hear you on what you'd like the pool's vote to be, but they don't have to. A miner should consider this before deciding to mine for a pool.

In order to regain your vote, you can choose mine with p2pool instead. This avoids the, for many, unacceptably long wait between finding blocks as a solo miner, and the variance in time in finding them.
The added work that a miner who works for p2pool will have to do, is run an instance of bitcoind (for collecting transactions) and also an instance of p2pool. So the main obstacle, compared to pooled mining, is having the proper amount of storage space (of sufficient quality - I suspect a USB stick isn't fast enough) for holding the block chain. Mining in this manner, your vote (which is determined by the bitcoind version you're running) will be heard only every time you find a block. So with 1GH/s of mining power you probably won't make your voice heard in time. But that doesn't seem unreasonable, since you have a very small part of the total hashing power (currently 1GH/s is ~0.01% of total hashing power) anyway.
If you want to make sure you vote with your hashing power at all times, joining a pool whose vote you agree with will achieve this.

Not sure if you are aware of this but as a pool miner YOU DON'T COMMUNICATE WITH THE BITCOIN NETWORK.  Thus your "vote" is worthless.  What is necessary (not just for this issue but any issue) is having 51% of HASHING POWER support a change.

So if you support change X but you mine at a pool which doesn't then .... your hashing power is "voting" AGAINST that change.

You have two options:
a) find out if your pool is supporting change X and if they aren't then go to another pool
b) solo mine


Of course they do.  There is no vote in the sense of a democratic election.  To make ANY change (this goes far beyond BIP 16) it must have support of 51% of the HASHING POWER.  When you mine in a pool your miner is STUPID.  It makes no decisions and thus can't "vote".  It will gladly hash whatever the pool gives it (rejecting P2SH transactions, attacking alt-chains, double spending bitcoin network, etc).


The miner isn't providing hashing power to the Bitcoin network.  The miner is giving hashing power to the pool operator to use as the pool operator sees fit.  This dynamic has always existed since the first pool was launched.  It is a large reason why there is concern over very large pools and the POWER it gives pool operators.

Votes are counted in the coinbase transactions that actually end up in the blockchain.  People that are mining through pools are working on blocks provided by the pool (usually), so they are working on coinbases provided by the pool.  Which means that it is the pool operators that are voting, not the pool users.

The pool operators should probably ask their users, or should tell their users which way they are voting so that pool users can change pools if needed.

If you are not actually directly submitting blocks that you generate and mine yourself, you are not really voting, and you don't need to set your node up one way or the other, since it won't matter at all.

I'm about to update my bitcoind appropriately to cast my "vote" which I shall not share here, what I do wish to share here is my concern for this quote un-quote voting process, Luke you made a point that Gavin is forcing anyone who has the latest bitcoind to vote in favor by default yet you are encouraging large pool ops to basically force a default vote upon on all of their miners by changing the pools bitcoind to not support gavins change , now admittedly I am reading/writing this from my phone so I may have missed something but in all fairness isn't this supposed vote meant to be by miners and not by pool ops?

I know for myself As someone who has mined extensively for almost a year  if I am given a chance to vote on a change in bitcoin as a miner - it should be my vote that is counted and pool ops should not have the ability to vote for me and for everyone else that mines with them.

Can someone please provide information on how the votes are counted, and how a pool op is able to vote for the miners that actually Provide the hashing power?

This is what I see in this thread:



My vote is for P2SH:

• There's no strong points against it.
• It's the only proposal so far that allows space savings in the future. Just imagine more and more complex unredeemed transactions saved in the chain: with P2SH is just a hash.
• Less potential of having a security flaw.

The only slight drawback I see is that you have to save the script somewhere to redeem it instead just a private key, but I don't think it's a problem if a good escrow negotiation scheme is implemented in the client (to avoid sending an escrow to someone who doesn't save the script).

edit: s/unredeemable/unredeemed/
Edit 2: It seems PIP 17 also allows the same space savings as PIP 16. Correct me if I'm wrong.

Good points about the primary use cases not being on windows.  At least they haven't managed to infest phones and servers like desktops.

I guess the one case I can think of that P2SH fits that doesn't work now is escrow without the escrow needing to do anything besides publish an address and sign a set of terms.  Something along the lines of, include a 1% fee to my address in a 2 of 3 transaction and I will arbitrate any disputes.  As it is now, the escrow has to provide an address for each transaction, then sweep the funds to a new multisig transaction.  In that case, they may as well just hold the funds like they do now.

That's why you should accept payment with a standard short address and then move your funds yourself to your safer "savings" account with a script as complex as you like.

It's pretty much already happened actually.
You should keep your wallet in your pocket, and for the vast majority of people that is not a Windows machine.
You should keep your "savings account" in a safe place, probably a "bank" in the cloud that'll one day even pay you some interest, and that also most likely means anything but a Windows machine.

I disagree that the fee issue is a small one.  Fees are small now, but this may not continue to be the case.  In very complicated transactions, the existing methodology can lead to humongous addresses and much larger transactions.  Dealing with various address lengths will be confusing to users, and the existing scheme has the incentives backwards.  Why should I pay more for your security?  The urgency comes from the fact that we need to make multisig very easy to use so that windows users can have a hope of not having their bitcoins stolen.  Without this, bitcoin is dead in the water... at least until the Windows monoculture breaks apart because of it's own inescapable design vulnerabilities.  I wouldn't count on that happening soon though.

I know addresses are hashes. I just always thought that the relevant part of a transaction size was the public key of each input, not the hashes of the ouput or the script.

Concerning formats, is it impossible to have an unique, generic format allowing the receiver to send the full script plus any hashes or generic data to the sender, in the form of a big string? Defining only such format once should be enough.

I understand that it would be better if the receiver pays the fee for the inclusion of his script, but, honestly, how expensive are transactions right now anyway? They are very cheap, this extra fee price can't be relevant to the point of stressing people the way we see in this thread.

TL;DR: I don't see any urgency in this change.

There are no addresses.

Your wallet is a list of private/public key pairs.  When you want someone to pay you, you take a hash of a public key, then give them the hash.  To redeem that transaction later, you need to provide the same public key that created the hash, and prove that you know the private key that corresponds to that public key by signing the transaction with it.

The minimum amount of information needed to create a secure transaction to a single keypair is a single hash.  We then embed that hash into a string using special rules, and we call it an address, but it never exists in the bitcoin system as anything but a hash.

Now, say you want to create a transaction that can be redeemed by either of two different keypairs.  How much information do you need to create that transaction?  You need two hashes, one for each key, and then you can create a script that can be satisfied by either of them.

It gets worse.  If you want to have a (A and B) or C system, you need to provide hashes of all three keys.  If you want a (N of M) system, you need to provide all N hashes.

And that isn't all.  Not only do we need to provide 3 key hashes for (A and B) or C, but we need to standardize the interchange format so that you can create an address that includes the three hashes and the relationship between them.  And we need a format for (2 of 3), and another one for (3 of 4), and in general we need a format for every system.  The CEO and CFO can spend if they agree, but otherwise either of them requires a majority of keys from the board of directors?  New format.  Any junior officer can spend with the consent of either the CEO or the CFO and the consent of at least one board member?  New format.

With P2SH, the addresses that you give out are the size of a single hash, regardless of what lurks beneath.

The redemption transaction grows, since it will include the script in addition to all of the needed public keys, and all of the needed signatures.  But, that is a problem for the person spending from the complex transaction, not the person spending to it.

It can't be only the larger address that's provoking all this discussion... As far as I know, the output addresses are not the relevant part of a transaction, when talking about size. It is the public key attached to each input that make transactions large, isn't it? A transaction with 5 inputs and 1 output is much larger than a transaction with 1 input and 5 outputs.

Maybe the script that the sender must attach to its transaction have to be much larger than the standard script? Is that it?

It isn't a solution.  It is completely nonviable.

I use multi-sig so I (not you) gain the advantage of higher security.
My address is longer so when YOU (not me) transfer funds You (not me) pay the higher fees.

I get all the benefit you get all the fees.  Also the fees can be significantly more and rise w/ more complexity and security (for example not just 2 sigs but 3,4,5).

So you pay more and more and more in fees and I get more and more and more security.  

Multi-sig will have a very limited usefulness (mostly academic) without a change to protocol.  It would be like pricing gas on the inverse of how large your car is and wondering why fuel efficiency sucks.

Actually this is possible with any multisig scheme, even without special redeeming scripts.

The issue isn't "slightly" larger transactions.  Complex transactions can be much larger than normal transactions, and it puts the burden on the wrong party.  See this post.