The Truth behind BIP 16 and 17 (important read)

Atheros

sr. member

Activity: 249

Merit: 251

Quote from: casascius on February 03, 2012, 07:57:03 PM

Remove all of this fluff from a pruned block chain, make a "regenesis" block consisting of nothing but unspent outputs, and I bet it's less than a third the size of even a pruned block chain, and less than a tenth or twentieth the size of our current chain (a disparity that increases toward infinity as bitcoin is used - by 2013, this disparity might quadruple).

Ok, I definitely concede that it would be smaller. All of those things individual miners can do on their own. The chain wouldn't be verifiable anymore but we basically threw that condition out of the window when we made a re-genesis block. I'm sure miners will be doing this before long as long as the full block chain is still available in a distributed manner.

finway

hero member

Activity: 714

Merit: 500

Gonna read this long post someday.

casascius

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

Quote from: Atheros on February 02, 2012, 07:15:46 PM

RE: 2_Thumbs_Up

That new 'genesis block' would be just as big as the current pruned blockchain, so there is no point in doing it that way. Luckily there is no need: clean and simple P2SH would be easy to do with the current blockchain and transactions. The only challenge would be, apparently, the network-wide upgrade process.

This may belong in another thread, but I have heard this point made, and I am not sure I agree with it, just doing a mental estimation in my head.

A new genesis block would be the same size as the current pruned blockchain, minus all of the following VERY BIG wastes of space:

Transaction inputs (these are HUGE: 130+ bytes each, compared to outputs around 30 bytes each) - and are worthless information except for their verification value... when multisig arrives, typical inputs will be double and triple this per transaction.
Stubs left behind when you prune merkle trees (since you need the full hash of the branches you pruned to be able to verify the hash of what's left of tree, which in many cases these hashes are a decent fraction in size of the transactions they replace)
Spent outputs of multi-output transactions (which can't be pruned if ANY unspent outputs remain - especially bloatful when you consider, for example, that pools like P2Pool generate huge transactions with numerous penny-sized outputs to pay off miners, of which most but not all get spent... which directly means that most of the space they take up is a waste).

Remove all of this fluff from a pruned block chain, make a "regenesis" block consisting of nothing but unspent outputs, and I bet it's less than a third the size of even a pruned block chain, and less than a tenth or twentieth the size of our current chain (a disparity that increases toward infinity as bitcoin is used - by 2013, this disparity might quadruple).

ByteCoin

sr. member

Activity: 416

Merit: 277

Quote from: Luke-Jr on February 03, 2012, 02:02:33 PM

Quote from: westkybitcoins on February 03, 2012, 01:52:13 PM

It is already cryptographically possible to have two or more devices each have access to a portion of a private key, and be able to combine these portions to spend funds in such a way that no device gains access to any more of the private key than it already had, correct?

AIUI, no.

Yes it's possible. As far as I can recall, you need to use the additive homomorphic property of the Pallier scheme. It has been discussed on the forum before but I can't find the reference.

ByteCoin

fivemileshigh

full member

Activity: 136

Merit: 100

Quote from: [Tycho] on January 29, 2012, 10:32:20 AM

* Disclaimer: I don't think that BIP17 is better than BIP16. Both are ugly hacks. I will support one only if most other miners will.

Tycho, I mean this with all the kindness and respect I can possibly muster:

If you think both are ugly, make your case and stand by it. "Just doing what everybody else is doing" is groupthink. Don't be a sheep. Nothing good or worth having lies that way.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: westkybitcoins on February 03, 2012, 01:52:13 PM

It is already cryptographically possible to have two or more devices each have access to a portion of a private key, and be able to combine these portions to spend funds in such a way that no device gains access to any more of the private key than it already had, correct?

AIUI, no.

westkybitcoins

legendary

Activity: 980

Merit: 1004

Firstbits: Compromised. Thanks, Android!

At the risk of rehashing a settled issue, I have a stupid question:

It is already cryptographically possible to have two or more devices each have access to a portion of a private key, and be able to combine these portions to spend funds in such a way that no device gains access to any more of the private key than it already had, correct?

If this is the case, I'm wondering why it's considered mission-critical to implement scripting for multisig and for extra security measures in general by altering the protocol, rather than letting the owners of the private keys take responsibility for securing them and preventing unauthorized spending.

Atheros

sr. member

Activity: 249

Merit: 251

RE: 2_Thumbs_Up

That new 'genesis block' would be just as big as the current pruned blockchain, so there is no point in doing it that way. Luckily there is no need: clean and simple P2SH would be easy to do with the current blockchain and transactions. The only challenge would be, apparently, the network-wide upgrade process.

[Tycho]

hero member

Activity: 742

Merit: 500

Also I would like to say that at least partially all this mess is caused by the opcodes that Satoshi disabled more than a year ago.

I think that multisigs with short addresses can't be implemented without P2SH because OP_CAT op is disabled. May be.

2_Thumbs_Up

sr. member

Activity: 323

Merit: 251

Quote from: Atheros on February 02, 2012, 06:26:10 PM

Quote from: 2_Thumbs_Up on February 02, 2012, 06:07:14 PM

But RFID tags will most likely be a good competitor to QR codes as NFC becomes standard in smart phones, no?

This would still be the data one would need to copy and paste. They would still be called "Bitcoin addresses" by everyone except perhaps the developers themselves. They should be as short as possible. Also, all of that data is necessarily going to be stored in the blockchain- much of it forever and ever.

I agree with those points, I just don't think that QR codes will stay around forever so that part shouldn't really be a factor in determing the future of bitcoin as far as I'm concerned.

Quote from: Atheros on February 02, 2012, 06:26:10 PM

Quote from: 2_Thumbs_Up on February 02, 2012, 06:07:14 PM

Am I right in my understanding of the issue if I think that the problem arises from trying to implement P2SH and keeping backwards compatibility? If P2SH had been the way bitcoin works from the beginning then it would be fine, but since we now have an "old" block chain to think about the solutions become hackish?

Yes, this is my impression. The fact that we have an old blockchain isn't the problem- it is guaranteeing that enough people upgrade.

Ok. I'm not a dev so I'm very cautios in suggesting anything. This is more out of curiosity and for understanding. But would it be technically possible to start over from scratch with a new block chain and altered protocol that allows P2SH in a clean manner and put all the current owners of bitcoins in the genesis block?

I'm just a user of bitcoin so I know my voice doesn't have the most weight. But I do see the value in the features that P2SH provides but hackish solutions still make me very wary, and I'm probably not the only one. So if it's at all possible to implement this in a clean manner that would put a lot of my worries to rest, even if it would be more cumbersome to transition.

And I don't really want to go into the dangers of such a transition with the merkle tree and whatever. I'm just wondering if it's technically possible, or if a clean implementation of P2SH is incompatible with the current adress syntax even with a new block chain.

Atheros

sr. member

Activity: 249

Merit: 251

Quote from: 2_Thumbs_Up on February 02, 2012, 06:07:14 PM

But RFID tags will most likely be a good competitor to QR codes as NFC becomes standard in smart phones, no?

This would still be the data one would need to copy and paste. They would still be called "Bitcoin addresses" by everyone except perhaps the developers themselves. They should be as short as possible. Also, all of that data is necessarily going to be stored in the blockchain- much of it forever and ever.

Quote from: 2_Thumbs_Up on February 02, 2012, 06:07:14 PM

Am I right in my understanding of the issue if I think that the problem arises from trying to implement P2SH and keeping backwards compatibility? If P2SH had been the way bitcoin works from the beginning then it would be fine, but since we now have an "old" block chain to think about the solutions become hackish?

Yes, this is my impression. The fact that we have an old blockchain isn't the problem, it is the fact that we would have old clients. They would need to upgrade.

2_Thumbs_Up

sr. member

Activity: 323

Merit: 251

Quote from: cbeast on January 31, 2012, 06:45:39 AM

Huge addresses can make difficult to read QR codes. They become harder to scan with a camera phone and even print clearly. Just an added observation.

But RFID tags will most likely be a good competitor to QR codes as NFC becomes standard in smart phones, no?

Quote from: Steve on January 29, 2012, 11:53:17 AM

Quote from: wachtwoord on January 29, 2012, 11:04:51 AM

What is the added value beyond shorter addresses for complex transactions? Because I don't see that as very important.

I think it's important. An address doesn't have to be a hash of anything…an address could be the entire script that you want someone to send coins to. However, that would be rather unwieldy and there has been considerable investment in the notion of a bitcoin address being a relatively short thing. Both investment in terms of software and investment in terms of people learning and understanding bitcoin. To start passed around very long addresses would be rather confusing I think. It also has the drawback of revealing more about the destination script than is necessary.

P2SH is the way that bitcoin should have been designed from the beginning IMO. Outputs of transactions (scriptPubKey) should have always been just a hash and the validation always been that a script hashes to that value and executes successfully. Using long addresses would be moving in the wrong direction in my opinion.

Am I right in my understanding of the issue if I think that the problem arises from trying to implement P2SH and keeping backwards compatibility? If P2SH had been the way bitcoin works from the beginning then it would be fine, but since we now have an "old" block chain to think about the solutions become hackish?

Atheros

sr. member

Activity: 249

Merit: 251

Like the maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000)?

Maybe this is naïve, but I'm personally fine with that being taken care of a little later- the very fact that it *must* be done means that it actually will get done. And hopefully by that point we can take care of a few other things on the hardfork wishlist.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Atheros on February 02, 2012, 05:05:27 PM

Quote from: EhVedadoOAnonimato on January 31, 2012, 10:33:15 AM

But still, big addresses and transaction fees are not that big of a problem to provoke all this rush and heated discussions.

If we don't fix it soon, it will never get fixed. And it needs to get fixed because it will be an enormous problem several years from now. Proper scrutiny and testing is certainly necessary- but these changes are urgent.

Protocol changes are early or never. And never is very very bad.

There are much more important fixes that need to be made for Bitcoin to scale, and they are hard-forking.

Atheros

sr. member

Activity: 249

Merit: 251

Quote from: EhVedadoOAnonimato on January 31, 2012, 10:33:15 AM

But still, big addresses and transaction fees are not that big of a problem to provoke all this rush and heated discussions.

If we don't fix it soon, it will never get fixed. And it needs to get fixed because it will be an enormous problem several years from now. Proper scrutiny and testing is certainly necessary- but these changes are urgent.

Protocol changes are early or never. And never is very very bad.

EhVedadoOAnonimato

hero member

Activity: 630

Merit: 500

If they are already trusting a service similar to an eWallet to hold half the keys.... but yeah, you have a point, shortening services wouldn't work in most cases. But still, big addresses and transaction fees are not that big of a problem to provoke all this rush and heated discussions.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: EhVedadoOAnonimato on January 31, 2012, 05:32:02 AM

Huge addresses are not a major problem. If people can get along with huge URLs, there's no reason to believe they would be lost with large addresses. Even if an address is thousands of chars long, shortening services could come along and provide a short URL that you can put into those QR codes again.

I don't think it's a good idea to encourage people to trust URI shortening services with their money.

EhVedadoOAnonimato

hero member

Activity: 630

Merit: 500

Quote from: da2ce7 on January 31, 2012, 07:48:28 AM

Quote from: EhVedadoOAnonimato on January 31, 2012, 07:41:36 AM

As do huge URLs. People would just use a shortener, as I suggested on my post above yours.

That is the problem... it takes up extra space in the chain... where the sender pays the fees; not the spender.

Quote from: EhVedadoOAnonimato on January 31, 2012, 05:32:02 AM

And transaction fees are and will remain very cheap to the end user for several years yet. People actually argue they will remain low forever, and that the main financing to mining will come from other sources. Even if that's not the case, there's plenty of time to do this calmly.

da2ce7

legendary

Activity: 1222

Merit: 1016

Live and Let Live

Quote from: EhVedadoOAnonimato on January 31, 2012, 07:41:36 AM

As do huge URLs. People would just use a shortener, as I suggested on my post above yours.

That is the problem... it takes up extra space in the chain... where the sender pays the fees; not the spender.

This is bad; as say mtgox would only except 'plain' bitcoin addresses.

EhVedadoOAnonimato

hero member

Activity: 630

Merit: 500

Quote from: cbeast on January 31, 2012, 06:45:39 AM

Huge addresses can make difficult to read QR codes. They become harder to scan with a camera phone and even print clearly.

As do huge URLs. People would just use a shortener, as I suggested on my post above yours.

Topic: The Truth behind BIP 16 and 17 (important read) (Read 8605 times)