Bitcoin Forum
March 30, 2024, 07:26:02 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3] 4 5 »  All
  Print  
Author Topic: The Truth behind BIP 16 and 17 (important read)  (Read 8536 times)
Atheros
Sr. Member
****
Offline Offline

Activity: 249
Merit: 251



View Profile WWW
January 29, 2012, 10:16:27 PM
 #41

To risk permanent harm to the system...

There is no risk of permanent harm.

And the blockchain bloat? That almost seems like a distraction. Complex transactions are going to take up extra space in the blockchain; arguing over where and when the bloat occurs seems pretty academic too.

You forget that completed transactions can be pruned. They can and will be deleted by many miners after the bitcoins are spent further. Unspent bitcoins can not. They are kept by all miners forever. These BIPs would reduce the size of unspent transactions, no matter how complex, to the lowest safe size. It is not merely academic. It is significant.

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
1711783562
Hero Member
*
Offline Offline

Posts: 1711783562

View Profile Personal Message (Offline)

Ignore
1711783562
Reply with quote  #2

1711783562
Report to moderator
1711783562
Hero Member
*
Offline Offline

Posts: 1711783562

View Profile Personal Message (Offline)

Ignore
1711783562
Reply with quote  #2

1711783562
Report to moderator
Activity + Trust + Earned Merit == The Most Recognized Users on Bitcointalk
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711783562
Hero Member
*
Offline Offline

Posts: 1711783562

View Profile Personal Message (Offline)

Ignore
1711783562
Reply with quote  #2

1711783562
Report to moderator
1711783562
Hero Member
*
Offline Offline

Posts: 1711783562

View Profile Personal Message (Offline)

Ignore
1711783562
Reply with quote  #2

1711783562
Report to moderator
oOoOo
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
January 29, 2012, 10:18:53 PM
 #42

Ultimately we seem to be fracturing the community (and potentially the blockchain!) just for the sake of convenience. If complex transactions require 70-character addresses, then so be it. To risk permanent harm to the system to avoid them just seems short-sighted.

Agreed!


There is no risk of permanent harm.


Besides the split of the chain...
Costia
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
January 29, 2012, 10:23:01 PM
 #43

Quote
These BIPs would reduce the size of unspent transactions, no matter how complex, to the lowest safe size.
never understood why that would happen, the bips just move the large script from the output to the input
unspent blocks have both
inputs of unspent transacions can be pruned? (afaik pruning is actually not supported by the client)
I thought the merkle tree contained hashes of transaction and not hashes of separate inputs/outputs...
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
January 29, 2012, 10:24:55 PM
 #44

Ultimately we seem to be fracturing the community (and potentially the blockchain!) just for the sake of convenience. If complex transactions require 70-character addresses, then so be it. To risk permanent harm to the system to avoid them just seems short-sighted.
Agreed!
There is no risk of permanent harm.
Besides the split of the chain...

Any split would resolve, assuming a simple majority of the future hash power was enforcing the new rules. It's not an unresolvable split risk.

70 characters is more like the minimum address length for a non P2SH secure wallet address.  An actual complex transaction might be more like 1000-2000 characters.

I gave genjix a pretty nice list of reasons why P2SH is important other than the long addresses. Unfortunately, he decided to only quote from people saying negative things about P2SH in his post.  Here is what I wrote to him:

Quote

...  No it's not a mistake.  P2SH _prevents_ needing long addresses.

Lets unpack the acronym "pay to script _hash_".  Hashes only need to
be 128-256 bits in size or so to have acceptable security, so you
don't need something longer than that for paying to a hash.

Note that gavin is saying 70 characters, not bytes.

Without some form of P2SH then only way for you to make a personal
choice of asking people to pay to a two-factor protected account or
two a multiparty trust that manages the finances of an organization
is using some form of "P2S", pay-to-script.

In other words, you'd have to have an address that encodes a full
script specification for the sender to pay to,  instead of just
encoding its hash.  As a result these addresses would be much longer
(and potentially very long).

The minimum size of a two address involving encoded script would be on
that order, but they get bigger quite quickly if you add more options
to the script (actually 70 sounds quite small, it should be more like
100 for a minimum two pubkey script).

In addition to the unworkability of very long addresses as described
by gavin (amusingly I am unable to copy and paste the quoted example
in one go) a P2S solution has several problems which you might
consider more or less important:


(1) They are highly vulnerable to invisible substitution.  E.g. I can
trivially take a P2S address, change one or two characters and get a
script which is redeemable by anyone.  With P2SH you have to do
computation which is exponential in the number of unchanged digits to
get a look alike address.

(2) The sender is fully responsible for fees related to the enlarged
transactions. Even if _you're_ willing to take the txn-processing time
and fee burden of a 30 person joint trust address,  random e-commerce
sites will not be and will randomly reject your addresses.

(3) They create another input vector for non-trivial data which must
be inspected and validated, potentially presenting an attack surface.

(4) They leave the complicated (long) release rules in the transaction
outputs.  When a transaction is mined we can't be sure if it will ever
be redeemed. The outputs are unprunable.   In a future world where
many nodes prune output space is far more important than input space
and it would make sense to require more fees for it because we're
never sure how long it would need to be stored (making it an
attractive target for someone who wants to make Bitcoin unusable by
spamming it with worthless data).  P2SH reduces output sizes to the
absolute minimum without inflating the total data size.
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
January 29, 2012, 10:34:10 PM
 #45

Quote
These BIPs would reduce the size of unspent transactions, no matter how complex, to the lowest safe size.
never understood why that would happen, the bips just move the large script from the output to the input
unspent blocks have both
inputs of unspent transacions can be pruned? (afaik pruning is actually not supported by the client)
I thought the merkle tree contained hashes of transaction and not hashes of separate inputs/outputs...

Pruning in this case doesn't actually have too much to do with the merkle tree here.  Once a transaction has been spent, and the spend is burred in your chain, you'll never need any of it's inputs (or the outputs they spend) again and so you can save the storage.   (the connecting tree isn't relevant, because you've already validated the transactions for yourself, you don't need to continually prove to yourself that you weren't lying to yourself)

When you get a transaction you don't know when it will be spent— or _if_ it ever will be— maybe you'll need to store its outputs for 6 months or 60 years.   But you do know that you'll be able to forget about its inputs as soon as they're burred deep enough in the chain.   So given equal total sizes we should strongly prefer to put more of the bytes in the script signature (the input side).

The current reference software doesn't take advantage of this... but the chain is only a gigabyte now.  The storage requirements from these decisions have an impact for basically forever.

Costia
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
January 29, 2012, 10:44:54 PM
 #46

Quote
(the connecting tree isn't relevant, because you've already validated the transactions for yourself, you don't need to continually prove to yourself that you weren't lying to yourself)
it becomes relevant if you add it to the default client.
then everyone will remove the inputs, and new clients downloading the blockchain will have trouble finding a record they can validate. (and if a new client cant validate, maybe an attacker will be able to generate a longer chain by manipulating some of the hashes)
the way i see it, if you decided to keep the blockchain - you should never prune so it cant be validated. if you don't want to keep it, you can delete all of the blocks right after validation and just keep a signed (by yourself) copy of unspent transactions.
Atheros
Sr. Member
****
Offline Offline

Activity: 249
Merit: 251



View Profile WWW
January 29, 2012, 10:49:26 PM
 #47

it becomes relevant if you add it to the default client.
then everyone will remove the inputs, and new clients downloading the blockchain will have trouble finding a record they can validate.

Pruning will not be so naïvely implemented.

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
January 29, 2012, 10:56:47 PM
 #48

then everyone will remove the inputs, and new clients downloading the blockchain will have trouble finding a record they can validate.

This is always the case for pruning, or at least pruning naively implemented. The reference client will support both modes of operation some day. I have a half dozen copies of the blockchain at home, thats silly and non-scalable. Smiley

The alternative to pruning isn't not pruning— FWIW— if the reference client doesn't gain the ability to prune more and more people will move to nodes like multibit which don't validate _at all_, and bitcoin will lose its decentralization.  Bootstrapping is important, but its irrelevant if you can't afford the runtime costs.

Quote
the way i see it, if you decided to keep the blockchain - you should never prune so it cant be validated. if you don't want to keep it, you can delete all of the blocks right after validation and just keep a signed (by yourself) copy of unspent transactions.

You need to keep enough to allow you to reorganize, but yes. P2SH minimizes the size of that set of that unspent data (by a factor of 2-4 or so, depending on what kind of assumptions you make on the frequency of complicated transactions). It does this without any particular 'costs', except the cost of deploying something new now. It's just one of the several advantages of using P2SH style transactions.
Costia
Newbie
*
Offline Offline

Activity: 28
Merit: 0



View Profile
January 29, 2012, 11:02:22 PM
 #49

you can prune in a way that you can still validate. you will only nee to keep 1 transaction per block and the merkle tree hashes.
I guess it will only matter for light clients then.
westkybitcoins
Legendary
*
Offline Offline

Activity: 980
Merit: 1004

Firstbits: Compromised. Thanks, Android!


View Profile
January 30, 2012, 02:04:12 AM
 #50

To risk permanent harm to the system...

There is no risk of permanent harm.

Hmm. I'm going by what I've read on the other thread. I seem to recall one of the big points of contention was that, essentially, "we can't screw this up, because if we do, we won't ever be able to fix it."

One example:

And, at the same time, there's nothing stopping anyone from implementing both.  It's conceivable someone could create a client that did the validation for both BIP-16 and BIP-17.  Miners could also validate both style transactions.  Since they are both designed to be backward compatible, they will all be recognized as legitimate transactions by the whole network if they get into a block (even if not all clients relay them).  The downside of course is that if you create either a BIP-16 or BIP-17 style transaction and the majority of mining power isn't doing the full validation, you run the risk of losing your coins to theft.

Perhaps its more accurate to say implementing either risks causing serious problems.



Quote
And the blockchain bloat? That almost seems like a distraction. Complex transactions are going to take up extra space in the blockchain; arguing over where and when the bloat occurs seems pretty academic too.

You forget that completed transactions can be pruned. They can and will be deleted by many miners after the bitcoins are spent further. Unspent bitcoins can not. They are kept by all miners forever. These BIPs would reduce the size of unspent transactions, no matter how complex, to the lowest safe size. It is not merely academic. It is significant.

Unspent bitcoins are only kept by miners until they are spent.

Sure, there will be some "lost" coins... coins sent using complex transactions where the recipient loses the private key, dies before spending the coins, etc. But I think that's a negligible situation that shouldn't dictate the protocol.

I think the real question is, how long on average will coins sent via complex transactions remain unspent? If the intention is for most transactions in the future to become complex (which I'm seeing hints of, and if so, I'd love to be pointed to where this is actually discussed openly,) then I see your point, but I don't see that that as a given.

Even if the average time delay of spending coins from complex transactions is months (which sounds highly unlikely,) it still just delays the pruning. A "rolling amount" of temporary bloat from some unspent complex-tx coins doesn't seem like it would be enough to worry about.

Bitcoin is the ultimate freedom test. It tells you who is giving lip service and who genuinely believes in it.
...
...
In the future, books that summarize the history of money will have a line that says, “and then came bitcoin.” It is the economic singularity. And we are living in it now. - Ryan Dickherber
...
...
ATTENTION BFL MINING NEWBS: Just got your Jalapenos in? Wondering how to get the most value for the least hassle? Give BitMinter a try! It's a smaller pool with a fair & low-fee payment method, lots of statistical feedback, and it's easier than EasyMiner! (Yes, we want your hashing power, but seriously, it IS the easiest pool to use! Sign up in seconds to try it!)
...
...
The idea that deflation causes hoarding (to any problematic degree) is a lie used to justify theft of value from your savings.
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
January 30, 2012, 02:13:45 AM
 #51

I think the real question is, how long on average will coins sent via complex transactions remain unspent? If the intention is for most transactions in the future to become complex (which I'm seeing hints of, and if so, I'd love to be pointed to where this is actually discussed openly,) then I see your point, but I don't see that that as a given.

The expectation that many in the future would be 'complex' because all two-factor wallets transactions would be complex.  I'd certainly encourage typical users to go this route.

But it's also not the entirely right question to ask here, because the chain doesn't just carry earnest transactions.  If someone wants to DOS attack bitcoin to make it unusable or ruin its decentralization, they'll use the cheapest method available to add the most immortal data to the blockchain. By reducing the amount of potentially immortal data needed in normal financial transactions we reduce that attack, because it is either easily distinguishable from normal transactions (thus subject to higher fees), or isn't as much data.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
January 30, 2012, 02:19:26 AM
 #52

FYI, earlier this morning Gavin solved the 1000-multisig-input limitation on BIP 17. I'm in the process of drafting a new BIP to cover these scripts (this isn't directly P2SH related) now.

P.S. I don't claim that Gavin is supportive of BIP 17 in light of this solution. I don't know if he is or not.

N12
Donator
Legendary
*
Offline Offline

Activity: 1610
Merit: 1010



View Profile
January 30, 2012, 02:26:17 AM
 #53

I’m with gmaxwell and BlueMatt. Why turn this technical stuff into a FUD political power struggle debate? It’s not like everyone had an opinion on how encryption should have been done, too. People don’t have to have an opinion on this, it’s up to the developers to achieve consensus.

I’m also with Gavin and Steve. Two-factor Authentication is extremely important for safely using Bitcoin without having the hassle of paper wallets and extra offline computers! Noone except us enthusiasts would go for such lengths, and that could be a reason we are stagnating in terms of users and acceptance.

I don’t understand why this debate exists.
westkybitcoins
Legendary
*
Offline Offline

Activity: 980
Merit: 1004

Firstbits: Compromised. Thanks, Android!


View Profile
January 30, 2012, 02:39:36 AM
 #54

I think the real question is, how long on average will coins sent via complex transactions remain unspent? If the intention is for most transactions in the future to become complex (which I'm seeing hints of, and if so, I'd love to be pointed to where this is actually discussed openly,) then I see your point, but I don't see that that as a given.

The expectation that many in the future would be 'complex' because all two-factor wallets transactions would be complex.  I'd certainly encourage typical users to go this route.

I do see the utility of this, but I find myself wondering if this will really be how the masses will handle most of their transactions; having to always use two devices for every spend can get inconvenient, and people like convenience. Still, yes, were this to become standard (which I personally would dislike) I could see a lot more unspent complex-tx outputs sitting around.


Quote
But it's also not the entirely right question to ask here, because the chain doesn't just carry earnest transactions.  If someone wants to DOS attack bitcoin to make it unusable or ruin its decentralization, they'll use the cheapest method available to add the most immortal data to the blockchain. By reducing the amount of potentially immortal data needed in normal financial transactions we reduce that attack, because it is either easily distinguishable from normal transactions (thus subject to higher fees), or isn't as much data.

Hmm. I see your point.

Bitcoin is the ultimate freedom test. It tells you who is giving lip service and who genuinely believes in it.
...
...
In the future, books that summarize the history of money will have a line that says, “and then came bitcoin.” It is the economic singularity. And we are living in it now. - Ryan Dickherber
...
...
ATTENTION BFL MINING NEWBS: Just got your Jalapenos in? Wondering how to get the most value for the least hassle? Give BitMinter a try! It's a smaller pool with a fair & low-fee payment method, lots of statistical feedback, and it's easier than EasyMiner! (Yes, we want your hashing power, but seriously, it IS the easiest pool to use! Sign up in seconds to try it!)
...
...
The idea that deflation causes hoarding (to any problematic degree) is a lie used to justify theft of value from your savings.
makomk
Hero Member
*****
Offline Offline

Activity: 686
Merit: 564


View Profile
January 30, 2012, 10:21:38 PM
 #55

So apparently, despite the fact that the miners are currently getting to make the decision and are the ones most directly affected by the bugs resulting from the code being deployed in the way it has been, letting them decide is an attack on Bitcoin:

Quote
23:32 < gmaxwell> luke-jr: perhaps because you're in charge of 400GH of other people's hash power you're happy to say that a coinbase tally is the right way to determine support, but I don't think thats good for bitcoin.
23:34 < gmaxwell> If miners were to force this by simple majority of hashing power, but the community opposed it — we'd call that a 50% attack.

However, trying to give users enough information to make a decision is also apparently unnecessary and everyone should just trust the developers to make the right decision on their behalf. Sigh. Wonder if people have underestimated just how fundamentally Bitcoin relies on its developers remaining honest.

This isn't true.  Yes, Gavin created a bot that exploits a differential weakness of BIP17 vs BIP16. This was pretty helpful as luke was insisting there was no difference, and this let us feel out how the difference actually mattered.
On the other hand Gavin didn't even try and create a bot to exploit the weakness that exists in BIP16. It also took him quite a while to admit that he'd done it leaving everyone puzzled as to what was going on and who was doing it. (Either would have been quite easy to exploit on testnet and a bit harder to exploit elsewhere from what I recall; testnet isn't an entirely realistic place to test this kind of thing.)

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652
Merit: 2164


Chief Scientist


View Profile WWW
January 30, 2012, 10:42:08 PM
 #56

For context: makomk is the creator of CoiledCoin, a bitcoin alternative:
  https://bitcointalk.org/index.php?topic=56675

And RE: creating bots:  I created a BIP-17-stealing bot because it was really easy (took about 10 minutes of hacking).  A BIP-16-stealing bot would be a lot harder (because it would have to 'lie in wait' until the sender was redeeming the coins, and then race to relay/mine a 'stealing' version of the transaction before the rest of the network mined the original).

How often do you get the chance to work on a potentially world-changing project?
makomk
Hero Member
*****
Offline Offline

Activity: 686
Merit: 564


View Profile
January 30, 2012, 11:06:54 PM
 #57

For context: makomk is the creator of CoiledCoin, a bitcoin alternative:
  https://bitcointalk.org/index.php?topic=56675
For additional context, as a result of developing it I found and reported a couple of fairly nasty security vulnerabilities in the OP_EVAL implementation that BIP 16 could've inherited - though I believe Gavin may have already found and fixed the second one and just not notified the pools about it. Also, CoiledCoin has been dead for a long time now courtesy of luke-jr having more than 51% of the hash power and using it to block transactions. It's complicated and mostly irrelevant which is why I didn't mention CoiledCoin in the first place.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
markm
Legendary
*
Offline Offline

Activity: 2940
Merit: 1090



View Profile WWW
January 31, 2012, 12:33:24 AM
 #58

It seems to me that one of the arguments for these new transactions has been that two devices (device "Alice" and device "Bob", presumably in crypto parlance) cannot work together to make a secret that neither of them alone possess?

But I thought that in fact crypto has already solved the problem of how "Alice" and "Bob" can work together to create keys that enigher of them actually has solo ability to use?

Is that incorrect?

If not, then surely the standard way for Alices and Bobs to do such things can work on the device side without the chain having to know anything about it?

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
genjix (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1071


View Profile
January 31, 2012, 12:52:11 AM
 #59

My stance:

http://bitcoinmedia.com/cathartic-progress/

Michael Marquardt (theymos) suggests compiling a list of everyone intimate with the bitcoin protocol to invite to a two-week email discussion. After those two-weeks a vote is taken. It will be the job of the champions of each idea (BIP 16, BIP 17 and no change) to win over the committee into supporting them. If an idea has necessary support, bitcoin clients will be programmed to apply the new rules for 3 months in the future.
[Tycho]
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile WWW
January 31, 2012, 01:02:25 AM
 #60

Michael Marquardt (theymos) suggests compiling a list of everyone intimate with the bitcoin protocol to invite to a two-week email discussion. After those two-weeks a vote is taken. It will be the job of the champions of each idea (BIP 16, BIP 17 and no change) to win over the committee into supporting them. If an idea has necessary support, bitcoin clients will be programmed to apply the new rules for 3 months in the future.
Good idea, but it solves a problem that never existed (chosing between BIP16 and BIP17).

Welcome to my bitcoin mining pool: https://deepbit.net - Both payment schemes (including PPS), instant payout, no invalid blocks !
ICBIT Trading platform : USD/BTC futures trading, Bitcoin difficulty futures (NEW!). Third year in bitcoin business.
Pages: « 1 2 [3] 4 5 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!