Bitcoin Forum
April 25, 2018, 01:08:08 PM *
News: Latest stable version of Bitcoin Core: 0.16.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 / Pools / Re: Supporting BIP 16 on: January 28, 2012, 05:08:19 PM
You know how I say "I make mistakes, don't trust me" ...

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.

Backports and the main git HEAD tree have been patched with the fix.

On a higher level:

There is obviously not going to be 50+% blockchain support for BIP 16 on Tuesday; I'm going to start conversations on how to move forward.

And there has obviously not been enough testing of the BIP 16 code. Getting people to thoroughly test things BEFORE code makes it into the main tree has been a chronic problem, I'd appreciate ideas on how to avoid this kind of annoying, time-wasting "it's ready"/"oops, found a bug"/"it's fixed"/"wait, no, somebody found another bug" thing in the future. I've been unsuccessful finding the kind of QA (quality assurance) person who can both do the QA and do the fundraising necessary so they get paid.
822  Bitcoin / Bitcoin Technical Support / Re: bitcoin-qt 0.5.2 Wallet Doesn't Match Blockchain on: January 28, 2012, 01:12:18 AM
Yes, you will confuse the GUI if you send coins to 'change' addresses.

My advice would be "don't do that."

Thanks very much for helping to test, though, it is very appreciated!
823  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.
824  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:
... 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:

git checkout -b bip16  # Create a branch for the changes, just in case
git fetch --tags 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

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).
825  Alternate cryptocurrencies / Altcoin Discussion / Re: On the Solidcoin Economic Changes on: January 27, 2012, 07:29:30 PM
(channelling my inner CoinHunter):


price = function(supply,demand)

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

(ok, done, back to reality)
826  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>
827  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:

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).
828  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.
829  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"
830  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 !
831  Bitcoin / 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."
832  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...
833  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?

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

So there is no manipulation allowed AT ALL.

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.

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).

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.
834  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?
835  Bitcoin / 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.
836  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.
837  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:
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).
838  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.
839  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).
840  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:
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!