Topic: Deadlines and moving forward (BIP 16/17 support) - page 2. (Read 8870 times)

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

Maybe that should be here for later forks, but as far as I know neither BIP 16 nor 17 need a fork like that. Old clients will remain compatible.

Seems like even a possible solution to the everbloating blockchain problem.

Nope, no magic solutions to either of those sadly - there's a reason that I supported the idea of P2SH back in the OP_EVAL era before the whole thing turned into a circus, and in fact Coiledcoin started off as my personal testbed for playing with it with all the mainnet checks still in operation. Something that works is better than something that might work eventually though.

No need to suspend chains.  Just create a new transaction type that renders coins "unspendable" and includes a public key.  Have the new chain's rules include a clause allowing the holder of the corresponding private key to create an equal amount of coins on the new chain.

With merged mining the fork won't even sacrifice hashpower.

This avoids the need for any sort of agreement/voting/cabal.  Each user decides which chain they want their coins to be on.  It isn't even "one coin, one vote" -- it's simply letting people move their coins to whichever system they feel best meets their needs.

I don't think any particular issue is the end of the world— but the representation that we can just use big addresses and it's no big deal is ignoring that there are other issues. I know you know about some of them. But I don't believe most people saying "oh, big addresses are no big deal" do.


Interesting thought, I hadn't considered that possibility. But "We can handle longer ones" isn't the same as "don't care" by doing that the minimum length for a 2of2 simple secured wallet, pretty much the simplest case, probably won't fit in a tweet anymore (for example), they won't fit in the small QR codes anymore, etc.

Do you have a magic solution to recipients losing the freedom to have complicated rules because the sender doesn't want to handle the TXN fees or risk of slow processing?  The concentration of more data in unprunable unspent outputs? etc.   Thats it— it's just not simply "big addresses", there are other issues even if they aren't super major.

+1

Some of them may be less important than you think. For example, I seem to recall you were worried that someone malicious could easily create their own pay-to-script address that only differed from the genuine address by a few characters but could be redeemed by them instead. There's an obvious solution to that if you don't care about address length: append the 160-bit hash of the script to the start of the address. That way, the more characters at the start someone compares, the harder it is to trick them.

I challenge you to demonstrate how well informed you are on this sub-subject by linking to posts giving at least three total distinct arguments against that position.

I think there have been a precedent like this in one of the alt-chains starting with S
They suspended 1.0 chain and somehow transferred all wealth into 2.0 chain which had new rules and its own genesis block.
So it should be possible at least theoretically.

Yes. Some of us are perfectly fine with complex transactions having addresses a hundred characters long and that is just as legitimate an option as BIP-16, 17, or anything else that could possibly replace them.

I was going to say the same thing. Those "NOTHING"s up there are too bold... the stronger miners could just attack the weaker network. We've seen Eligius being used to attack an alt chain, so these kind of violent behaviors should be expected.

But I agree with gmaxwell that this democracy analogy is perhaps not very adequate.

The bottom line is that non-technical people should have no say in an issue that is purely technical. This is technocratic democracy and it's simply the best way. All technical people should be invited to the discussion and then they can vote amongst themselves, simple as that. Then the results are made public and the miners will upgrade based on that, if the team decided to go forward with either BIP. There should of course be a vote for "neither".

If people are afraid that this technical team can misuse their power either now or in the future, it's important to remember that the miners have the ultimate decision in the end. In most cases they should support the decision that the devs made but if there is reason to believe that they are doing something very suspicious, they can always refuse to upgrade.

If this issue is handled in any other way, I will seriously lose confidence in Bitcoin. The public debates need to end, they are not helping to solve the issue, instead they are just adding doubt in people's minds.

This is only true so long as you assume that people would go on and continue to use a version of Bitcoin when they know that there's more than enough miners hostile to its existence that a small proportion of them could execute a 51% double-spend attack and that they have an incentive to do so. In fact, if 100% of current miners leave even a small proportion of them could just block all transactions from getting confirmed.

As you've pointed out elsewhere, in order for Bitcoin to work miners need an incentive to co-operate rather than defect. Once they've all announced they're planning to defect from the developer-approved version it's likely to get screwed badly.

Of course, getting users to upgrade seems to be even harder than getting miners to upgrade, which is presumably why you're not doing it this way. Plus, the uncertainty as to which version to use would probably be hugely disruptive in itself - the only safe thing to do would be to just stop using Bitcoin until the dust settled and everyone had agreed on which side of the resulting fork to use, because if the miners are hostile and have a financial incentive to destroy the developer's side of the chain fork...

Though I'm far from understanding the technical details (I'm just a miner) I find this discussion fascinating, and the opportunity to setup a new decission making system for bitcoin, that will luckily attempt to enhance the corrupted "democratic" systems as we already know them.

I'm not intending to give an exact proposal of how this voting system would be, but only a few guidelines that will be enhanced by more intelligent people.

Decision makers should be :

- Satoshi (if he ever shows again)
- Developers
- Miners
- Pool owners
- Users

Keeping in mind that bitcoin WILL be attacked hard, assign a proper percentage to each of them, making it impossible for any individual or group of individuals to collude or being obliged to collude, to do any harm to bitcoin.

Changes on bitcoin fundamentals should not be easy, if not impossible. We need a stable, predictive and, why not, very conservative system, making it almost impossible for any individual or group of individuals to change bitcoin for their own benefit.


     

   

I can agree to this if there will be a mechanism to preserve "wealth" of current network and transfer it into the new one..

Really, can you, developers, come up with a script that does this? Like CTRL-C CTRL-V

can we see theymos idea + non-backwards compatible new standard?

a blockchain fork will have to happen in the future.

see this as a good testbed, practice run or training level.

if we cannot get it right then bitcoin is doomed.

Sorry this is off topic (my fault).  Feel free to open up a new thread for discussion.

Why?  A pool owner has everything to gain by preserving the value of bitcoin.  If the network isn't running smoothly the value of bitcoin drops and pool operators are out of business.  Also, if pool operators attempted a change that benefits them over everyone else (setting aside the practicality of actually doing such), you can be sure it would undermine the value of bitcoin.  Mind you, I'm not saying that it's not a good idea to disperse the hashing power that a pool controls…I would certainly like to see more control (especially over block creation) returned to the individual miners.

Man, I wish this were true, but it's not. (and I'm basically informed about EC math )

The problem we need to address with wallet security is this:  We can't trust a service provider to have control over our private keys (see mybitcoin) and (many users) can't really trust their own computers because of viruses and trojans (which even superhuman effort don't completely prevent unless you go the offline dedicated hardware route, with poor usability). These are also problems for traditional banking, but in traditional banking transactions are reversible— which stinks but hides a lot of security sins by user and the banking infrastructure.

You absolutely can have two people create a key in two parts which must be combined to sign via multiplication of the public/private parts (I use that property in the type-2 deterministic wallets I describe in the link above).  The problem is that they must actually be combined to use them, meaning that somewhere there must exist a single computer with the final private key in memory. ... but in our threat model above no such ultimately trustworthy computer exists.  People also have good reasons for needing things like "Two of {A,B,C}, or D" which doesn't fit into a simple combined key/threshold model. So we must use multisignature transactions for this purpose.

There do exist threshold signature schemes which allow for independent processing, but the ones I'm aware of have other compromises (like being large) and, more critically, aren't compatible with our ECDSA.   This is sad because as nice as multisig is, you couldn't do crazy things like have a transaction directly controlled by 50,001 out of 100,000 people with it (the spending transaction would be too big).

P2SH does nice things for other kinds of complicated transactions— not just multisignature. So even though multisignaure is the main end-user use for the here and now it's still a good direction independent of that.