Bitcoin Forum
March 31, 2015, 05:25:33 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
  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 92 ... 114 »
821  Bitcoin / Development & Technical Discussion / Re: BIP 17 on: January 27, 2012, 10:15:34 PM
No direct contact of the major players making up 55%+ of the mined blocks, with the possible exception of Slush(?) and/or Tycho (?) in "secret." 

Just FYI: I contacted the top ten mining pools (as listed in the stickied threads in the Mining Pools subforum) directly via email way back in October, copied the email to them in the Mining Pools forum, and kept them 'in the loop' on all of this.

I probably should have posted all of my followup emails to them in the Mining Pools forum, also; as I said, I'm terrible at that kind of "keep track of who you've told what and make sure you've got 'buy-in' from X Y and Z" thing.

I think my only really major blunder was being too stubborn about inserting some wording into BIP 16 that Luke wanted inserted; I let my emotions cloud my judgement.
822  Bitcoin / Pools / Supporting BIP 16 on: January 27, 2012, 09:01:37 PM
A few of the big mining pools have started supporting BIP 16, and I feel pretty confident that they've shaken out any major bugs.

If you'd like to jump on the bandwagon, backported code for BIP 16 is available at:
  https://github.com/gavinandresen/bitcoin-git/
... in the "p2sh_backport" and "p2sh_backport_vinced" branches.

Backports are available for all releases from bitcoin version 0.3.19 forward; for example if you're running code forked from the 0.3.24 release you would:

Code:
git checkout -b bip16  # Create a branch for the changes, just in case
git fetch --tags git://github.com/gavinandresen/bitcoin-git.git p2sh_backport
git tag -l 'bip16*'  # List the backports available
git merge bip16_v0.3.24_1

The "vinced_mergedmine" tags are for if you are using Vince's 'getauxwork' patch/branch for merged mining (based on bitcoin version 0.3.24).

If you're running latest&greatest or are willing to upgrade to the latest&greatest, BIP 16 support is already in https://github.com/bitcoin/bitcoin/


Finally, if you do decide to support BIP 16, upgrade your code, and start mining with it, let me know and I'll be happy to thank you publicly in my signature  (offer good until I run into the 300-characters-in-the-signature forum limit).
823  Alternate cryptocurrencies / Altcoin Discussion / Re: On the Solidcoin Economic Changes on: January 27, 2012, 07:29:30 PM
(channelling my inner CoinHunter):

It is SIMPLE ECONOMICS, people!

price = function(supply,demand)

So to create more demand, just fix the price and the supply!  Easy-peasy!

(ok, done, back to reality)
824  Bitcoin / Pools / Re: [419 GH] Eligius pool: ~0Fee SMPPS, no reg, RollNtime, hop OK, BTC+NMC merged! on: January 27, 2012, 07:23:33 PM
There is no OP_P2SH. BIP 12, 16, and 17 are all competing standards for P2SH. BIP 17 is the most sane, and BIP 16 the least.

<begin troll>

No it is not!  BIP 17 is bad for the network and will give you herpes!

<end troll>
825  Bitcoin / Bitcoin Discussion / Re: BIP 16 / 17 in layman's terms on: January 27, 2012, 05:35:32 PM
I'm curious to know how thoroughly these proposals have been tested. That might go a long way toward swaying opinion. I would imagine having a public alt-coin for the sole purpose of implementing one proposal or the other and seeing how easy it is to break could be a great proving ground.
Testing is actually one of the reasons I don't like BIP 17; it is harder to test, because it is much easier to steal BIP-17 transactions if the network hasn't yet upgraded (Luke has had to test BIP 17 on the main network instead of testnet because I wrote a BIP-17-stealing robot and ran it on testnet).

I've spent the last couple of days running "transaction fuzzing" tests against both the new BIP 16 code and old clients; so far it has turned up no problems. "Fuzzing" means throwing lots and lots of random inputs at a program and making sure it deals with them properly; it is another good way of finding the "what do you know, we didn't think of that..." bugs.

The fuzzing tool is here:
  https://github.com/gavinandresen/bitcoin-git/tree/fuzzer

Also RE: ghastly exploits:

Satoshi himself made changes to the way the scripting language works after a series of 'ghastly exploits' were discovered back in 2010 after the first slashdotting. I'm so stubbornly against BIP 17 because it basically reverts one of the changes he made (separating execution of scriptSig and scriptPubKey-- take that discussion to another thread in Dev&Tech if you want to argue more about it, please).
826  Bitcoin / Development & Technical Discussion / Re: BIP 17 on: January 27, 2012, 03:38:57 AM
I'll have to review the BIP format and requirements, but I can probably put something together.  It's based on the Python development RFC format or something, yeah?
Yes, BIPs are based on PIPs and BEPs (for Python and BitTorrent).  See BIP 0001 for the process.
827  Bitcoin / Development & Technical Discussion / Re: BIP 17 on: January 27, 2012, 02:58:28 AM
I don't think it bodes ill at all.  I think, in the future, if something like this is handled properly as a roll out, things will go very well.  This entire thing was botched from the beginning as far as the rollout goes and then quickly devolved into this mess. 
We all learn from our mistakes.

Would you be willing to write an "informational BIP" describing how to do a rollout right in the future?

I'm terrible at that kind of "first we'll need to get buy-in from groups X, Y, and Z by doing A, B, and C, then each of those groups will elect representatives who will have three days to agree to a schedule, which will be announced blah blah blah blah"
828  Bitcoin / Bitcoin Discussion / Re: This will change Bitcoin as you know it. on: January 26, 2012, 11:56:07 PM
LOL!  I gotta stop shaving and start working on that nifty 'stash !
829  Bitcoin / Technical Support / Re: How bad firewall settings can make you lose 75 BTCs on: January 26, 2012, 10:51:17 PM
So, yes, i did 4 out of 4. I had no idea mistakes were prune to ratings.
So if I or anyone does 5 mistakes, what then, you think our house should blow up?

....

It's just a disappointment to see development does not care about its 'flock' - we, who make mistakes as any human does, are on our own.
Fair enough, from your pedestal point of view, of course. 

I apologize for coming across as harsh, it has been a hard couple of weeks.

And the reason it has been a hard couple of weeks is because I'm working really hard to try to get support for multisignature wallets... which would have prevented your loss (assuming you were using a multisignature-protected wallet).

The hacker would have been able to ask your bitcoind to send him your coins, but you would have got a confirmation on your cell phone (or SMS or email with a one-time-PIN or whatever) and realize immediately that you'd been hacked.

Or, in other words:  I've been working really hard trying to get a solution for the bigger problem of insecure computers, because I really do care about the "flock."
830  Bitcoin / Bitcoin Discussion / Re: BIP 16 / 17 in layman's terms on: January 26, 2012, 10:23:34 PM
(but Gavin attacked me too while I did nothing wrong).
I apologize-- I did not mean to attack you, I thought I stated nothing but facts. I am also sorry I didn't speak up about some of the things that were said about you earlier in this thread (e.g. suggesting an attack on your pool is NOT cool) but I don't have time to read every forum post as soon as it is posted...
831  Bitcoin / Development & Technical Discussion / Re: Questions about BIP 16 / 17 in layman's terms on: January 26, 2012, 10:19:01 PM
1. It's prudent to avoid executing data from the stack. Why? Because you have a scripts that manipulate data on the stack. Obviously the system is designed so that scripts can't manipulate the data that is going to be executed. But if there is a bug, you have all the pieces in place for an exploit. The script doesn't have opcodes to manipulate off-stack data, so Luke's implementation seems safer.

Did you read BIP 16?

Quote
Validation fails if there are any operations other than "push data" operations in the scriptSig.

So there is no manipulation allowed AT ALL.

Quote
2. Supporters of BIP 16 claim that it allows 5-10 times more headroom before block size limits are reached. Supporters of BIP 17 claim that it puts fewer bytes into the block. Can someone please make a clear statement about what these proposals actually mean for scalability?

A maximum of 1,000 "naked" OP_CHECKMULTISIG operations are allowed in the scriptSigs and scriptPubKeys of transactions in any given block.

We had a block earlier this month with 1,8000 scriptSigs, so I think we are uncomfortably close to that limit.

BIP 16 "hides" the CHECKMULTISIGS in the serialized script, so more of them are allowed.

Quote
3. It's clear that both BIP 16 and BIP 17 transactions can be spent by others if those transactions are broadcast before 50% of the mining power (plus a safety margin) supports them. It's also clear that the BIP 17 transactions are easier to spend in this situation. However I think this is a non-issue because (a) mining power will quickly rise above 50% once consensus is reached, and (b) who is going to broadcast these newfangled transactions before the mining power is there to support them?

At the very least BIP 17 is harder to test-- Luke had to test on the main network because I was naughty and wrote and ran a BIP-17-transaction-stealing bot (sorry, I couldn't resist).

Quote
3. I have a vague feeling of undue haste. Gavin has already said that his motivation is the security of people's transactions, and I don't doubt it. But is that the whole motivation? Gavin needs to say whether it's commercially relevant to his current work project whether BIP 16 or BIP 17 is chosen (or how quickly the new functionality is firmed up). It's no big deal if Gavin has a commercial interest. In that case, he should just step aside from administering the oversight of this particular decision.

I have zero commercial interest; I am not being paid by anybody for anything right now.
832  Bitcoin / Mining / Re: Miners don't even know what P2SH is! on: January 26, 2012, 08:16:58 PM
An explanation is REQUIRED in order to vote.
Like this one?
833  Bitcoin / Technical Support / Re: How bad firewall settings can make you lose 75 BTCs on: January 26, 2012, 08:01:54 PM
There should be some deterrence in place for these cases of plain user dumbness.

Let me count the ways:

1. You must explicitly choose a username and password; you must have enough tech know-how to find your bitcoin.conf directory or run with -rpcpasswrod= options.

2. If you choose a short password, then every failed access attempt DOES trigger a timeout.

3. You must explicitly tell bitcoin to listen for connections from IP addresses other than localhost, using the rpcallowip= option.

4. You must open a hole in your firewall that lets any arbitrary IP address through to your rpcport.

I'm sorry you lost 75 bitcoins, but you really made a LOT of mistakes. Adding more layers of protection to the RPC interface isn't high on the development priority list, but if anybody wants to volunteer to keep track of number of failed RPC authentication attempts over time then be my guest and write a patch. Just be sure it isn't vulnerable to denial-of-service attacks by people deliberately generating failed login attempts.
834  Bitcoin / Development & Technical Discussion / BIP 16 big picture on: January 26, 2012, 05:21:41 PM
I just had a great discussion with a developer who urged me to write a "big picture" technical post about BIP 16.  So:

First, I think a good design approach is to be clear about what you are trying to accomplish and think about what the ideal solution, if there were no constraints like backwards compatibility, would look like.

The big picture goal has always been:  short, multisignature bitcoin addresses (BIP 13).

The ideal solution would be to split scriptSig/scriptPubKey into three parts:

signatures, redemption script, and redemption script hash.

The sender would just provide the script hash, the receiver would provide the script and signatures to sign them over to somebody else.

Ideally, the redemption script hash would be include a version or 'hash type' byte, so in the future if RIPEMD160(SHA256()) was ever considered insecure a smooth upgrade could happen.

That's the ideal solution. I think all bitcoin transactions should have been done that way from the start, but it is what it is. Now we have to compromise, because one of the design constraints is backwards compatibility-- we are not going to replace scriptSig/scriptPubKey with something else and require everybody to upgrade all at once.

OP_EVAL tried to do too much, in my opinion.  It enabled all sorts of nifty things, but we made the mistake of losing sight of what we were trying to accomplish.

BIP 16, in my view, meets the goal and (importantly!) does nothing more.  I think of it as implementing the ideal three-way split in as simple and safe way as possible:

signatures:   all the items except the last pushed onto the stack by the scriptSig
redemption script:  the last item pushed onto the stack by the scriptSig
redemption script hash:  the scriptPubKey

It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !



That's all why I like BIP16 better than OP_EVAL.  I've written quite a lot here on the details of why I prefer BIP 16 to BIP 17, but, fundamentally, I believe that BIP 16 is a more conservative solution that is less likely to have an "darn, I didn't see that coming" bug.
835  Bitcoin / Bitcoin Discussion / Re: BIP 16 / 17 in layman's terms on: January 26, 2012, 02:37:56 PM
I want to try to clear up two misconceptions:

1. The original implementation of OP_EVAL was not "exploitable", but it did have bugs.  

2. The Feb. 1 deadline was explicitly designed to be a "soft" deadline; here is what BIP 16 says about it:
Quote
To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.

On February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.

If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved).
836  Bitcoin / Bitcoin Discussion / Re: BIP 16 / 17 in layman's terms on: January 26, 2012, 02:17:28 PM
As I've been asking in other threads, but have yet to get an answer, I will ask here again.  Why is this such a rush?  Why the secretive "upgrade?"  What is wrong with this proposal that it requires it to be force pushed through at such a rapid pace?

This needs to be weighed and measured and the potential consequences thought out.  Why is this not being done?

I believe that without a deadline nothing would get done.

We could talk and argue and discuss for six months trying to find the perfect solution, and there would still be people saying that we need another six months to argue and discuss some more.

In fact, us developers HAVE been discussing and arguing about this for over six months now; this whole thing started with an impromptu brainstorming session at the first Bitcoin Conference in New York.

As for this upgrade being "secretive" : huh? It certainly isn't/wasn't a secret among the developers, and until the developers came to rough consensus (and I believe there IS rough consensus, despite what Luke claims) I didn't think non-developers would be interested in the technical details.

From some of the reactions in this thread, I think I was right-- most people don't care whether we use nails or screws or glue to build a better wallet.

RE: rumors that I'm doing this for some personal reason:  100% untrue. I want a solution because it will make Bitcoin better sooner.
837  Bitcoin / Bitcoin Discussion / Re: BIP 16 / 17 in layman's terms on: January 26, 2012, 01:06:44 AM
Call me dumb, but I absolutely do not understand how you are supposed to create a whole address out of partial sigs?!? Wouldn't it be necessary for all sigs to come together at one point to create a single address hash to which you can then send the coins?

Bitcoin addresses today correspond to one public key in your wallet.

Signatures enter the picture when you spend the bitcoins sent to an address; your private key is used to generate the right digital signature, proving that you actually have that key.

BIP 16/17 will enable bitcoin addresses that are associated with more than one public key. Your wallet will know both public keys, but will only know ONE of the private keys needed to spend the bitcoins (your phone or a "wallet protection service" will keep the other private key safe).

So when sending coins, your wallet will provide one signature for the private key that it knows, the other required signature must come from whatever device is holding the other private key.

The public keys aren't just strung together in a row, but are combined using a secure hashing algorithm (the same algorithm that is used to associate public keys with the bitcoin addresses we're all using today).
838  Other / Off-topic / Re: Ignore this post, I just have to vent a little bit... on: January 26, 2012, 12:01:17 AM
Ie, most bitcointalk people dont bother with reading the technical laden Development & Technical Thread.

I suppose I could have posted to the general Bitcoin Talk, but I didn't think that kind of low-level "plumbing" would be of general interest, any more than the average bitcoin user would care or notice a bunch of other low-level "plumbing" changes that are being made (I've got a patch pending that a certain-somebody doesn't like because it tightens up the definition of a "standard" transaction; I expect that if I pull that patch he'll start screaming that I'm wrecking future network flexibility all because I'm a big old worry-wart).

I did post to the Mining/Pools forum a couple of months ago looking for feedback because miners/pool operators are the people who are "voting" on the original proposal:
  https://bitcointalk.org/index.php?topic=50707.msg604435#msg604435
839  Bitcoin / Bitcoin Discussion / BIP 16 / 17 in layman's terms on: January 25, 2012, 09:25:32 PM
So you might have rumblings about changes to the network:  OP_EVAL and BIP 16 and BIP 17 and multisig and P2SH, and you wonder what the heck is going on.

Here's my view; I'll try not to get too technical.

First, the feature:

I want more secure wallets. There's unanimous agreement among developers that the easiest, fastest way to get there is with "multi-signature transactions" -- bitcoins that require approval from more than one person or device to spend.

For example, a future version of Bitcoin-Qt might know how to talk to an app running on your mobile phone. When you send bitcoins, it would provide one signature, but it would have to ask your phone for approval and the other signature.  That way even if your computer gets compromised by malware your bitcoins absolutely positively cannot be stolen, since the best the malware could do would be to ask your phone to approve the "Send the bad guys bitcoins" transaction.

The bitcoin network protocol already mostly support multi-signature transactions, although they're considered "non-standard" right now.  Part of what is going in is making them standard.  That's not controversial.

What is causing all the discussion is how to support sending coins into one of these new, spiffy, secure wallets.  There is rough consensus that the best way to do that right now is with a new type of bitcoin address; I say "rough consensus" because in a perfect world some people think that there wouldn't be bitcoin addresses visible to users at all.  And I say "right now" because we don't live in a perfect world, and there are no proposals for how, exactly, to replace bitcoin addresses with something better.

Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this:
  57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
(or possibly even longer)

I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable.

So: there are three proposals on how to support short multisignature addresses-- BIP 12, 16, and 17.

I withdrew BIP 12 (also known as "OP_EVAL") because I try to be extremely conservative when it comes to changes to core Bitcoin, and I think BIP 16 is a safer way to go.

Luke Dashjr liked OP_EVAL, really doesn't like BIP 16, and came up with BIP 17, which solves the same problem in a different way. I still like BIP 16 best, because I think it is the most conservative, safest solution. The number of people who understand the guts of Bitcoin well enough to have an informed opinion about which is better is pretty darn small, but I think the controversy is really about how conservative we aught to be.

All of the BIP 12/16/17 stuff is mostly engineers arguing over whether it is better to use a nail, a screw, or glue to put two pieces of wood together. Any of the solutions would work, and ordinary users wouldn't notice any difference; you'll still (eventually) get spiffy, more secure wallets.

(don't take the analogy too far, in this case using a nail AND a screw AND some glue to be extra safe isn't an option).

How dangerous is all this?  Is the bitcoin network in danger of falling apart one of these BIPs is adopted?

The worst-case scenario for all of this stuff (including the non-controversial support of multisignature transactions as "standard") is that some bug will slip by, and an attacker will figure out a way of getting all the nodes running the new software to crash or misbehave. I'm working hard to prevent that from happening-- I've been writing "unit tests" and "fuzzing tools" and have been getting other developers to look really hard at the code.  I strongly believe that the new feature is worth the (small) risk, and that even in the worst-case scenario the consequences are not catastrophic (we'd just fix the bug and come out with a new release; everybody still running old code would continue to confirm transactions and create blocks while the early adopters were busy downloading and installing the fixed software).

The bitcoin network is NOT in danger of falling apart if any of these are adopted; they are all backwards-compatible, so old software will continue to work exactly as before.

Some footnotes (and sorry for making this so long):

I concentrated on multisignature transactions for secure wallets, but they're useful for several other things, including escrow transactions and "emergency offline backup keys" for wallet backups.

I've set an arbitrary deadline of February 1'st for deciding whether or not to "turn on" the new short-multisignature-bitcoin-address-support feature, mostly because deadlines are the only way I know to actually get people to pay attention. If you read the BIPs, those deadlines are designed to be flexible, so if there is NOT a majority of support or "we" think that not enough time has gone by or enough testing has been done they can (and will) be slipped.

Right now, it looks like one person/pool (Tycho/deepbit) has enough hashing power to veto any change. I believe Tycho liked, and planned to support, the original OP_EVAL proposal, but doesn't like/support either BIP 16 or BIP 17 (he does like/support BIP 11, the multisignature-as-standard-transactions part of all this), so unless he changes his mind or there is a mass exodus from his pool short, multisignature bitcoin addresses will have to wait.
840  Bitcoin / Bitcoin Discussion / Re: Concerns: The Centralization of a Decentralize Currency on: January 25, 2012, 07:46:10 PM
Decentralized systems often settle into some kind of "power law distribution."

For example, there's no central authority determining how large cities all over the world should be, and yet if you plot the size of cities you'll see that there are a few REALLY big ones, a bunch of medium sized ones, and a gazillion small ones.

Plot the size of the bitcoin mining pools and I think you'll see the same thing.

If there were no mining pools, then plot the hashing power of individual miners and I bet you'd see the same thing... (ArtForz used to be a significant fraction of mining power all by himself, for example)

I worry a lot more about incentives than I do size; if the "naturally big" players have the right incentives, then they're not bad for the network. So far, I think the incentives are working nicely. For example, people HAVE tried to knock out the big mining pools and exchanges using denial-of-service attacks, and the big mining pools and exchanges have (as far as I can tell) worked to fix that problem themselves.

PS: p2pool built into a bitcoin client is something I'd fully support, I think a lot of people would like a one-button "get a trickle of bit-pennies" option.
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 92 ... 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!