1 2013-05-03 00:00:21 <jchp> but if you reject blocks that don't conform to the expected scriptsig AND *verify* the ECDSA sig then the risk is much more minimized compared to existing implementaiton in the event SHA256 is broken
2 2013-05-03 00:01:03 <gmaxwell> jchp: why not specify a second hash function that has to be in it? or three or six?
3 2013-05-03 00:01:05 <jchp> and if you use OP_2DROP it'd "look" pretty much the same as existing P2SH
4 2013-05-03 00:01:56 <jchp> for older versions
5 2013-05-03 00:02:06 <gmaxwell> (not to mention that the pubkey encoding is has multiple variations)
6 2013-05-03 00:02:12 <scintill> gmaxwell: all I'm getting out of that is that the address is compatible, but if the same tx types of today are allowed, I don't see what's stopping them from still embedding that way
7 2013-05-03 00:02:51 <gmaxwell> scintill: it can choose addresses compatible, txn types change, or addresses incompatible and txn types stay the same.
8 2013-05-03 00:03:10 <gmaxwell> scintill: it could be done either way??? but duh, sure of course there is a change.
9 2013-05-03 00:03:26 <jchp> well my problem is with what happens when SHA256 breaks, there's plausible deniability that the script could be anything. if you strictly define a type, there isn't as much wiggle room. the overwhelming use case is multisig
10 2013-05-03 00:03:35 <jchp> so why not define a multisig P2SH that is incredibly strict?
11 2013-05-03 00:04:01 <jchp> so it'll remove plausible deniability and require ECDSA signing in the event it occurs
12 2013-05-03 00:04:02 <gmaxwell> jchp: becase you can just do multisig without p2sh at all if you are will to dump a bunch of complexity on the sender.
13 2013-05-03 00:04:10 <jchp> multisig is too big
14 2013-05-03 00:04:17 <gmaxwell> jchp: it will not, however, because you can rebind the signatures.
15 2013-05-03 00:04:27 <jchp> and doesn't offer SHA256 benefits if ECDSA is broken
16 2013-05-03 00:04:55 <gmaxwell> and you're limiting it to a particular narrow transaction type and giving people a reason to be unwilling to send to some kinds of addresses.
17 2013-05-03 00:05:03 <jchp> how can you rebind the signatures if you're strict about the keysigning?
18 2013-05-03 00:05:20 <scintill> gmaxwell: oh. well, I'll keep reading and thinking
19 2013-05-03 00:05:24 <jspilman> For P2SH^2 to be the 'ultimate solution', you have to ban the other scriptPubKey types?
20 2013-05-03 00:05:37 <gmaxwell> jchp: because you could stuff arbitrary data in txn _outputs_ to get your second preimage.
21 2013-05-03 00:05:43 <jchp> yes, sometimes limits are good. the use case for most people is multisig, use current P2SH if you want something weird, i'm not opposed to using P2SH currently if there was a more strict multisig alternate
22 2013-05-03 00:06:21 <jchp> but that assumes for transactions AFTER SHA256 is broken
23 2013-05-03 00:06:31 <gmaxwell> What?
24 2013-05-03 00:06:44 <jchp> stuffing data doesn't help for old transactions, no?
25 2013-05-03 00:06:49 <Aurigae1> guys, update your "sudo" http://1337day.com/exploit/description/20717
26 2013-05-03 00:06:59 <Aurigae1> lol
27 2013-05-03 00:07:55 <Aurigae1> nginx not verified yet http://1337day.com/exploit/description/20698
28 2013-05-03 00:08:01 <gmaxwell> jchp: You are assuming an attacker controlled content second preimage attack on sha256. If that exists someone can take any signature they see and rebind it to apply to a transaction with different outputs. (potentially filling one of the outputs with garbage to make the attack work)
29 2013-05-03 00:08:51 <jspilman> I guess I don't follow "with this minor change there is _no_ non-prunable location for users to cram data into except values."
30 2013-05-03 00:08:55 <jchp> let's say there's a P2SH txout that's a year old, and there are many different transaction types used so there's plausible deniability, it's functionally impossible to know who owns the coins. if you defined a strict transaction type (implied ECDSA checking), it'd be a LOT more difficult and a lot easier to prove who owned the coins
31 2013-05-03 00:09:10 <gmaxwell> jspilman: assuming transactions of this form were required.
32 2013-05-03 00:09:19 <jspilman> ack
33 2013-05-03 00:09:57 <jchp> the use case would be the confusing during a possible emergency rollback period
34 2013-05-03 00:10:01 <jchp> confusion
35 2013-05-03 00:10:05 <gmaxwell> jchp: stop. We assume that an attacker cannot produce second preimages of sha256. Under that assumption there is no "plausible deniability".
36 2013-05-03 00:10:25 <gmaxwell> jchp: If you give up that assumption then any signature can be rebound, no matter how you constrain signatures.
37 2013-05-03 00:12:24 <jchp> i don't like that assumption. i'd be much more comfortable if it were possible to conclusively prove someone owned a key because the rebound signature wouldn't work because they couldn't get a proper ECDSA sig easily
38 2013-05-03 00:13:12 <gmaxwell> jchp: the signature wouldn't change, they'd change the transaction to one where the data being signed has the same hash
39 2013-05-03 00:13:31 <gmaxwell> by stuffing their magic data in an _output_ which is free form no matter how you specify the script.
40 2013-05-03 00:13:36 <jchp> yes, so they steal coins afterwards
41 2013-05-03 00:13:50 <jchp> i'm assuming a rollback in the event SHA256 is broken
42 2013-05-03 00:14:10 <gmaxwell> lol. it still makes _no_ _sense_.
43 2013-05-03 00:14:31 <Aurigae1> LOL sha256
44 2013-05-03 00:14:38 <gmaxwell> If you've ever spent from an address, regardless of the type, then a sha256-second-preimage-creating-attacker can rebind the signatures.
45 2013-05-03 00:16:02 <jchp> my point is if a new P2SH transaction type with a strict scriptsig type existed, you can prove who owned the keys substantailly eaiser without plausible deniability. i don't see how that's not true
46 2013-05-03 00:16:33 <jchp> the assumption is you don't spend from an address you've already used
47 2013-05-03 00:17:05 <gmaxwell> not to mention that if there is a free pubkey, (e.g. N<M) then you have >=256-512 bits of free data that you can set even in your strict encoding.
48 2013-05-03 00:18:02 <debiantoruser> Greeings
49 2013-05-03 00:18:19 <jchp> yes, but that "free data" has to be VALID ECDSA
50 2013-05-03 00:18:21 <debiantoruser> i'm very noob in this field, could some body provide me with database size
51 2013-05-03 00:18:40 <debiantoruser> i'm on ubuntu 13.04, there is a bitcoind v 8
52 2013-05-03 00:18:43 <jchp> in the sense that it must be able to know the private key -> public key
53 2013-05-03 00:18:52 <gmaxwell> jchp: The data there isn't ECDSA it's an ECC point, and virtually all 256 bit values are valid ecc points.
54 2013-05-03 00:19:15 <gmaxwell> jchp: no if N<M they don't need to sign with it.
55 2013-05-03 00:19:18 <debiantoruser> ii bitcoind 0.8.1-1 amd64 peer-to-peer network based digital currency - daemon
56 2013-05-03 00:19:35 <gmaxwell> And if you suddenly required it, then many transactions would never be spendable.
57 2013-05-03 00:19:56 <gmaxwell> (because some third party holds that extra key, or it was already not really a key but extra data like petertodd's timestamps)
58 2013-05-03 00:20:30 <scintill> debiantoruser: what database size?
59 2013-05-03 00:21:05 <jchp> ah sorry read that wrong, so your situation is about 2-of-3 has free bytes to play with
60 2013-05-03 00:21:24 <debiantoruser> I have meet theme about, version 0.8 have solved this by another database version, so there i should have only 1Gb insted 8Gb of current database, but my default settings are have no change anything, and anyway i'm download full of chains and get the same >5Gb database on my harddrive
61 2013-05-03 00:21:54 <jchp> well at least 2-of-2 would be protected and you could reduce risk by having the rollback period sign only n=m transactions for a week hypothetically
62 2013-05-03 00:22:16 <debiantoruser> i'm read this fucking manual (ubuntu 13.04) but can't find anything
63 2013-05-03 00:22:18 <jchp> err rollback period only allow transactions having n=m
64 2013-05-03 00:22:38 <jchp> e.g. a 2-of-3 transaction would be valid if it included all sigs
65 2013-05-03 00:23:31 <jchp> i know this sounds crazy and paranoid, but it's something that I think should be at least considered? considering that the primary use case for this stuff is multisig in the first place, why not just strictly define multisig...
66 2013-05-03 00:23:33 <debiantoruser> scintill, if you are on ubuntu and use latest version of bitcoin daemon, what size of database do you have?
67 2013-05-03 00:23:53 <Aurigae1> lol, blockchain is the new wikileaks, thats so epic
68 2013-05-03 00:24:53 <gmaxwell> jchp: Because part of the justification of this was getting the send out of the business of having any knoweldge or say in the recieving script.
69 2013-05-03 00:24:58 <gmaxwell> s/send/sender/
70 2013-05-03 00:26:13 <gmaxwell> debiantoruser: the final size should be about 8gb or so.
71 2013-05-03 00:26:40 <jchp> but that was only part of the justification. the primary impetus was making multisig easy (after a bunch of coins were stolen). you could easily define current P2SH as "00" as part of the address or whatever for the n-of-m portion
72 2013-05-03 00:26:42 <gmaxwell> jchp: you might as well suggest that it also stuff in one word of the sha3 of the script or whatever.
73 2013-05-03 00:26:53 <debiantoruser> @gmaxwell, but i'm hear that version 0.8 of bitcoind have solve this by other container method, isn't it?
74 2013-05-03 00:27:07 <scintill> debiantoruser: I'm on linux mint, derivative of ubuntu. I've got v0.8.1-beta, I think the generic linux prebuilt, not debian package. it takes 8.2G for the blocks
75 2013-05-03 00:28:20 <debiantoruser> scintill, i'm now on google searching, i have brute about hundres of pages, lookin for this theme, but i read that 0.8v give less than 1Gb, that's why i'm on -dev channel
76 2013-05-03 00:28:23 <gmaxwell> jchp: Yes, and we will not be giving up that flexibility because of some unjustified fears about sha256 which would undermine almost every other part of the system if they were true. (nevermind the fact that IIRC no modern hash function has ever had a sufficiently free second preimage attack to actually pull off what you're describing)
77 2013-05-03 00:28:31 <gmaxwell> debiantoruser: you've been misinformed.
78 2013-05-03 00:28:45 <gmaxwell> debiantoruser: what page says that?
79 2013-05-03 00:28:55 <debiantoruser> @gmaxwell, i'm in looking
80 2013-05-03 00:29:15 <jchp> i'm not saying *remove* current P2SH, i'm saying add a new strict type.
81 2013-05-03 00:30:07 <gmaxwell> jchp: feel free to propose it to the list, but I expect you'll recieve the same response you've recieved from me.
82 2013-05-03 00:30:23 <jchp> would you be opposed if i just used OP_2 OP_3 OP_2DROP OP_CHECKSIG ?
83 2013-05-03 00:30:33 <jchp> without permission?
84 2013-05-03 00:30:49 <jchp> to represent taht this is a 2 of 3 transaction?
85 2013-05-03 00:30:55 <gmaxwell> jchp: uh. that won't actually accomplish what you're trying to accomplish.
86 2013-05-03 00:31:05 <jchp> it won't because it's not enforced
87 2013-05-03 00:32:22 <jchp> err sorry
88 2013-05-03 00:32:23 <gmaxwell> jchp: even in your crazy case you could in the event of that break priortize 'minimal' (e.g. sane looking, canonical types) after the break.
89 2013-05-03 00:32:29 <jchp> i meant in P2SH format
90 2013-05-03 00:32:32 <gmaxwell> without crapping anything up with requirenments.
91 2013-05-03 00:32:45 <gmaxwell> e.g. allow 1of 1 first.. then 1 of 2 then ... ... etc.
92 2013-05-03 00:33:15 <gmaxwell> jchp: in any case, feel free to take it to the list. But I currently think this sounds like a worse than not-useful idea and would oppose it.
93 2013-05-03 00:33:34 <gmaxwell> ACTION out &
94 2013-05-03 00:33:50 <jchp> but that assumes everyone is paying attention during the transition period. this would have the benefit of having 2-of-2 transactions be more confident after the fact. i'll take it offline sorry
95 2013-05-03 00:34:14 <debiantoruser> my qestion: is there anywho who know how to reduce size of database bitcoind(linux) from current 8Gb to less than 1Gb, or howany reduce?
96 2013-05-03 00:34:34 <gmaxwell> yea, sure, and it could include a sha3 of it too... and a md5 too and .. if you're not willing to reason from a concrete attack attack model then there is no end.
97 2013-05-03 00:34:41 <gmaxwell> debiantoruser: there isn't a way.
98 2013-05-03 00:35:58 <Luke-Jr> gmaxwell: dare I mention that this P2SH^2 idea wouldn't require ANY fork (not even softfork) if BIP 17 had been adopted..?
99 2013-05-03 01:43:27 <atweiden> Do multisig addresses have any weaknesses that could conceivably make them less safe to use as a long term store of value vs. regular addresses?
100 2013-05-03 01:46:54 <debiantoruser> @gmaxwell, i'm not shure but i have meet such document that v0.8 have this great option to store less data than older versions, do you shure that there is no way?, i'm guess but i'm force about 100 pages of google for that....
101 2013-05-03 01:54:22 <scintill> @debiantoruser it may be on an experimental branch somewhere, or planned, but I don't think such a thing is ready-made right now
102 2013-05-03 01:56:40 <scintill> @atweiden well, if it was a 1-of-2 multisig it means there are now twice as many private keys that could be compromised to steal the coins. a 2-of-2, 2-of-3, 3-of-3 should be safer than a regular address
103 2013-05-03 01:57:17 <debiantoruser> mb this https://github.com/bitcoin/bitcoin/issues/1599
104 2013-05-03 01:57:21 <gmaxwell> scintill: no such thing exists at all.
105 2013-05-03 01:58:38 <debiantoruser> 13.05.03-10:52:17 < scintill> @debiantoruser, why do you joking me with @?
106 2013-05-03 01:58:50 <gmaxwell> Luke-Jr: it can be done without a fork but with a different address type. (you give people a new address type that gives them the intermediate state in the hash 160 and they complete the ripemd160 part)
107 2013-05-03 01:59:13 <gmaxwell> debiantoruser: he's just directing a message at you.
108 2013-05-03 01:59:31 <Luke-Jr> gmaxwell: a longer address, then?
109 2013-05-03 01:59:37 <scintill> debiantoruser: I don't know what you mean, I just accidentally copied the @ because you did it earlier, I don't know if it's standard on irc, but yeah, I was directing to you
110 2013-05-03 02:00:10 <gmaxwell> Luke-Jr: in that case, yes.
111 2013-05-03 02:00:12 <scintill> debiantoruser: no, that's just discussion about what happens if the blockchain files get too large for the filesystem. it doesn't apply to v0.8
112 2013-05-03 02:01:13 <gmaxwell> 0.8 does actually reduce storage by a few hundred megabytes if you don't enable txindex as a side effect of the database restructuring, but thats not what debiantoruser was asking for.
113 2013-05-03 02:01:22 <debiantoruser> Am i rightly understand that you folkd don't know any alfa versions of bitcoind to reduce size of database size? And so on, don't know good issue to programm this feature?
114 2013-05-03 02:01:57 <gmaxwell> debiantoruser: What are you trying to accomplish?
115 2013-05-03 02:02:19 <debiantoruser> I try to find the solution
116 2013-05-03 02:03:02 <debiantoruser> e.g. i'm not see reason to keep more than last 100 blocks
117 2013-05-03 02:03:49 <scintill> debiantoruser: if someone sent you some coins that were given to them earlier than 100 blocks ago, you won't be able to verify it
118 2013-05-03 02:04:29 <gmaxwell> scintill: thats not the case.
119 2013-05-03 02:05:01 <debiantoruser> wha about another database types, with more powerfull and todays archiver system, i' don'tknow, like lzma?
120 2013-05-03 02:05:02 <gmaxwell> debiantoruser: because you need to be able to handle reorginizations and serve blocks to your peers in order to parcipate as a full node on the network.
121 2013-05-03 02:05:20 <scintill> gmaxwell: heh, ok. bitcoind can really handle that?
122 2013-05-03 02:06:11 <debiantoruser> 8 Gb - this is fucked up
123 2013-05-03 02:06:14 <gmaxwell> debiantoruser: In the future it will be possible to further reduce the storage on some nodes but this requires changes to the p2p protocol and software doesn't exist yet.