Bitcoin Forum
March 07, 2015, 12:07:48 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 ... 113 »
821  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.
822  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"
823  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 !
824  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."
825  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...
826  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.
827  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?
828  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.
829  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.
830  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).
831  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.
832  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).
833  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
834  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.
835  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.
836  Bitcoin / Development & Technical Discussion / Re: BIP 17 on: January 25, 2012, 07:20:58 PM
What frightens me is that there is no way back if we make this step and it turns out to be a wrong direction.
Please explain to me how ANY of the proposals (the original OP_EVAL, BIP 16, and BIP 17) are any different in the "what if we change our minds and want to remove support" case?

Removing support for BIP 17 would be harder than removing support for BIP 16, because if the network doesn't support it all BIP 17 transactions can be stolen as soon as they're broadcast.

Imagine there are a bunch of un-redeemed BIP 17 transactions in the block chain and support for BIP 17 goes away.  Every single one of them could be immediately redeemed by anybody.

The situation is better with BIP 16, because of the "half validation" done by old nodes.  Admittedly not a lot better, but it is the "belt and suspenders" nature of BIP 16 that makes me prefer it.
837  Bitcoin / Development & Technical Discussion / Re: Sweep/import private key feature request on: January 25, 2012, 05:55:53 PM
yeah lots of great features and improvements left alone for the supposedly ultimate feature... p2sh (multi redeem) or what it's name is

we need sweep now, fast initial blockchain download and lots more. I'm really disappointed atm  Cry

I've been very clear about my top development priorities:

1. Network stability: DoS threats, scaling-up issues, etc.
2. Wallet security/backup.

I see everything else as lower priority; I want users to be confident that their bitcoins can't get stolen even if they slip up and open an attachment in Outlook that the aughtn't have opened before I want a downloads-the-entire-blockchain-in-10-seconds client with all sorts of other bells and whistles.

838  Bitcoin / Development & Technical Discussion / Re: Sweep/import private key feature request on: January 25, 2012, 05:50:20 PM
I was really looking forward to the import feature in bitcoind (don't care about sweep). Too bad the developers decided to be nanny for us.

Huh?  GIT HEAD bitcoind supports import private key functionality:
Code:
importprivkey <bitcoinprivkey> {label}

Whether or not that's ever supported by the GUI is a different issue, and there I think we SHOULD be more concerned about people using the GUI shooting themselves in their feet.

839  Bitcoin / Development & Technical Discussion / Re: BIP 17 on: January 25, 2012, 04:13:55 PM
IsStandard() is a permanent part of the protocol with BIP 16.

No, it really isn't.

Here's a possible future implementation of IsStandard():

Code:
bool
IsStandard()
{
    return true;
}

I like the idea of a future IsStandard() that allows more transaction types, but only if they're under some (sane) resource limits.
840  Bitcoin / Development & Technical Discussion / Re: BIP 17 on: January 25, 2012, 03:00:17 PM
Why the hard dates?
You both are struggling and rushing because the dates you set keep coming again and again, before miners notice and upgrade. Here's an alternate idea:
  • Have P2SH* implemented, and announce P2SH support in the coinbase, but it's disabled until a certain condition is met.
  • The condition is to have 55% or more blocks in any 2016-block span announcing support for P2SH.
  • When that condition is met, the remaining 45% hashing will have two weeks to update.
  • Remove the P2SH announcement and just reject blocks with invalid P2SH transactions. Also the changes in the block limits will be made effective here.
  • A future version of the software will remove the automatic switch logic.

That's non-trivial to implement; it seems to me that a conscious decision by the miners/pools to support or not support is less work and safer.

Luke proposed something similar earlier, though; I'm surprised his patches don't implement it.

I like whoever proposed that the string in the coinbase refer to the BIP, in the future that's the way it should be done.


RE: schedules:

Deadlines, as we've just seen, have a way of focusing attention.  OP_EVAL got, essentially, zero review/testing (aside from my own) until a month before the deadline.

It seems to me one-to-two months is about the right amount of time to get thorough review and testing of this type of backwards-compatible change. Longer deadlines just mean people get busy working on other things and ignore the issue.
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 ... 113 »
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!