Pages:
Author

Topic: The Truth behind BIP 16 and 17 (important read) - page 3. (Read 8605 times)

staff
Activity: 4284
Merit: 8808
Quote
These BIPs would reduce the size of unspent transactions, no matter how complex, to the lowest safe size.
never understood why that would happen, the bips just move the large script from the output to the input
unspent blocks have both
inputs of unspent transacions can be pruned? (afaik pruning is actually not supported by the client)
I thought the merkle tree contained hashes of transaction and not hashes of separate inputs/outputs...

Pruning in this case doesn't actually have too much to do with the merkle tree here.  Once a transaction has been spent, and the spend is burred in your chain, you'll never need any of it's inputs (or the outputs they spend) again and so you can save the storage.   (the connecting tree isn't relevant, because you've already validated the transactions for yourself, you don't need to continually prove to yourself that you weren't lying to yourself)

When you get a transaction you don't know when it will be spent— or _if_ it ever will be— maybe you'll need to store its outputs for 6 months or 60 years.   But you do know that you'll be able to forget about its inputs as soon as they're burred deep enough in the chain.   So given equal total sizes we should strongly prefer to put more of the bytes in the script signature (the input side).

The current reference software doesn't take advantage of this... but the chain is only a gigabyte now.  The storage requirements from these decisions have an impact for basically forever.

staff
Activity: 4284
Merit: 8808
Ultimately we seem to be fracturing the community (and potentially the blockchain!) just for the sake of convenience. If complex transactions require 70-character addresses, then so be it. To risk permanent harm to the system to avoid them just seems short-sighted.
Agreed!
There is no risk of permanent harm.
Besides the split of the chain...

Any split would resolve, assuming a simple majority of the future hash power was enforcing the new rules. It's not an unresolvable split risk.

70 characters is more like the minimum address length for a non P2SH secure wallet address.  An actual complex transaction might be more like 1000-2000 characters.

I gave genjix a pretty nice list of reasons why P2SH is important other than the long addresses. Unfortunately, he decided to only quote from people saying negative things about P2SH in his post.  Here is what I wrote to him:

Quote

...  No it's not a mistake.  P2SH _prevents_ needing long addresses.

Lets unpack the acronym "pay to script _hash_".  Hashes only need to
be 128-256 bits in size or so to have acceptable security, so you
don't need something longer than that for paying to a hash.

Note that gavin is saying 70 characters, not bytes.

Without some form of P2SH then only way for you to make a personal
choice of asking people to pay to a two-factor protected account or
two a multiparty trust that manages the finances of an organization
is using some form of "P2S", pay-to-script.

In other words, you'd have to have an address that encodes a full
script specification for the sender to pay to,  instead of just
encoding its hash.  As a result these addresses would be much longer
(and potentially very long).

The minimum size of a two address involving encoded script would be on
that order, but they get bigger quite quickly if you add more options
to the script (actually 70 sounds quite small, it should be more like
100 for a minimum two pubkey script).

In addition to the unworkability of very long addresses as described
by gavin (amusingly I am unable to copy and paste the quoted example
in one go) a P2S solution has several problems which you might
consider more or less important:


(1) They are highly vulnerable to invisible substitution.  E.g. I can
trivially take a P2S address, change one or two characters and get a
script which is redeemable by anyone.  With P2SH you have to do
computation which is exponential in the number of unchanged digits to
get a look alike address.

(2) The sender is fully responsible for fees related to the enlarged
transactions. Even if _you're_ willing to take the txn-processing time
and fee burden of a 30 person joint trust address,  random e-commerce
sites will not be and will randomly reject your addresses.

(3) They create another input vector for non-trivial data which must
be inspected and validated, potentially presenting an attack surface.

(4) They leave the complicated (long) release rules in the transaction
outputs.  When a transaction is mined we can't be sure if it will ever
be redeemed. The outputs are unprunable.   In a future world where
many nodes prune output space is far more important than input space
and it would make sense to require more fees for it because we're
never sure how long it would need to be stored (making it an
attractive target for someone who wants to make Bitcoin unusable by
spamming it with worthless data).  P2SH reduces output sizes to the
absolute minimum without inflating the total data size.
newbie
Activity: 28
Merit: 0
Quote
These BIPs would reduce the size of unspent transactions, no matter how complex, to the lowest safe size.
never understood why that would happen, the bips just move the large script from the output to the input
unspent blocks have both
inputs of unspent transacions can be pruned? (afaik pruning is actually not supported by the client)
I thought the merkle tree contained hashes of transaction and not hashes of separate inputs/outputs...
full member
Activity: 238
Merit: 100
Ultimately we seem to be fracturing the community (and potentially the blockchain!) just for the sake of convenience. If complex transactions require 70-character addresses, then so be it. To risk permanent harm to the system to avoid them just seems short-sighted.

Agreed!


There is no risk of permanent harm.


Besides the split of the chain...
sr. member
Activity: 249
Merit: 251
To risk permanent harm to the system...

There is no risk of permanent harm.

And the blockchain bloat? That almost seems like a distraction. Complex transactions are going to take up extra space in the blockchain; arguing over where and when the bloat occurs seems pretty academic too.

You forget that completed transactions can be pruned. They can and will be deleted by many miners after the bitcoins are spent further. Unspent bitcoins can not. They are kept by all miners forever. These BIPs would reduce the size of unspent transactions, no matter how complex, to the lowest safe size. It is not merely academic. It is significant.
staff
Activity: 4284
Merit: 8808
Quote
I am not sure what has changed since this time and

Nothing changed. Thats the point. You didn't correct the highly exaggerated an "political" representation which I  (and _many_ other people) pointed out was confusing and misleading.

You've continued with your misrepresentation here with your selective bolding in your quotation.  For example, I'd spent some time making what I thought was a pretty clear and non "political" explanation of the subject in #bitcoin-mining, which I recommended you borrow from.  But you've bolded my commentary in a way which presents a false description of my position.

Please completely unbold my comments or completely bold them. I consider it unacceptable that you skipped over things like "< gmaxwell> genjix: explaining what the P2SH stuff does is fantastic. People seemed to like it when I explained it in #bitcoin-mining the other day."  but then bold the "but" part of the statement that I said next.

You make it sound like you're somehow more neutral than anyone else. This is nonsense, you might be less informed than other people— but that doesn't make you more neutral.  I gain _nothing_ from any of the particular proposals, nor did I write any of their code.  (I've done more testing work on BIP17 (the proposal that I don't prefer) than BIP16, simply because Luke needed help with testing and asked for it).  But somehow you paint me as a partisan? thats weird to me.



legendary
Activity: 980
Merit: 1004
Firstbits: Compromised. Thanks, Android!
Thanks for the article, genjix. Definitely cleared some things up for me.

My conclusion (for what little it's worth:)

BIP 17 seems to clearly be a superior method coding-wise. BIP 16 seems like overkill.

But my vote, in part made by continuing to run a pre-Qt client, is for neither.

Ultimately we seem to be fracturing the community (and potentially the blockchain!) just for the sake of convenience. If complex transactions require 70-character addresses, then so be it. To risk permanent harm to the system to avoid them just seems short-sighted.

I also don't buy the whole concern about who pays transactions costs... considering the recipient can charge whatever he wants for whatever he's selling, that point is more academic than anything. And the blockchain bloat? That almost seems like a distraction. Complex transactions are going to take up extra space in the blockchain; arguing over where and when the bloat occurs seems pretty academic too.

I'm thinking Tycho made the right call here.

Note: Again, I'm just stating my perspective on all this; no insult to anyone intended.
newbie
Activity: 28
Merit: 0
Latest code = from git, to-be-0.6.

Normal people don't read "from git" as "latest code" even if it is technically true. Just sayin'.
note the "code" in latest code - not "release"
but yeah if you dont mess with CVS yourself , you probably won't notice Smiley
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
I think you did a great service to our community with your effort that you put into your article, so thank you very much!

+1
legendary
Activity: 1078
Merit: 1003
I think you did a great service to our community with your effort that you put into your article, so thank you very much!
legendary
Activity: 1232
Merit: 1076
I think it's unfortunate that both Tycho and Genjix are both spreading overt misinformation here in order to create controversy.  (Tycho making insane claims that testing BIP17 is impossible, Genjix with falsely describing this as a "vote", claiming that people don't want you to know about this open and widely discussed matter, the over the top subject line)

The kind of hysteria being promoted here is a very big disincentive to contributing technically to bitcoin. I encourage everyone to be patient and thoughtful and recognize that bitcoin can not survive if people with powerful media presences are able to disrupt development and exhaust the developers at will.  Discussion is great, but consider whos interest panic is well aligned with: Certainly not the interest of the Bitcoin using community. Don't let your emotions be manipulated.

Here is the list of developers i contacted for feedback before publishing:
- justmoon
- jgarzik
- gavin
- roconnor
- gmaxwell
- sipa
- wladimir
- Mike Hearn
- luke-jr

I got help with copy-editing and feedback from the following people:
- luke-jr
- justmoon
- tcatm

Quote
21:31 < genjix> gmaxwell, roconnor: i'm putting this out tomorrow if you want to give some thoughts on this: http://privatepaste.com/c8b40edb00
21:31 < occulta> also that wiki is very old, relating to client 0.3 *
21:31 < BlueMatt> "minimum TX fee for new transactions reduced to 0.0005 BTC."
21:31 < BlueMatt> its still true
21:31 < genjix> whether it captures the entirety of the EVAL, P2SH, CHV discussion
21:32 < gmaxwell> genjix: ugh. that makes me feel sick. Representing it as a vote is simply misleading.
21:32 < gmaxwell> It's not that kind of 'vote'.
21:32 < genjix> what would you call it then?
21:32 < gmaxwell> I give up.
21:32 < genjix> it basically is, and this is informing the voters to ensure they make a better decision

21:33 < gmaxwell> This process is all broken.
21:33 < gmaxwell> No, it's pissing all over the walls.
21:34 < gmaxwell> genjix: The reason for the coinbase tags is _NOT_ to conduct a vote (if it were, I suppose the software would also tally the result) but simply because there needs to be a hash power measurement because the new rules are only safe if the majority of all future hashpower enforces them.
21:34 < gmaxwell> genjix: there is also no way this is going active on Feb 15th now. So the representation of that is creating false urgency. Though I suppose its up to gavin to announce moving that back.
21:35 < gmaxwell> genjix: you're also characterizing this as gavin vs luke, which is a complete load of rubbish.
21:35 < Joric> are there any pure-python parsers for berkeley db? my google skills are failing me
21:35 < Joric> or at least format documentation
21:36 < BlueMatt> bdb parsers are impossibly hard to find
21:36 < genjix> i asked for feedback to write a better article and you're simply attacking me
21:36 < Joric> yeah )
21:36 < BlueMatt> there may be a bdb wrapper
21:36 < genjix> Joric: pybsbdb
21:36 < Joric> want to get rid of bsddb dependency, gae doesn't have it
21:36 < genjix> it is a good bdb wrapper
21:36 < BlueMatt> genjix: his feedback is that there should be no article
21:36 < BlueMatt> (and I agree)
21:37 < genjix> yes let the mere users fester in ignorance
21:37 < gmaxwell> genjix: sorry. This whole "dispute" thing has basically pushed my interest in contributing to bitcoin technically negative.

21:37 < Joric> etotheipi_, do you need pure python bdb parser aswell?
21:37 -!- graingert [~graingert@unaffiliated/graingert] has joined #bitcoin-dev
21:37 < genjix> i'm only trying to inform people how bitcoin works (if you look at my past articles)
21:38 < gmaxwell> And I'm irate because I feel like I've invested time in something that now has net negative return (it stresses me out). I shouldn't be taking that out on you.

21:38 < Diablo-D3> [04:35:13] genjix: you're also characterizing this as gavin vs luke, which is a complete load of rubbish.
21:38 < Diablo-D3> yes really
21:38 < Diablo-D3> because if there was some sort of cage match between the two
21:38 < Diablo-D3> gavin would be going in dry.
21:38  * BlueMatt suggests you leave authors out of the article
21:38 < gmaxwell> genjix: explaining what the P2SH stuff does is fantastic. People seemed to like it when I explained it in #bitcoin-mining the other day.
21:38 < BlueMatt> (as its irrelevant)
21:39 -!- Ahimoth_ [[email protected]] has joined #bitcoin-dev
21:39 -!- Ahimoth [[email protected]] has quit [Disconnected by services]
21:39 -!- Ahimoth_ is now known as Ahimoth
21:39 < gmaxwell> genjix: inviting people into taking positions over technical minutia which they won't be qualified to really have an opinion on without a lot more understanding than you can put into the article... meh.
21:40 < BlueMatt> esp when their opinion wont have any effect on the outcome aside from making the pissing match bigger
21:40 < gmaxwell> BlueMatt: exactly.

21:40 < BlueMatt> (kinda doubt any will switch pools)
21:40 -!- wirehead [[email protected]] has quit [Ping timeout: 260 seconds]
21:41 < gmaxwell> The solution to this needs to be consensus of the interested and compentent. Not a bigger dispute decided by whomever can convince more people to come to their side.
21:41 < genjix> i'd rather people have a say in the matter even if it makes life tougher for developers to explain their decisions.

21:41 -!- erle- [[email protected]] has joined #bitcoin-dev
21:41 < gmaxwell> The latter case has no winners.
21:41 < genjix> these kinds of decisions should always be deliberately difficult and hard
21:41 < BlueMatt> what?
21:41 < BlueMatt> we should make all of our decisions harder?
21:42 < genjix> no big decisions to the protocol or system
21:42 < genjix> implementation decisions - fine.

21:42 < BlueMatt> but we should make the big decisions harder on ourselves?
21:42 < gmaxwell> genjix: So what, some statemen with a prominant website gets people all upset over their half understandings of some technical details and they go against the decisions of the people who are actually spending time to work on the software? You know what the outcome of that is? The people working on it _leave_, and the only people left to make additions are the people who are either too clueless or lazy to contribute now, and luke.
21:43 < BlueMatt> by making the decisions into huge pissing matches where politics takes on more importance than technical arguments?
21:43 < genjix> umm hello?
21:43 < genjix> it's already that way
21:43 < gmaxwell> genjix: when we had the discussion about what would become BIP16 the discussion ended without anyone objecting to that decision. (except luke, who'd left early)
21:44 < genjix> sure. but i feel a bit apprehensive about telling our users this is how it will be, you have no say and then giving them the finger
21:44 < BlueMatt> if they feel like really getting involved, great
21:44 < BlueMatt> they can come in here and chat, and post on the forum
21:45 < BlueMatt> s/forum/mailing list/
21:45 < gmaxwell> genjix: your article is also full of factual errors. For example, the maximum recusion depth was always part of OP_EVAL. roconnor's important contribution was realizing that the implementation was buggy and the limit didn't work.
21:45 < BlueMatt> (freudian slip)
21:45 < gmaxwell> genjix: I don't think any user would be opposed to P2SH as it is— when I explained it in bitcoin-mining the other day people were very excited about it.
21:46 < gmaxwell> genjix: the reason to oppose it is just the risk of unknown bugs— a very important concern, but not one that causual users are qualified to reason about, unfortunately.
21:47 -!- graingert [~graingert@unaffiliated/graingert] has quit [Remote host closed the connection]
21:47 < gmaxwell> genjix: if you think this needs to be delayed in order to address that, then great— but where is the plan that converts extra time into extra software quality?
21:47 < genjix> i dont have a viewpoint on this.
21:47 < genjix> if p2sh, chv or none comes along then i'll implement them.
21:47 < BlueMatt> so why are you encouraging others to make one?

21:48 -!- b4epoche_ [[email protected]] has joined #bitcoin-dev
21:48 < genjix> my experience is in software architecture not protocols, so i'm not commenting
21:48 -!- b4epoche [[email protected]] has quit [Read error: Operation timed out]
21:48 -!- b4epoche_ is now known as b4epoche
21:48 < genjix> BlueMatt: because i like people to have choice and freedom
21:48 < genjix> it is not harmful to give people choice or information

21:49 < BlueMatt> they do, if they actually want to come and reason about the issues, there is always someone here to discuss with
21:49 < BlueMatt> but they dont have choice
21:49 < BlueMatt> and unless they all switch to p2pool overnight, they wont get one
21:50 -!- shazooun [[email protected]] has quit [Ping timeout: 245 seconds]
21:50 < gmaxwell> genjix: there can't be choice and freedom without understanding. People don't bother even switching pools when their pools cost them money.
21:51 -!- shazooun [[email protected]] has joined #bitcoin-dev
21:51 < genjix> my worry is someday bitcoin becomes corrupted. see this extra scrutiny as an opportunity to build a culture of openness
21:51 < genjix> it is not at all bad.
21:51 < tcatm> it's not so much about having a choice but discovering "the best" way to implement more complex transactions types...
21:51 < gmaxwell> genjix: if you're concerned about the ecosystem why aren't you out there figuring out why people are paying 110%-115% PPS for secret mining projects? and telling the people who are contributing who don't currently know where their hash power is going.
21:52 < genjix> gmaxwell: i am writing an article on that
21:52 < gmaxwell> Oh. Smiley
21:52 < roconnor> genjix: s/Both BIP 0017 and BIP 0018 are/Both BIP 0016 and BIP 0017 are/
21:52 < genjix> but i have never mined a block so a lot of this is news to me.
21:52 < roconnor> PPS?
21:52 < genjix> like proportional mining being a scam and understanding the various statistical measures.
21:53 < gmaxwell> roconnor: pay per share.
21:53 < genjix> pay per share
21:53 < genjix> thanks roconnor
21:53 < gmaxwell> roconnor: people are being given a signficant premium on mining above the expected rewards, with ~zero payout variance.
21:54 < roconnor> gmaxwell: paid it bitcoin?
21:54 < roconnor> *in
21:54 < gmaxwell> roconnor: yes. If it were paid in USD it would be completely sensible.
21:54 < gmaxwell> roconnor: paid in bitcoin daily too.
21:55 < roconnor> that doesn't sound sustainable
21:55 < gmaxwell> roconnor: if it were being used to promote a new mining pool, for example, it would also be sensible... but this is for private projects with no published hash rates, so it doesn't have promotional value.
21:56 < BlueMatt> gmaxwell: link?
21:56 < gmaxwell> My best theory is that they're doing something useful with merged mining, next best is that they've got some idiot money laundering scheme (e.g. give miners dirty silkroad coins), worst outcome is that it's for some idiot attack. Sad
21:57 < gmaxwell> BlueMatt: https://bitcointalksearch.org/topic/closed-watch-the-thread-for-finaly-payout-info-project-2-54467
21:57 < gmaxwell> https://bitcointalksearch.org/topic/115-bonus-pps-pool-mining-opportunity-61117
21:57 < gmaxwell> https://bitcointalksearch.org/topic/gpumax-the-bitcoin-mining-marketplace-55819 (A meta service to aggregate these offers into a bidding market)
21:57 < gmaxwell> https://bitcointalksearch.org/topic/120-pps-mining-61570
21:58 < BlueMatt> now thats just weird
21:58 < gmaxwell> There are more... there are at least a half dozen people doing this all of a sudden.
21:58 -!- wirehead [[email protected]] has joined #bitcoin-dev
21:58 < roconnor> gmaxwell: I don't really see how it could be used to launder money
21:59 < gmaxwell> roconnor: I said idiot for a reason! Smiley
21:59 < roconnor> ah
21:59 < BTC_Bear> gmaxwell: quick question as to this:
21:59 < BTC_Bear> the checkpoints are there to keep from overtaking the blockchain, or at least it is a side benefit. gmaxwell would know more than I. But I believe, I am correct.
22:00 < roconnor> BTC_Bear: it is there to stop DOS attacks by sending you long but low work chains.
22:00 < gmaxwell> BTC_Bear: nah, not really— the checkpoints do that as a side effect but they're so far back that you couldn't realistically overtake even with a good multiple of the hash power for a short window.
22:00 < CIA-97> bitcoin: jedi95 * rec8af03cfdf7 Phoenix-Miner/minerutil/RPCProtocol.py: Fixed expire= for X-Roll-Ntime http://tinyurl.com/7xwchtb
22:00 < BTC_Bear> thanx
22:00 < gmaxwell> what roconnor said, they avoid some stupid DOS attacks.
22:00 < JFK911> where can I get 115%
22:01 < gmaxwell> I guess the risk of a new checkpoint being set does discourage someone from working in secret on a very long overtaking fork, but thats also some speculative side benefit.
22:01 < BlueMatt> as a sidenote, we need a new checkpoint for 0.6
22:02 < BlueMatt> s/for/before/
22:04 -!- dr_win [[email protected]] has joined #bitcoin-dev
22:06 < roconnor> genjix: gavin knew about the looping behaviour in OP_EVAL well before december.
22:06 < roconnor> genjix: the maximum iteration code was there from the beginning
22:06 < genjix> roconnor: i've corrected that

Notes:
- I was directly involved with the development of BIP 0016
- I wrote an article trying to present the facts. it was exhausting and took a lot of time so there may be some slip ups, errors or bad phrasing, but i want to inform the users and put out truth. I don't appreciate general hand waving trashing the article, i do appreciate constructive criticism about how to reword paragraphs or change sections to be more accurate.
- Went to great effort to make that article factually accurate, neutral, fair and balanced.
- Have no preference for BIP 16, BIP 17 or none. I will implement whatever comes along. Others have been thinking this over far longer than me.
- I asked the developers before asking them to write an article. Nobody seemed interested so I took on the task.
- Will definitely publish an article challenging mine from another developer.

I am not sure what has changed since this time and I am not sure why you did not bring to my attention what you feel is 'overt misinformation' in the article before hand. If there is something worth editing I will certainly consider it even now. I know you have helped a lot and I really have appreciated your efforts and the leaking of those documents before. I know you're a good guy, but lets talk through this more amicably without the attacks.

I run the BIP standardisation process and it is my responsibility to ensure that a BIP gets adequate discussion and approval before becoming a standard.
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
just look around you will find some of Gavin's threads. I'm into in the loop with you guys, dev team, so my opinions are based on what was made public on the forum lately.

If you're going to slander like that you at least owe the participants here a link to a specific message/a quote.

I think what you're saying is untrue and unfounded but if you go around and repeat it as a fact people who, unlike me, haven't read almost all the discussion are going going to believe it.

let's not elevate on this issue more than is necessary, and you can think whatever you want, at least we have that freedom. I'm not going to link/repeat what has been discussed because the forum does an awesome job keeping a record of it.
legendary
Activity: 2576
Merit: 1186
When I set the deadline, I had no idea Luke would:
  a) Decide that a bugfix 0.5.2 release was a good idea. I thought the minor bugfixes weren't worth taking the time to make a release but arguing with Luke is like arguing with a brick wall, so I went "meh, whatever."
  b) Propose BIP 17 and go on a war against BIP 16.

Here's the catch: Gavin is forcing everyone using the latest Bitcoin code to vote for BIP 16.

I don't see how 0.5.2 is at all related to this. I'm pretty sure there was a general consensus that the mlock fix (which drastically improved startup time and initial blockchain download) warranted it.

What is this?
Latest code = from git, to-be-0.6.
staff
Activity: 4284
Merit: 8808
just look around you will find some of Gavin's threads. I'm into in the loop with you guys, dev team, so my opinions are based on what was made public on the forum lately.

If you're going to slander like that you at least owe the participants here a link to a specific message/a quote.

I think what you're saying is untrue and unfounded but if you go around and repeat it as a fact people who, unlike me, haven't read almost all the discussion are going going to believe it.
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
@gmaxwell the pressure was created by Gavin and Luke, in the first place, with not so accurate statements, personal attacks and a close deadline ahead. Now you only see the waves coming back.

Please show me a statement made by Gavin which is inaccurate or a personal attack.

The whole characterization of Luke vs Gavin is nonsense to begin with. BIP16 arose out of combining a half dozen proposals, it was a _consensus_ proposal. At the regular development meeting that produced it no one was objecting to it at the end (partially no one because Luke had to leave early, before he left he indicated that he would only support it if some language about deprecating non-BIP16 transactions was added to the BIP).



just look around you will find some of Gavin's threads. I'm into in the loop with you guys, dev team, so my opinions are based on what was made public on the forum lately.
staff
Activity: 4284
Merit: 8808
@gmaxwell the pressure was created by Gavin and Luke, in the first place, with not so accurate statements, personal attacks and a close deadline ahead. Now you only see the waves coming back.

Please show me a statement made by Gavin which is inaccurate or a personal attack.

The whole characterization of Luke vs Gavin is nonsense to begin with. BIP16 arose out of combining a half dozen proposals, it was a _consensus_ proposal. At the regular development meeting that produced it no one was objecting to it at the end (partially no one because Luke had to leave early, before he left he indicated that he would only support it if some language about deprecating non-BIP16 transactions was added to the BIP).

Yes, Gavin created a bot that exploits a differential weakness of BIP17 vs BIP16. This was pretty helpful as luke was insisting there was no difference, and this let us feel out how the difference actually mattered.
The same bot could be created to steal BIP16 transactions instead.

Come on, you know it's not the same. A single BIP17 stealer hidden on tor with only one connection to the network will be 100% effective (in an network without P2SH validation, of course). A BIP16 stealer is only 100% effective if run by a large miner, otherwise it is only X% effective in cases where the stealer is on the shortest path between the spender and X% of the mining hash power.   I agree that it's a corner case, but there is a difference there.

legendary
Activity: 2576
Merit: 1186
Gavin created a bot that makes BIP17 testing impossible on the testnet.
Not quite. You can still test by using -p2shtime=0

I'm concerned about lukejr continuing to work on bitcoin after he proved his is an untrustworthy individual. He abused the people using his pool. And they want to continue to let him change the bitcoin code? I tell you what as a business owner, I would say fuck that shit. ANd really I am going to make sure as many business owners as possible who are considering bitcoin know who helps program it. And let them decide with full information that they have to trust something produced by a person who proved that they could not be trusted.
As a business owner, you should know better than to buy into these libelous lies and use such crude language.

When I set the deadline, I had no idea Luke would:
  a) Decide that a bugfix 0.5.2 release was a good idea. I thought the minor bugfixes weren't worth taking the time to make a release but arguing with Luke is like arguing with a brick wall, so I went "meh, whatever."
I don't see how 0.5.2 is at all related to this. I'm pretty sure there was a general consensus that the mlock fix (which drastically improved startup time and initial blockchain download) warranted it.
 b) Propose BIP 17 and go on a war against BIP 16.
Rather, I was "on a war against" BIP 16 from the day it was proposed. You chose to basically ignore my objections, and nobody else seemed to be coming up with an alternative to BIP 16 (since BIP 12 had been killed off), so I spent the time to create BIP 17 as a solution to provide P2SH without the problems posed by BIP 16.

Yes, Gavin created a bot that exploits a differential weakness of BIP17 vs BIP16. This was pretty helpful as luke was insisting there was no difference, and this let us feel out how the difference actually mattered.
The same bot could be created to steal BIP16 transactions instead.
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
@gmaxwell the pressure was created by Gavin and Luke, in the first place, with not so accurate statements, personal attacks and a close deadline ahead. Now you only see the waves coming back.
staff
Activity: 4284
Merit: 8808
Gavin created a bot that makes BIP17 testing impossible on the testnet.

This isn't true.  Yes, Gavin created a bot that exploits a differential weakness of BIP17 vs BIP16. This was pretty helpful as luke was insisting there was no difference, and this let us feel out how the difference actually mattered.

This doesn't make testing impossible, and there are in fact test transaction there. It actually aided testing and helped find some misbehavior in the software Luke was running with BIP17.

I have mined testnet for Luke several times to aid in his testing (and, in fact, did a costly 40 blockish reorg for him).

I think it's unfortunate that both Tycho and Genjix are both spreading overt misinformation here in order to create controversy.  (Tycho making insane claims that testing BIP17 is impossible, Genjix with falsely describing this as a "vote", claiming that people don't want you to know about this open and widely discussed matter, the over the top subject line)

The kind of hysteria being promoted here is a very big disincentive to contributing technically to bitcoin. I encourage everyone to be patient and thoughtful and recognize that bitcoin can not survive if people with powerful media presences are able to disrupt development and exhaust the developers at will.  Discussion is great, but consider whos interest panic is well aligned with: Certainly not the interest of the Bitcoin using community. Don't let your emotions be manipulated.

full member
Activity: 238
Merit: 100
Quote
P2SH provides a way to hide these SIGOPs from Satoshi’s rule to allow a newer more precise method for counting them to be developed.

(...)

P2SH does not solve this issue, but it buys more time.

... and ...

Quote
Rather than introducing a new paradigm of executing a piece of data on the stack upon recognising a particular script schema, CHV (BIP 0017) uses an existing operation that seemed to be included for this purpose by Satoshi: CODESEPARATOR.

CHV’s disadvantage over P2SH is nodes will accept any transactions spending an output as valid. To old clients it looks like a transaction that is spendable by anybody while P2SH requires the hashed data.

Judging on your explanation it appears as if BIP 17 is the superior approach. BIP 16 appears to be sacrificing elegance and consistency just for the sake of backwards compatibility ("older clients"). I don't see any reason to do this, an economically critical software such as bitcoin should be maintained and updated regularly by all users just like you would update any anti-virus software.

Quote
Summarising:

  • P2SH introduces a complexity-inducing solution to a tough problem.
  • CHV introduces a new operation code. Unexpected combinations of opcodes have been a problem in the past.
  • Remain where we are with all of bitcoin’s imperfections and problems. Use 70+ character addresses for multiple person transactions instead of 20 character ones.

I don't believe the last point to be a big issue at all. People will rarely write down an address character-by-character. Compared to weird/untested hacks and unnecessary complexity, a 70 symbol address seems to be the smalles evil.
.
Pages:
Jump to: