Topic: BIP 16 / 17 in layman's terms - page 15. (Read 38982 times)

I can't say I've entirely understood how BIP16 or BIP17 work (but I'm not completely ignorant of them); however:

• BIP16 feels "hackish"; that is not to say BIP17 is therefore "the one", and it might be that an as yet unwritten BIP18 is the answer.  That being said, there is an awful lot of "hackish" already in the scripting part of bitcoin... OP_CODESEPARATOR makes me uncomfortable anyway.
• The inertia needed to be overcome for a change, suggests that changes should be made very judiciously.
• Deadlines are for closed source software.  The most uncomfortable part about this for me was the sudden announcement of a deadline.

In general: I think if there is controversy, then the answer is not to rush it is to delay.  But  then again... I'm not the project lead am I? 

To me this is not about which solution we use or when we apply it, we can keep going for a couple of months more if that is required. Multisig is an important feature but there is now something even more important going on which is the centralization of the mining network. This issue has proven that we actually have a much bigger problem right now.

This problem will never entirely go away but what we can do is make it better, a lot better. We can start by reducing the power of Deepbit and other large pools. Join me in the biggest boycott Bitcoin has ever seen. This can be done and this HAS TO BE DONE.

Read more here: https://bitcointalksearch.org/topic/join-me-in-the-biggest-mining-pool-boycott-bitcoin-has-ever-seen-61219

Have you tested the 0.5 (or whatever) migration to qt? It's a pretty slick interface.

Gavin, do you know what he objects to in P2SH and/or CHV?

why are the bip17 addresses longer than BIP16?
from what i understand both need to contain only the hash of the {script+pubkeys}.

If there is any risc of double spending could we make a deal with the exchanges.
Maybe they could email every customer telling them to upgrade their clients and shut down for 2 days (like in a weekend) during a risky period.

I don't like to upgrade. I really appreciate the work that goes into new features and versions, but sometimes things go wrong and I want to stay months behind. I certainly see the value in the improvements being discussed, but what I need is working and my main priority is keeping it that way.

If you really want people to adopt an updated client. As discussed in another thread, put some bit penny making capability back into it.

Then sell it. Hey, you might make 0.0000001 BTC every now and again.

The amount really doesn't matter. It is the idea that upgrading and running a node will make you something. The miners and Pools could care less about it, BUT the people with just -qt would.


There are currently about what? 30K nodes?  Hell, you could pay people to upgrade. Every one gets 0.01 BTC to upgrade. That would cost about: 300 BTC

You might even get donations towards such an endeavor.

I feel like I know a decent amount about the workings of Bitcoin - enough to comprehend this explanation but not come up with it - and I agree.


I think the concern is that this is not likely to happen. I saw a figure somewhere that 70% of clients are running a version lower than 0.5.

What about a staged update like when the default fee changed 0.3.22/23?

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.

Frankly, I'm not too disturbed by that.  Saddened, yes, but if you're enough of an idiot to mine at DeepBit with your GH then you deserve to lose money.  What I'm more concerned about is the effect that these idiots have on the security and the future of the Bitcoin network as a whole.

I'm completely willing to believe that implementing an "aware" blockchain is not easy. I also understand that awareness would lead to attack methods which try to manipulate awareness. However, I'm confident that awareness would open the door for a number of useful features (spending limits, blockchain-based derivatives, and others). I also believe that potential attack problems could be worked out eventually. I don't want to get into a discussion about how the features would work here. Instead what I am asking for is a long-term position on awareness.

It is a long-term goal of the development team to make the bitcoin blockchain aware?

You're right that it's possible in theory. However, we're talking about quite a few major changes that would have to be done.
1) Transactions are not aware of the blockchain at all. For this, they'd at least need to be made aware of the timestamp of the block they were put in. All such blockchain-aware transactions would need to be locked for at least 100 blocks after they are included in the chain before being spendable again. Even that might not be enough, in theory, although we'd likely be able to get away with it in practice.
2) Transactions would need to be aware of the output of the transaction in which they are redeemed. This is needed to find out how much is being spent and put conditional checks on it.

Neither of these are easy tasks. They might not ever be safe, either.

Yea, probably true. But nothing wrong with a little Pep Rally.

Information that Gavin provided could be read by almost anybody, (that can read), and decide for themselves now. Can you ask anything more. He obviously feels strongly for this issue. I put a little more faith in him and his decisions than others I guess.

I think generally speaking, anyone mining on Deepbit is not going to be reading this thread or agreeing with it. 

This post is really appreciated. All one could say is that Gavin, the lead developer, needs help in cranking up pressure on a Pool Operator to switch.

So it boils down to:

Do you think Gavin is leading the community in the right direction?

Do you think a pool operator should wield so much power?

It would be assumed, that this community does not like entities having to much power.

So how will this community respond to Gavin's plea for help now that the issues are laid out and explained for the majority of users?


So lets crank up the GH/s and show everybody where the power is. Point those miners (temporally) to another pool, or solo mine for a bit. Lets push those rigs up to 13 TH/s or more.

Go, Go, Go, OP_TakeBack

VOTE, VOTE, VOTE.

Ya, spamming always helps to bring people to your way of thinking... especially when you
do it in such a calm and non-arrogant manner as you have shown...  lol


oh the irony... 


Death to all fanatics! 

Why add in a web-based service since it is not necessary in theory? Does it have something to do with the code lacking awareness of the blockchain? Are the core code modifications necessary to remedy this too difficult?

In my view, there should be a plan where txns with time-dependent spending limits without help from a third-party service become possible at some point. Maybe this is too tough to achieve right now, but it seems like a cleaner, more convenient, and intuitive solution to me. Time-dependent spending limits have such prevalence in consumer banking that I think people will be uncomfortable without them.

Third party service providers can cause lots of problems. Many people are already quite uncomfortable with them. "Don't lose two things at once" strategies also make things quite complicated. People get worried by stuff that is complicated. Who wants to spend the mental energy to deal with multiple methods of authentication simultaneously? I'm not saying I don't see value-added in these proposals, it is just that they do not seem like permanent, first-best solutions to me.

Should we view these proposals as temporary fixes?

Yes, this actually would be possible. To do what you asked, specifically, you would create 2-of-3 multisig transaction addresses where the third key is owned by a third party (likely web-based) service. When you lose access to one of your two private keys, you could use this service to recover your funds at whatever predetermined rate you chose. Such a service could require a login, or not, depending on the security you desire.

Alternatively, you could put the third private key in a safe and you would have immediate access to all of your funds should you lose a private key. Of course, this is no different than just storing a backup of both keys, but it's a little neater.

That's why it'll be encouraged for people to use 2-of-3 transactions instead of 2-of-2.

I am a programmer, and my boss sometimes makes me re-work the code i write for "no reason" only because it looks and feels cleaner his way.... needless to say this can be a piss off, but in the end it really does produce clear strong code.

I hope the dev team isn't in too much conflict.

I dont understand the problem, but i will say this, i really dont care how long it takes as along as its "perfect" once its done. this isn't some web-app. Its the core for a brighter future  

keep up the good work!

Cheers