Bitcoin Forum
May 09, 2016, 01:03:34 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 [41] 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 ... 114 »
801  Bitcoin / Development & Technical Discussion / Re: Deadlines and moving forward (BIP 16/17 support) on: February 01, 2012, 02:31:46 PM
OK, it has been a couple of days and the general consensus seems to be a 'rolling' two-week window, with no "below 20%" rule.

I don't think there is any need for a two-week email discussion period among those familiar with the guts of Bitcoin, we've already spent months discussing the options and the consensus for BIP 16 is clear (see the tally here).

It is time to call it settled and move on to bigger and better things, like what protocol to use when a client needs to gather signatures (REST? JSON? http? https? something else?).
802  Bitcoin / Development & Technical Discussion / Re: BIP 22? on: February 01, 2012, 01:28:44 PM
STOP IT.  JUST STOP IT.

BIP 16 has overwhelming support, it will be the solution.

Casascius:  please read BIP 0001 for the process to get assigned a BIP number.  The process is not "create a page on the wiki."

As for the proposal itself:  No.

You are proposing a non-backwards-compatible change, which would mean a "hard" blockchain split. Everybody agrees that is a bad idea. The confusion and potential for hacks if a significant fraction of bitcoin users were on a separate chain is massive; you gloss over all of that in your proposal.
803  Bitcoin / Bitcoin Discussion / Re: How Open Source Projects Survive Poisonous People on: February 01, 2012, 01:24:24 PM
I moved Casascius' proposal ("BIP 22") to the Dev&Tech forum, I will respond there.
804  Bitcoin / Development & Technical Discussion / Testnet chain split scheduled for Feb 15 on: January 31, 2012, 07:06:06 PM
FYI: I pulled:
  https://github.com/bitcoin/bitcoin/pull/686

... which will likely result in a testnet blockchain split on February 15'th. I hadn't pulled before because I was busy with other things. The testnet faucet bitcoind will be updated in the next day or two.

See this thread for the design discussion.
805  Bitcoin / Bitcoin Discussion / Re: How Open Source Projects Survive Poisonous People on: January 31, 2012, 04:48:35 PM
gavin, what they talk about in the video is one person derailing a whole project over extended periods of time.

Yes, exactly. At some point you have to say "enough is enough, I'm not going to let this person derail the project any more going forward."

I'm saying that point is right now; see the unproductive, one-sided argument about BIP 20 versus BIP 21 on the bitcoin-development mailing list that is re-hashing a wiki editing war that "the rest of us" just gave up on a year ago for the latest example.
806  Bitcoin / Development & Technical Discussion / Re: BIP 16 analysis from a miner's point of view on: January 31, 2012, 03:52:24 PM
The way i understand it BIP16 changes completely the scripting system for the p2sh transactions. How ? bypassing it. Seen lot of code examples already. BIP17 uses an existent placeholder OP code to fit it's needs and another one that seems to have been put there by Satoshi himself.

You understand wrong.

BIP 16 recognizes a certain pattern of bytes, and says "If you see those bytes, then the script will be provided by the person who has the coins instead of the sender (the sender just provides a secure hash of that script)."

The script that is provided is then used EXACTLY as if it was a "normal" sender-provides-the-script transaction.

BIP16 is the most conservative possible solution to the problem we want to solve.
807  Bitcoin / Bitcoin Discussion / Re: How Open Source Projects Survive Poisonous People on: January 31, 2012, 03:41:03 PM
RE: debating ideas rather than people:  I've tried very hard to do that.

I said last year when I reluctantly agreed to function as the lead core bitcoin developer that I have zero experience leading open source projects.  But I try to do my due-diligence and learn from the experience of other successful projects.

The "aha" moment for me yesterday is the point in the video that I linked to, where the advice is to evaluate whether or not somebody causing issues for a project (whether intentional or not) is a net positive or negative to the project, and if they're "more trouble than they're worth" get them out of the project.

This isn't about BIP 16 versus BIP 17, this is about one person draining the rest of the development team with nagging, idealogical rigidity, and holy wars against "impure" ideas.

I try very hard to consider that maybe I'm wrong, but I think the evidence is clear.

You might also argue that the subversion people take the wrong approach, in which case please send me a link to some other open source project that has dealt with the issue in a different/better way.

I thought carefully about where to start this, and decided I might as well start it in the most public bitcoin discussion forum, because I think if I started it anywhere else it would eventually just appear here as "There's a Secret Conspiracy Started By Gavin To Oust A Valued Developer!"
808  Bitcoin / Bitcoin Discussion / Re: How Open Source Projects Survive Poisonous People on: January 31, 2012, 01:49:19 PM
bittenbob:

You replied 3 minutes after I posted.  You obviously didn't watch the video link I posted.

At that link, two experienced subversion (another successful open source project) developers talk about what to do if somebody in your open source community makes it impossible to have unity and agreement.

You say "we need to get back to unity" -- I agree.  That is why Luke must go.
809  Bitcoin / Bitcoin Discussion / How Open Source Projects Survive Poisonous People on: January 31, 2012, 01:26:04 PM
Thanks to midnightmagic who directed me to this very helpful video about identifying and then dealing with "poisonous people" in open source software projects:
  http://youtu.be/ZSFDm3UYkeE

Advice on disinfecting:
  http://youtu.be/ZSFDm3UYkeE?t=34m22s

Watch the whole thing for examples of "poisonous person" behavior, like repeatedly flooding mailing lists/forums with their opinion or comments, not listening to the opinion of others, or making sweeping "the world will end if..." statements about the project.

I'll be blunt:  I think Luke Dashjr fits the definition of a poisonous person, and I think Bitcoin would be better without him. At the very least, we wouldn't be creating two BIPs for every technical issue, one for Luke and one for the rest of us (see BIP 16/17, and now we have BIP 20/21, too).
810  Bitcoin / Bitcoin Discussion / Re: The Truth behind BIP 16 and 17 (important read) on: January 30, 2012, 10:42:08 PM
For context: makomk is the creator of CoiledCoin, a bitcoin alternative:
  https://bitcointalk.org/index.php?topic=56675

And RE: creating bots:  I created a BIP-17-stealing bot because it was really easy (took about 10 minutes of hacking).  A BIP-16-stealing bot would be a lot harder (because it would have to 'lie in wait' until the sender was redeeming the coins, and then race to relay/mine a 'stealing' version of the transaction before the rest of the network mined the original).
811  Bitcoin / Pools / Re: Supporting BIP 16 on: January 30, 2012, 10:24:09 PM
A bug in my code is dropping transaction fees from the block reward. Simple to fix, and obvious in hindsight; I will be personally reimbursing everybody who got bit by this bug by finding the blocks affected by this, figuring out what transaction fees the creators SHOULD have received, and sending that number of bitcoins to the block-award address.

Transaction sent: 2d3006cf1e16cb9f4097894fdaa0739c66d38eb9e0356be3fd8daf63810cf375

I wrote some code that found all blocks with "/P2SH/" in their coinbase that did not include transaction fees in the block reward. I extracted the block reward payment address (or addresses, if it was a p2pool block) and reimbursed those addresses.

If the amount would be less than 0.0011 bitcoins, then I rounded the amount awarded up to 0.0011.  Just because eleven is my favorite number (well, and because I like the idea of rewarding p2pool users, I think p2pool is neat).
812  Bitcoin / Bitcoin Discussion / Re: BIP 16 / 17 in layman's terms on: January 30, 2012, 05:54:23 PM
I've started a discussion on BIP 16/17 support moving forward (including trying to improve the testing process) here:
  https://bitcointalk.org/index.php?topic=61922.0

(please reply there so the discussion stays mostly in one place)
813  Bitcoin / Pools / Re: Supporting BIP 16 on: January 30, 2012, 05:52:14 PM
I've started a discussion on BIP 16/17 support moving forward (including trying to improve the testing process) here:
  https://bitcointalk.org/index.php?topic=61922.0
814  Bitcoin / Mining / Re: Would you support P2SH? Please, mining pool operators, vote! on: January 30, 2012, 05:50:57 PM
RE: rushing:

I'm starting a discussion on how not to rush here:
  https://bitcointalk.org/index.php?topic=61922.0
815  Bitcoin / Development & Technical Discussion / Deadlines and moving forward (BIP 16/17 support) on: January 30, 2012, 05:49:15 PM
BIP 16 (or 17) will not meet their initial "go/no-go" deadlines.  You can see the state of support here: http://blockchain.info/P2SH

That's OK, that's why the deadlines were structured the way they are; in the past, Satoshi made changes like this by simply changing the code and then expecting everybody to upgrade. This is the first time we've used a more open, community-driven process.

So, since we'll miss the deadline, the question is:  what next?  To focus discussion, here are two straw-man proposals that y'all can agree or disagree with; I'll go along with whatever consensus arises over the next couple of days:

Quote
Support for BIP 16/17 will be evaluated weekly, beginning on February 1 (support measured as described in the BIP). Results shall be announced here in this thread, and when support exceeds 55% the switchover date shall be set two weeks from then (with announcements made here, to the bitcoin-development mailing list, and to the Mining and Mining Pool forums).  If support drops to less than 20%, then the proposal shall be withdrawn.

Quote
To give more time for testing and deployment, there will be a new go/no-go deadline for evaluating BIP 16/17 support. The new deadline for BIP 16 shall be March 1, 2012. If 55+% support the new feature (as described in the BIP), then March 15 shall be the switchover date.


On the subject of testing... I've created a wiki page to record QA (quality assurance) testing that has been done on BIP 16.  If you can help test, or have been testing/deploying, then please add to this page:  https://en.bitcoin.it/wiki/BIP_0016_QA

As always, (on-topic) discussion, feedback, etc. is very welcome. If we can, I'd like to move past the "we dont' need to do ANYTHING" arguments, there is clearly rough consensus (with notable exceptions) that a short-bitcoin-address solution is needed.
816  Bitcoin / Bitcoin Discussion / Re: Donning tin foil hat concerning multisig transactions on: January 30, 2012, 05:35:15 PM
I understand that but I thought when this idea was first presented it was said that the user would keep both key's a in a backup wallet so you couldn't be held hostage with your service provider.

Yes, that's the use-case I care most about -- you have control over all of your keys, you just put them in multiple places so if you lose control of (say) your computer you don't lose your bitcoins.

But there are other use-cases, like you agreeing to let the government control half the keys, so the government can "guarantee" the transactions, etc.  I can imagine the PR campaign: "It is just like Federal Deposit Insurance (FDIC), only for Bitcoin!"

I don't think that will ever happen, though. I know I wouldn't trust the government to keep the keys to my money safe and secure, I don't think most people would, either. More likely is most people will trust banks to hold half the keys, and the governments will then regulate the banks like they do today to get information about who is paying who for what....
817  Bitcoin / Bitcoin Discussion / Re: Donning tin foil hat concerning multisig transactions on: January 30, 2012, 03:03:44 PM
If a government has the capability to exert control...
So far, I think the pace of technological change has outrun governments' ability to figure out how to use it to exert control.

Maybe governments will get more nimble, but I'm going to continue betting that entrepreneurs and individuals will continue to widen the gap between the new freedoms that technology enables and what the law allows.

RE: multisignature transaction dangers:  I'm completely convinced the (large, practical) benefits far outweigh the (small, theoretical) risks that it'll be abused by some repressive government(s).
818  Other / Meta / 1-post locked threads on: January 30, 2012, 02:46:09 PM
So the SolidCoin folks have been creating 1-post locked threads announcing stuff.

Putting aside how you feel about SolidCoin, I wonder what other people think about that practice in general.  It seems to me to go against the purpose of "Forums" -- seems to me the whole point is discussion.  If you don't want discussion, then buy an ad or publish information on your website.

Seems to me locking threads should be a last resort instead of "I'll just lock every thread I make to keep out the trolls."

I'm going to lock this thread now because I think some people will disagree with me.
(KIDDING, JUST KIDDING)
819  Bitcoin / Bitcoin Discussion / Re: The Truth behind BIP 16 and 17 (important read) on: January 29, 2012, 04:41:53 PM
Exactly. There's no urgency, so I really don't understand why the urgency to ram through a proposal with any risk attached with the excuse that nothing will get done otherwise? Gavin?

It is completely artificial urgency, so a decision is reached and implemented in a reasonable amount of time.

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.

Both of those distracted from implementation and testing of BIP 16.

But what's past is past, the question is what do do from here; I'm planning on starting that discussion in the Dev&Tech forum tomorrow.

PS: RE: risk:  the risks of either proposal to the overall health of the bitcoin network are small.
820  Bitcoin / Pools / Re: Supporting BIP 16 on: January 29, 2012, 03:02:08 PM
nFees was defined twice?
How come the fees weren't 0 all the time?

The fees were 0 all the time, that was the bug.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 [41] 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 ... 114 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!