sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
Chris_Stewart_5 has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
jtimon has quit [Ping timeout: 276 seconds]
<Yogh>
BlueMatt: very much looking forward to that 3 minute talk you're presenting ;)
cyphase_eviltwin has quit [Ping timeout: 250 seconds]
cyphase has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
Pr0t3us has joined #bitcoin-wizards
Pr0t3us has quit [Remote host closed the connection]
Alopex has quit [Remote host closed the connection]
angel2710 has joined #bitcoin-wizards
jtimon has quit [Ping timeout: 276 seconds]
Alopex has joined #bitcoin-wizards
grubles has quit [Ping timeout: 260 seconds]
Noldorin has quit [Ping timeout: 265 seconds]
Alopex has quit [Remote host closed the connection]
aj has quit [Quit: .]
Alopex has joined #bitcoin-wizards
grubles has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
spudowiar has joined #bitcoin-wizards
spudowiar has left #bitcoin-wizards ["Leaving."]
Noldorin has joined #bitcoin-wizards
aj has joined #bitcoin-wizards
Noldorin has quit [Max SendQ exceeded]
GAit has quit [Quit: Leaving.]
Chris_Stewart_5 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 250 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
<Taek>
I am also interested
NewLiberty_ has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 250 seconds]
Giszmo has quit [Quit: Leaving.]
angel2710 has quit []
rusty2 is now known as rusty
Alopex has quit [Remote host closed the connection]
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
pro has quit [Quit: Leaving]
Samdney has quit [Quit: Verlassend]
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Quit: WeeChat 0.4.2]
mdavid613 has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
mdavid613 has quit [Quit: Leaving.]
instagibbs has quit [Ping timeout: 244 seconds]
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
lvns has joined #bitcoin-wizards
edvorg has joined #bitcoin-wizards
byteflame has quit [Ping timeout: 276 seconds]
byteflame has joined #bitcoin-wizards
edvorg has quit [Ping timeout: 250 seconds]
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
Guest58710 has quit [Ping timeout: 250 seconds]
chjj has quit [Ping timeout: 276 seconds]
metric has joined #bitcoin-wizards
metric is now known as Guest91507
Ylbam has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
MoALTz has quit [Ping timeout: 244 seconds]
instagibbs has joined #bitcoin-wizards
BashCo has quit [Remote host closed the connection]
kyletorpey has quit [Quit: Leaving.]
lvns has quit [Remote host closed the connection]
BashCo has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
nullfxn has quit [Ping timeout: 276 seconds]
jtimon has quit [Ping timeout: 260 seconds]
rusty has quit [Ping timeout: 265 seconds]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
rubensayshi has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
paveljanik has quit [Quit: Leaving]
lvns has joined #bitcoin-wizards
lvns has quit [Remote host closed the connection]
lvns has joined #bitcoin-wizards
bildramer has quit [Ping timeout: 258 seconds]
bildramer has joined #bitcoin-wizards
MoALTz has joined #bitcoin-wizards
jannes has joined #bitcoin-wizards
pro has joined #bitcoin-wizards
rusty2 has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 265 seconds]
MoALTz has quit [Ping timeout: 244 seconds]
edvorg has joined #bitcoin-wizards
Giszmo has joined #bitcoin-wizards
rusty2 has quit [Ping timeout: 244 seconds]
lvns has quit [Remote host closed the connection]
lvns has joined #bitcoin-wizards
byteflame has quit [Ping timeout: 276 seconds]
jtimon has joined #bitcoin-wizards
lvns has quit [Remote host closed the connection]
bildramer1 has joined #bitcoin-wizards
Samdney has joined #bitcoin-wizards
bildramer has quit [Ping timeout: 255 seconds]
yorick_ is now known as yorick
Mazz_ has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
Noldorin has joined #bitcoin-wizards
byteflame has joined #bitcoin-wizards
bildramer1 is now known as bildramer
Noldorin has quit [Ping timeout: 260 seconds]
paveljanik has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
GAit has joined #bitcoin-wizards
helo_ is now known as helo
GAit has quit [Client Quit]
byteflame has quit [Ping timeout: 244 seconds]
morcos has quit [Quit: leaving]
GAit has joined #bitcoin-wizards
defrag has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
GAit has joined #bitcoin-wizards
jtimon has quit [Read error: Connection reset by peer]
jtimon has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
superkuh has joined #bitcoin-wizards
cyphase has quit [Ping timeout: 255 seconds]
GAit has quit [Quit: Leaving.]
cyphase has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 250 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
morcos has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 265 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
bildramer1 has joined #bitcoin-wizards
bildramer has quit [Ping timeout: 250 seconds]
chjj has quit [Ping timeout: 240 seconds]
rubensayshi has quit [Remote host closed the connection]
cyphase has quit [Ping timeout: 265 seconds]
edvorg has quit [Remote host closed the connection]
MoALTz has joined #bitcoin-wizards
Guyver2_ has joined #bitcoin-wizards
cyphase has joined #bitcoin-wizards
edvorg has joined #bitcoin-wizards
edvorg has quit [Remote host closed the connection]
Guyver2 has quit [Ping timeout: 252 seconds]
Guyver2_ is now known as Guyver2
Chris_Stewart_5 has quit [Ping timeout: 265 seconds]
cyphase has quit [Ping timeout: 250 seconds]
cyphase has joined #bitcoin-wizards
lvns has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
mdavid613 has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 250 seconds]
GAit has quit [Quit: Leaving.]
cyphase has quit [Ping timeout: 260 seconds]
cyphase has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
GAit has quit [Quit: Leaving.]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
cyphase has quit [Ping timeout: 255 seconds]
cyphase has joined #bitcoin-wizards
PaulCapestany has joined #bitcoin-wizards
<petertodd>
Has anyone investigated the security of SHA256 midstates? Seems sketchy to essentially let the attacker pick the initialization constants.
<petertodd>
For example, if you were to create a timestamp commitment via a midstate, can the attacker choose one that makes a preimage attack easier?
<petertodd>
0 retweets 0 likes
GAit has joined #bitcoin-wizards
<e0_>
When is someone allowed to pick the midstates?
<e0_>
do you mean chaining variable?
<petertodd>
e0_: if you are the verifier, and you don't have the full data, then the attacker can pick the midstate at will without you being able to know
PaulCape_ has quit [Ping timeout: 264 seconds]
<e0_>
ok, so someone sends you a SHA256 chaining variable and the inputs that extend the chaining-variable to the final output?
<petertodd>
e0_: yup
<petertodd>
e0_: case in point being timestamp proofs, where the attacker would want to choose the midstate such that finding a second message with the same hash is made easier
wangchun has quit [Remote host closed the connection]
<katu>
petertodd: yes. your "midstate" generally fall into the category of length extension attacks (not the simple case of bypassing authentication though).
<e0_>
Midstate clearly leverages length extention but granting an attacker the ability to pick a chaining variable without having to show how that chaining variable was generated is pretty powerful.
<katu>
chosen-iv is practical only for sha1 at the moment, though.
<e0_>
yes, free state collisions
<gmaxwell>
petertodd: it seems almost certian to me that it reduces security, which is one of the reasons I've shyed away from constructions that use that trick.
<petertodd>
katu: they're similar to length extension attacks, but they may be even worse: remember that sha256 starts with a nothing-up-my-sleeve number, and midstates let the attacker bypass that and choose the initialization conditions at will
<e0_>
exactly
<katu>
petertodd: if it's pure chosen-iv that sounds incredibly dangerous. as i said, sha1 is already broken under that precondition.
<petertodd>
gmaxwell: yeah, it's a surprisingly big change to the algorithm
<gmaxwell>
katu: sha1 is a much more linear construction, however.
<e0_>
as someone involved in hash function cryptanalysis, such a protocol would make my job easier
<petertodd>
katu: you're familiar with what the midstate concept is right? it's simply where you provide the internal state of the SHA256 computation as your "prefix", and the suffix is the rest of the message. So yes, it's basically a chosen-iv
<sipa>
but we're still only interested in preimage attacks, right?
<sipa>
so the case where an attacker sees an existing published hash, and constructs an initial state + suffic that hash to that published value
<e0_>
@katu and it isn't just choosen-IV, as the length of the message is included to the padding
<petertodd>
sipa: for timestamping, yes! because a birthday collission still proves that both messages existed prior to some point in time!
<katu>
petertodd: im not sure where that scenario arises, though, ie attacker having completely free choice. taking apart hash function for spare parts like that and doing something silly with it ... isnt that explicitly forbidden via "dont roll your own crypto if you dont need to"? :)
<sipa>
an attacker being able to construct two different initial states + suffix that both hash to the same thing... well, good for him, now he can timestamp two values from the price of one
<petertodd>
katu: this is used in production by p2pool to make shares more compact, and I've seen people propose it for timestamping
<sipa>
the relevant of length extension attacks is usually wrt collisions, not preimages
<katu>
ouch
<petertodd>
katu: I'm not sure it actually would matter for p2pool, but using it for timestamping seems very unwise to me...
cyphase has quit [Ping timeout: 250 seconds]
<petertodd>
sipa: yeah, timestamping is weird that way :)
<katu>
another scenario (with sha1) is compactly representing single file in a torrent
<sipa>
so the question is really whether you're able to invert a single sha256 transform
<e0_>
p2pool is basically rolling their own crypto primatives. Without someone spending a very long time thinking about it, no one knows how secure it is.
<katu>
you need to keep sha1 midstate for preceding and trailing chunk.
<petertodd>
sipa: yup
chjj has joined #bitcoin-wizards
<gmaxwell>
e0_: for that if it were somewhat broken it would hardly matter.
<sipa>
if the data being hashed (or claimed to be hashed) is unconstrained, this is essentially a problem with 256 bits known, and 768 bits variable
<sipa>
as opposed to the typical preimage attack problem where you have 256 bits known and only 512 bits variable
TheSeven has quit [Ping timeout: 250 seconds]
<katu>
e0_: it's ok if it is some hack on top of existing protocol (ie see the example of representing file in a torrent - there simply isnt other option), i just cant imagine why p2pool would actually need it.
<gmaxwell>
katu: because its a hack on top of the bitcoin protocol.
TheSeven has joined #bitcoin-wizards
<petertodd>
sipa: right, because you get the extra degree of freedom in the 256 bits of midstate
<sipa>
exactly
<sipa>
i don't know whether this matters, but it may be important to realize that this is fundamentally an easier problem than a preimage attack
<sipa>
(though, even in the presence of known collision attacks, this construction is not necessarily broken)
<gmaxwell>
not quite. that was forrestv trying to generalize it.
<e0_>
katu: I don't think it is ok, These things are really tricky, just understanding the exact security properties you want is an involved task. Determining if a modification of a crypto primative meets that property requires long term research. There is a reason that SHA-3 was run as a multi-year contest with many cryptographers looking at each hash function.
<gmaxwell>
When you attempt a share, you need to reveal the user-id and sharechain root that it commits to. This information is at the end of the coinbase transaction, which is some 15kbytes of data. It's not important to communicate that first 15kb when initially connecting the share to the share chain. Once you've verified it, and connected it, the rest of the data in the coinbase transaction is a funct
chjj has quit [Ping timeout: 240 seconds]
<gmaxwell>
ion of the sharechain, and all that is verified too.
<gmaxwell>
So as-I-vaguely-recall the way it's used in p2p is even if it's totally busted it only results in a CPU exhaustion DOS attack against p2pool nodes at worse (by flooding them with non-p2pool shares that you've made look like p2pool shares)
<katu>
e0_: in both cases, there is clear cost benefit. the hash is broken apart to achieve something, and explicitly acknowledging 'yep, that breaks the hash'. but both in case of merged mining and bittorrent, it seems the widened attack surface is worth it.
<gmaxwell>
s/used in p2p/used in p2pool'
<katu>
e0_: most importantly, in neither case the hash is used to hash a secret, but only commitment. commitment which is later re-verified by doing proper hash.
<gmaxwell>
but people have tried to do this elsewhere, where stronger properties were needed and where the use had greater consequences, and I've discouraged it for the reasons e0_ mentions.
<e0_>
katu: I have no idea of the cost benefit analysis. My only point is that may not be safe or secure.
<gmaxwell>
katu: fwiw, 'don't make your own constructs' I think that is advice which is causing harm. At one level it's obviously good but the way people apply it is that they can take random black box standardized cryptographic objects found on github and apply them and then think they're doing fine.
priidu has joined #bitcoin-wizards
<gmaxwell>
At least in the realm of open protocols on the internet it has been well over a decade since there was a major example of someone cooking up their own blockcipher. But over and over again we see people every day cooking up busted protcols and using implementations of standard constructs with gratitious sidechannel vulerabilities in places where it might matter.
<gmaxwell>
So I liken that advice to "abstence only" cryptography education, it has similar failure modes to its parallel in human sexuality.
cyphase has quit [Ping timeout: 255 seconds]
<bsm117532>
gmaxwell: I've been thinking that for some time. The adage "don't roll your own crypto" is really incompatible with crypto-financial engineering. Instead we need to figure out how to do software engineering, using cryptography, in a secure manner.
<katu>
gmaxwell: you're criticizing fundamental problem of computer engineering. yes, commodity solutions are sub-optimal, but typically with better outcomes than people rolling stuff on their own.
<katu>
from scratch. every time.
<bsm117532>
Just passing the buck sucks.
<gmaxwell>
katu: no.. it's orthorgonal.
laurentmt has joined #bitcoin-wizards
<petertodd>
incidentally, it occures to me that for some applications, it to require the midstate to be followed by a fixed "pseudo-iv" - although whether or not that's actually secure is beyond my paygrade
<petertodd>
*it'd be feasible to require the
<gmaxwell>
katu: I'm not complaining that AES isn't the best fit function for some application or whatnot. But rather the mindset that you are safe _if_ and only if you use something that you think is standardized. The overwhelming majority of cryptographic breaks come from bad protocol design, and there are virtually no well studied protocols for pratically any engineering. So people just say 'the crypto i
<gmaxwell>
s the [AES] the protocol is not crypto. I can write that without understanding crypto.' with bad results.
<sipa>
i think what gmaxwell is saying that people who just take off-the-shelf crypto primitive *also* make mistakes... for example AES without authentication, or with sidechannels
BashCo has joined #bitcoin-wizards
<sipa>
jinxed
<sipa>
so the advice should be to always research the various attack vectors and security assumptions
cyphase has joined #bitcoin-wizards
<sipa>
and when you're digging deeper in the stack, the difficulty of that goes up
<katu>
gmaxwell: fiar enough. the advice for crypto-ignorant people should definitely extend to usage too. which is, adhere to predefined protocol spec, just like primitives.
<sipa>
but it's not a boolean
<gmaxwell>
Yes, there is no replacement for having a degree of understanding. And if you do, you will also realize that there is no way you're going to cook up your own replacement for AES.
<petertodd>
gmaxwell: note how far NaCl has to go to create an API that's "sufficiently safe" to use without a solid understanding of it, and in the process they've made something where it's not clear how you'd use it for consensus - as an example
chjj has joined #bitcoin-wizards
<katu>
sipa: worst with AES i've seen in practice is key-similiarity attacks.
<katu>
its not often stressed enough, just *dont* have similiar keys for aes, ie hash those before using.
<gmaxwell>
katu: uh. no. people use AES-CTR and then reuse keys/iv.
<katu>
gmaxwell: thats not aes as such, but ctr :)
<gmaxwell>
Or they use CBC without an IV and yield fingerprinting attacks (linux disk encryption and truecrypt too)
<sipa>
AES-ECB is totally safe, right?
<gmaxwell>
or they use AES-ECB
<katu>
all the chained modes are pretty tricky
<sipa>
gmaxwell: which reminds me, we should add CBC to ctaes
<gmaxwell>
katu: but aes without a chaining mode is not fit for basically any application.
<katu>
or generally the poor understanding of word 'nonce'
<katu>
that which should not appear twice
<sipa>
nwice
<katu>
(bitcoin with its 'nonce' isnt helping, shouldnt that be serial or something :)
laurentmt has quit [Quit: laurentmt]
<petertodd>
sipa: I use ECB because I believe in block equality
<e0_>
If you are designing cryptographic protocols you need an expert. I'm all for experimentation and playing around with building your own crypto, but getting it right and knowing when you got it wrong requires a person that has dedicated many years of the life as a full time job learning how to securely engineer crypto.
<katu>
e0_: yeah, just make robust cookiecutters for protocols too
<katu>
isnt that basically what nacl is all about?
<e0_>
I think robust cookiecutters are good idea, but often projects will require a usercase not supplied by the cookiecutter.
<e0_>
Even standardized protocols have serious problems.
<bsm117532>
e0_ let's educate, instead of passing the buck though. Lots of dev shops have obtuse (non-crypto) programming rules and frameworks that try to prevent programmers from shooting themselves in the foot -- I think this is largely foolish. Don't treat people like idiots, educate them instead.
<gmaxwell>
e0_: but that isn't the standard advice, the standard advice is some kind of abstence cult; not a hire an expert cult. :P
<e0_>
If apple can't get imessage right, and they couldn't, who can?
<gmaxwell>
There are basically no secure standardized protocols for anything non-trivial.
<e0_>
gmaxwell: I don't agree with the abstence view.
<e0_>
right
<katu>
bsm117532: the midstte sha is a good example though. it goes against advice "dont reinvent crypto". but in cases when it is actually used, it is acknowledged the hash is broken. for cases such as those, i'd simply standardize use of mid-hashes for sha1/sha2.
<waxwing>
apparently we are abstaining from spelling out the word abstinence too :)
<katu>
also possibly have cryptanalist outlien to which degree is the hash broken.
<katu>
damn, too many typos to regex through
<bsm117532>
I think there do not exist enough cryptographers in the world to transition to cryptographic finance. We're all going to have to bite the bullet and learn more about midstates...
<gmaxwell>
I don't think midstate compression is much _more_ an "act of cryptography" than, say, coming up with your hashtree structure.
<gmaxwell>
even when your hashtree doesn't peel back the crypto black box boundaries at all.
wangchun has joined #bitcoin-wizards
<katu>
gmaxwell: depends, it's just a single primitive with valid use (put a wedge to hashlist/md tree).
<e0_>
midstate compression is very dangerous because it opens the door to fine grained control of variables in the hash function which are assumed to not be under the control of an attacker
<katu>
s/to/into/
<e0_>
like BLAKE has "interesting" behavior if an attacker can control the chaining variables
<katu>
e0_: it needs to be evaluated to which degree it is hard to produce evil states. as it is now, it is assumed "reasonably hard to stave off DoS"
<gmaxwell>
for example, we sit here and cringe with the midstate compression but haven't encountered a pratical attack. But the hashtree construction used in Bitcoin has _three_ known vulnerabilties, and one is pratical and easily exploited.
cyphase has quit [Ping timeout: 244 seconds]
<gmaxwell>
So I think being horrified by one but not blinking at the other is being pennywise and pound foolish.
* sipa
googles "pennywise -band"
<petertodd>
gmaxwell: one potential difference, is that explaining the vulnerabilities in bitcoin's hashtree is easy - for that matter, even a relatively unsophisticated person could find them too
<e0_>
I wasn't aware of the problems with the hashtree, but that sounds bad as well =/
<gmaxwell>
petertodd: many attacks sound pretty obvious in hindsight, look at the attacks on 64-bit block ciphers in SSL.
<petertodd>
gmaxwell: I feel perfectly confident designing a hashtree precisely because the vulnerabilities in bitcoin's one are obvious to me with my current level of knowledge; I don't have a damn clue what makes sha256 work
<petertodd>
gmaxwell: sure, what I mean is simply that my level of knowledge for hashtrees is likely a lot closer to that of experts in the field than it is for designing hash functions from scratch
<sipa>
well there is no clear algorithmic hardness assumption for sha256
<sipa>
it's just a mix of permutations and non-linear operations
<petertodd>
sipa: aka, black magic :P
<sipa>
yes, pretty much
<sipa>
there is a large collection of understanding about what kinds of constructions lead to easy attacks
<sipa>
and hash function design is mostly just avoiding that, and then doing enough of it :)
<gmaxwell>
yes, but consider, if sha256 midstate compression were _completely_ broken it would very likely have manifest itself in other ways and would have been noted elsewhere. The midstate extension property is not intended interface of sha256 but it's highly related to extension attacks.
<katu>
sipa: those can be definitely expressed and mathematically solved, as a SAT problem or polynomial in extended gf(2)
<katu>
the trick is, how big are those sat/poly?
<katu>
satcoin might hint some interesting answers
cyphase has joined #bitcoin-wizards
<gmaxwell>
there is no strong argument provided by anyone that I'm aware of that says that second preimages results in a sat problem which is hard. Other than the hope that if it didn't the extensive cryptanalysis so far would have uncovered it.
<sipa>
assuming sha256 is not broken in any way that isn't known now, i don't expect midstates to be trivially attackable
<gmaxwell>
doesn't mean using it is a good idea generally.
<sipa>
but they may be somewhat easier than a full sha256 premiage
<petertodd>
sipa: an interesting question then, is given the desire for nothing-up-your-sleeve numbers, why didn't the sha256 designers just use zero's as the IV?
<e0_>
there has been some success on free-start collisions on SHA256 in reduced round varients
<sipa>
petertodd: sha3 uses all zeroes as initial state :)
<petertodd>
sipa: lol, nice :)
<gmaxwell>
sipa: I would be shocked if it weren't easier, and shocked if it made any interesting attack easy.
<sipa>
gmaxwell: agree
<sipa>
a massively easy midstate attack would likely indicate a full preimage attack
<e0_>
SHA3 is also a completely different construction
<gmaxwell>
e0_: he wasn't giving that as a justification. :)
<petertodd>
e0_: yup, just reading that section now - sounds like pretty clear evidence that freedom in the IV is at least a negative
<katu>
sipa: well, for example in case of sha1 thats not strictly the case. chosen-ivs seem to be pretty magical, and whole security of sha1 now lies in that its difficult to arrive to this fixed point when attempting to produce real world collisions.
bsm117532 has quit [Ping timeout: 250 seconds]
<katu>
ie what if you dont get a wide class of chosen-ivs as options, but something very very specific
tucenaber has quit [Ping timeout: 276 seconds]
GAit has quit [Read error: Connection reset by peer]
<andytoshi>
thanks roasbeef .. though i think that is too simplified for what i'm doing, and it also predates a lot of important work in pairing-based crypto (in particular freeman's unification of several families of curves that support pairings, and lynn's thesis)
c0rw1n has joined #bitcoin-wizards
c0rw1n has quit [Read error: Connection reset by peer]
c0rw1n_ has joined #bitcoin-wizards
Davasny has joined #bitcoin-wizards
chjj has quit [Ping timeout: 264 seconds]
cyphase has quit [Ping timeout: 264 seconds]
blackwraith has joined #bitcoin-wizards
priidu has quit [Ping timeout: 250 seconds]
cyphase has joined #bitcoin-wizards
cyphase has quit [Ping timeout: 276 seconds]
cyphase has joined #bitcoin-wizards
parathon has joined #bitcoin-wizards
parathon has quit [Client Quit]
byteflame has joined #bitcoin-wizards
cyphase has quit [Ping timeout: 276 seconds]
cyphase has joined #bitcoin-wizards
byteflam1 has joined #bitcoin-wizards
byteflam1 has quit [Client Quit]
byteflame has quit [Quit: leaving]
byteflame has joined #bitcoin-wizards
rusty2 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 250 seconds]
cyphase has quit [Ping timeout: 252 seconds]
cyphase has joined #bitcoin-wizards
bildramer has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
bildramer1 has quit [Ping timeout: 250 seconds]
laurentmt has quit [Quit: laurentmt]
Chris_Stewart_5 has joined #bitcoin-wizards
byteflame has quit [Ping timeout: 250 seconds]
jrayhawk_ is now known as jrayhawk
cyphase has quit [Ping timeout: 240 seconds]
<kanzure>
in dagchain designs, is there anything particularly broken about having long weak block chains that eventually get reorged into stronger chains? potentially conflicting transaction trees can be excluded (or one side can be picked/favored by the miner of the non-weak pow chain that reincorporates most of the weak chain results).
Chris_Stewart_5 has quit [Quit: WeeChat 0.4.2]
<bsm117532>
Nothing in particular and in fact I'm planning on that.
<bsm117532>
However it requires that you can identify conflicting transactions, so is not compatible with aggregation a la Mimblewimble.
<kanzure>
oh wait-- so the particular problem would have to be something like: an attacker can trivially broadcast their different transaction to different long weak chains. but this is more the fault of a user that believes a weak confirmation is valuable.
<bsm117532>
Correct.
<kanzure>
what is the value of the weak confirmation (in the context of long weak chains) at all?
<bsm117532>
The notion of "confirmation" changes and requires a more sophisticated calculation. I'm planning on using a "high water mark" which is an indication of the maximum hashpower that could be on a weak chain.
<bsm117532>
If you're on a weak chain (any chain where the highest hashpower ever see is 100% larger than what is currently visible) -- transactions NEVER confirm.
<bsm117532>
...until they're merged with the stronger chain.
kyletorpey has joined #bitcoin-wizards
cyphase has joined #bitcoin-wizards
<kanzure>
i suppose you could make handwavy incentive arguments about miners wanting to take a portion of fees that might not otherwise happen without the transaction trees included in the (longer) weak chains
<bsm117532>
This allows one to automatically and generically merge chains in the case of e.g. network splits.
<Taek>
kanzure: it depends on the algorithm that you use to merge weaker chains into longer chains
<bsm117532>
Miner coin allocation also uses the high-water-mark.
<Taek>
but, generally speaking I believe that either the weaker chain has to be orphaned, or it can cause reorgs of depth up to the size of the weaker chain
<bsm117532>
Though there may be other ideas, and as Taek says, it comes down to your conflict resolution at merge time.
<Taek>
I'm also worried about the algorithmic complexity of merging
<Taek>
it you can merge weak chains that are thousands of blocks behind, your conflict resolution may get intractable
cyphase has quit [Ping timeout: 250 seconds]
cyphase has joined #bitcoin-wizards
Tenhi_ has joined #bitcoin-wizards
Guyver2 has quit [Read error: Connection reset by peer]
belcher has quit [Ping timeout: 264 seconds]
belcher has joined #bitcoin-wizards
cyphase has quit [Ping timeout: 276 seconds]
Tenhi_ has quit [K-Lined]
cyphase has joined #bitcoin-wizards
oleganza has joined #bitcoin-wizards
<oleganza>
Hi there. A friend asked if we it's a good idea to slap MAC onto the payload in the CT range proof. I think the ring signature is effectively a MAC on the ciphertext (yielding "encrypt-then-mac" method), so no more integrity checks are necessary, is that right?
rusty2 has quit [Ping timeout: 276 seconds]
MoALTz has quit [Quit: Leaving]
<andytoshi>
oleganza: heya. yeah, the ringsig itself is effectively a MAC. you still might wanna checksum the data as a sanity check (in case of corruption before it went into the ringsig or after it came out)
<oleganza>
in other words, how much is schnorr ring signature malleable by non-signers? IMHO, a simple check like "enforce low-s" should suffice
<andytoshi>
don't even need low-s with schnorr, it's not malleable at all
<e0_>
I assume someone else has already thought of this but you can reduce the expected-loss of a user doublespending a 0-confirmation transaction once transactions maleability is solved.
<e0_>
Alice wants to pay Bob for a coffee by paying 0.001 BTC in transaction T1 but doesn't want to wait for a confirmation. Bob asks Alice to spend 10 BTC into a 2-of-2 transaction spendable only by both Alice and Bob's key. Bob creates and signs a refund transaction for the 2-of-2 which also spends 0.00001 BTC from T1. Thus, if T1 is doublespent Alice loses 10 BTC since the refund is invalid but if T1 is confirmed on the blockchain Alice can reclaim her 1
<e0_>
if the 2-of-2 is spendable by Bob's key alone after say 2 weeks, Bob merely needs to calculate the probability that both the 2-of-2 and T1 and doublespent and choose a 2-of-2 insurance value which gives him an expected value of 0.001 BTC.
morcos has quit [Remote host closed the connection]
cyphase has quit [Ping timeout: 260 seconds]
rusty2 has quit [Ping timeout: 244 seconds]
pavel_ has joined #bitcoin-wizards
paveljanik has quit [Ping timeout: 244 seconds]
cyphase has joined #bitcoin-wizards
vega4 has quit [Ping timeout: 240 seconds]
moli has joined #bitcoin-wizards
belcher is now known as JM-IRCRelay
JM-IRCRelay is now known as belcher
<CocoBTC>
Not in this way - but AFAIK pre-made transactions are a part of how Lightning network will work with "HTLCs"
cyphase has quit [Ping timeout: 255 seconds]
cyphase has joined #bitcoin-wizards
morcos has joined #bitcoin-wizards
<e0_>
CocoBTC: what do you mean by "pre-made". I was thinking that this method could be used to quickly establish a payment channel with the lightning network.
xissburg has quit [Quit: leaving]
xissburg has joined #bitcoin-wizards
vega4 has joined #bitcoin-wizards
vega4 has quit [Client Quit]
vega4 has joined #bitcoin-wizards
<gmaxwell>
e0_: not just thought of, but actually used, thats a payment channel.
Noldorin has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
Davasny has quit [Read error: Connection reset by peer]
CocoBTC has quit [Quit: Leaving]
cyphase has quit [Ping timeout: 240 seconds]
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined #bitcoin-wizards
cyphase has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 240 seconds]
byteflame has joined #bitcoin-wizards
cyphase has quit [Ping timeout: 250 seconds]
cyphase has joined #bitcoin-wizards
Giszmo has quit [Ping timeout: 250 seconds]
vega4 has quit [Read error: Connection reset by peer]
Alanius has quit [Remote host closed the connection]
<Eliel>
e0_: is the 10 BTC payment to the 2-of-2 address supposed to be confirmed beforehand or how were you planning on preventing that from being doublespent?
bildramer has quit [Ping timeout: 250 seconds]
Mazz_ has quit [Ping timeout: 264 seconds]
bildramer has joined #bitcoin-wizards
Mazz_ has joined #bitcoin-wizards
oleganza_ has joined #bitcoin-wizards
oleganza has quit [Ping timeout: 250 seconds]
oleganza_ is now known as oleganza
Giszmo has joined #bitcoin-wizards
NewLiberty_ has quit [Ping timeout: 240 seconds]
cyphase has quit [Ping timeout: 265 seconds]
cyphase has joined #bitcoin-wizards
jtimon has quit [Remote host closed the connection]