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
DeanGuss has quit [Remote host closed the connection]
Barras2 has quit [Read error: Connection reset by peer]
DeanGuss has joined #bitcoin-wizards
pinheadmz has joined #bitcoin-wizards
pinheadmz has quit [Quit: pinheadmz]
pinheadmz has joined #bitcoin-wizards
davec has quit [Read error: No route to host]
davec has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]
pinheadmz has quit [Quit: pinheadmz]
tralfaz has joined #bitcoin-wizards
davterra has quit [Ping timeout: 240 seconds]
tralfaz is now known as davterra
Mikaela1 has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
dr-orlovsky has quit [Ping timeout: 265 seconds]
AaronvanW has quit [Ping timeout: 240 seconds]
pinheadmz has joined #bitcoin-wizards
Mikaela1 has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 272 seconds]
pinheadmz has quit [Read error: Connection reset by peer]
kallewoof has quit [Read error: Connection reset by peer]
kallewoof_ has joined #bitcoin-wizards
rusty has quit [Quit: Leaving.]
<gleb>
There's a new paper on transaction relay, they suggest it for some million-tps system, which i don't care of, but the idea seems to be to use carefully-designed 4-byte tx ids, and that saves all the bandwidth.
<gleb>
This approach obviously have limitations in terms of linear scalability(connections), but if put that aside, maybe the short-id design is interesting? I can't understand how their 4-byte IDs can be possibly collision-resistant in an adversarial setting :) Perhaps someone here could get a better idea?
<zmnscpxj>
first answer that pops to my head is that "carefully-designed" means "assumes non-adversarial setting"
<gleb>
They seem to talk about adv in the middle of Section 4, but I find their description obfuscated...
<gleb>
fwiw it's a peer-reviewed paper at a (supposedly top-tier) non-Bitcoin general systems conference
<zmnscpxj>
okay, will go take a deeper look
<gleb>
Figure 7 anecdotically suggests that they save on transaction-body-bandwidth, which is....impossible? (unless they assume erlay allows a lot of duplicate tx-bodies, which is false)
roconnor has joined #bitcoin-wizards
<roconnor>
Do txids take up a large fraction of transaction data?
jeremyrubin has quit [Ping timeout: 260 seconds]
<roconnor>
I mean, there ought to be at least one signature per input, and signatures are larger than txids. Figure 7 does look like a 50% reduction in transaction size, which doesn't seem possible
<roconnor>
Glancing through section 5.3 does seem to suggest that they believe earlay is retransmitting transactions.
<roconnor>
I mean, it suggests that they have run earlay and observed this.
sirkitree has quit []
dr-orlovsky has joined #bitcoin-wizards
Lthere has joined #bitcoin-wizards
CryptoDavid has joined #bitcoin-wizards
sr_gi has quit [Read error: Connection reset by peer]
sr_gi has joined #bitcoin-wizards
tralfaz is now known as davterra
kallewoof_ is now known as kallewoof
yanmaani has quit [Ping timeout: 240 seconds]
<gleb>
They suggest that their “siphash” approach retransmitting, which is correct because they can’t dedup due to salt. In erlay, that’s not the case
<gleb>
well, in the latest version at least
<gleb>
And they don’t claim it either, yet somehow the graph suggests it
bswartz has quit [Quit: Leaving.]
yanmaani has joined #bitcoin-wizards
bswartz has joined #bitcoin-wizards
bswartz has quit [Changing host]
bswartz has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
roconnor has quit [Read error: Connection reset by peer]
dr-orlovsky has quit [Ping timeout: 240 seconds]
dr-orlovsky has joined #bitcoin-wizards
proofofkeags has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
laptop has quit [Quit: Leaving]
Lthere has quit []
proofofkeags has quit [Ping timeout: 240 seconds]
jeremyrubin has joined #bitcoin-wizards
ghost43 has quit [Read error: Connection reset by peer]
ghost43 has joined #bitcoin-wizards
TheoStorm has quit [Quit: Leaving]
jonatack has joined #bitcoin-wizards
proofofkeags has joined #bitcoin-wizards
proofofkeags has quit [Remote host closed the connection]
SleepingShell has joined #bitcoin-wizards
SleepingShell has left #bitcoin-wizards ["WeeChat 2.9"]
hari1 has joined #bitcoin-wizards
rot is now known as iCookie
iCookie is now known as rot
hari1 has quit []
davispuh has joined #bitcoin-wizards
variable has joined #bitcoin-wizards
variable is now known as Guest36719
CryptoDavid has quit [Quit: Connection closed for inactivity]
jonasschnelli has joined #bitcoin-wizards
jonasschnelli has quit [Changing host]
jaromil has quit [Remote host closed the connection]
jaromil has joined #bitcoin-wizards
jaromil has joined #bitcoin-wizards
fiatjaf has quit [Ping timeout: 272 seconds]
fiatjaf has joined #bitcoin-wizards
fiatjaf has quit [Ping timeout: 240 seconds]
smak has joined #bitcoin-wizards
vtnerd has quit [Ping timeout: 260 seconds]
vtnerd has joined #bitcoin-wizards
TheoStorm has joined #bitcoin-wizards
vtnerd has quit [Ping timeout: 240 seconds]
vtnerd has joined #bitcoin-wizards
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
fiatjaf has joined #bitcoin-wizards
Guest36719 has quit []
justanotheruser has quit [Ping timeout: 240 seconds]
Belkaar has quit [Ping timeout: 240 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
Belkaar has joined #bitcoin-wizards
dorena has joined #bitcoin-wizards
proofofkeags has joined #bitcoin-wizards
proofofkeags_ has joined #bitcoin-wizards
rh0nj has quit [Remote host closed the connection]
smak has quit [Remote host closed the connection]
rh0nj has joined #bitcoin-wizards
justanotheruser has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 258 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
CryptoDavid has joined #bitcoin-wizards
<zmnscpxj>
gleb: The shortid has a 24-bit FixedBytes and a 8-bit RandomBytes. FixedBytes is a function of the tx, but RandomBytes is a function of the tx and the peers communicating
<zmnscpxj>
gleb: In order for an attacker to block out a target tx, it has to create 256 alternatives that match the FixedBytes
<zmnscpxj>
gleb: But the mechanism they propose will check if there are more than 9 txes that have the same FixedBytes, and will require full 256-bit txids if so
<zmnscpxj>
it does seem to need that peers have some kind of salt they agree on when sharing txids tho
<zmnscpxj>
to my naivete, it seems useful as a replacement for the short-ids in a compactblocks setting but not for compressing the actual prev-txids in txes, as I expect Bitcoin to have far more than 9 * 16,777,216 txes already
<adlai>
please take extra care when spelling proper names that are intentional typos of short nouns, e.g. 'erlay' is both a typo and not a typo
* adlai
can't figure out wtf 'earlay' is, other than "too early to proofread"
<zmnscpxj>
adlai: a confused wasp that is supposed to lay eggs on ears, but is now laying ears on eggs?
<zmnscpxj>
OTOH the UTXO set is about 68million or so, and there are fewer referrable txes than that, so maybe it would work to replace prev-txids with these short-ids as well?
<adlai>
what is the long-term prognosis on the complexity of unspent fragmentation?
<zmnscpxj>
personally I hope channel factories become a thing and a lot of utxos have shared ownership
<adlai>
e.g., "By 2145, there should be no fewer than seventy billion trillions of transacting devices, coordinating their actions using no more than seven million fragments of digital stuff"
* adlai
may have thinkoed out a few orders of magnitude; the question remains, arguably unanswerable in a politely logged channel before, say, 2130
<zmnscpxj>
yes, too many years out, insufficient data to compute reasonable answer
<adlai>
reasonable answers are both computable and impolite
adlai has left #bitcoin-wizards ["hopes are for the public logs"]
vtnerd has quit [Ping timeout: 240 seconds]
vtnerd has joined #bitcoin-wizards
smrtz has joined #bitcoin-wizards
<smrtz>
Heyo! I'm pretty new to cryptogrophy, but trying to wrap my head around Threshold signatures vs Aggregate signatures. I'm trying to figure out if an aggregate signature allows a verifier with all public keys to determine which keys were used, and (roughly) how much smaller it would be then a unique detached signature for each signing key pair.
<zmnscpxj>
ideally a threshold signature *is* an aggregate of k signers, but that is not how it is implemented in Bitcoin today
<zmnscpxj>
an aggregate signature would be just 1 signature instead of k (or n) detached signatures
<zmnscpxj>
MuSig works easiest for aggregate sigs
<zmnscpxj>
to implement threshold, you need an extra setup step
<zmnscpxj>
that is not described in the MuSig paper
<zmnscpxj>
but if you do the extra setup step
<zmnscpxj>
then the MuSig proposal will work just as well with threshold
<smrtz>
What's the name of that extra setup step? I'd like to learn more about it.
<zmnscpxj>
verifiable secret sharing
<zmnscpxj>
I am ignorant of its details other than name
<zmnscpxj>
it is basically shamir secret sharing, but done in a multiparty setting with zero-knowledge and other buzzwords
<smrtz>
Ahh, finally a term I actually understand.
<smrtz>
Shamir Secret Sharing, I have basically no understanding of ZK stuff.
<zmnscpxj>
problem of Shamir Secret Sharing is that one of the devices learns a privkey that is equivalent to the entire k-of-n, in order to generate the pubkey
<zmnscpxj>
verifiable secret sharing just works with pubkeys
<zmnscpxj>
I think
<zmnscpxj>
not sure
<zmnscpxj>
andytoshi should know, but maybe he is afk
<smrtz>
So, if I wanted to consolidate a set of detached sigs into a smaller single object, and retain the ability to determine which secret keys were involved, neither threshold or aggregate would work for me?
<zmnscpxj>
no
<zmnscpxj>
you need to coordinate their R
<zmnscpxj>
so you cannot even do that even without the ability to determine whose pubkeys were used
<smrtz>
Their R?
<smrtz>
Is an aggregate or threshold signature not smaller than the sum of all individual signatures?
<zmnscpxj>
signatures have an R and an s
<zmnscpxj>
(or sometimes an e or an s)
<zmnscpxj>
to get an aggregate signature, all signers have to agree on and use the same R
<zmnscpxj>
and they sum up their s
<smrtz>
Hmm, thanks.
rusty has joined #bitcoin-wizards
<smrtz>
My actual goal is to have a system of `i` key pairs, where `j` signers agree on a file, and cooperate to create a single, small signature. The verifier needs to be able to verify that at least %(`i`/2+1) signers were involved, and I'd like to be able to verify which signers they were. It seems like I'm going down the wrong method with
<smrtz>
aggregate/threshold sigs?
rusty has quit [Quit: Leaving.]
davterra has quit [Remote host closed the connection]