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
priidu has quit [Ping timeout: 246 seconds]
thrmo is now known as notthrmo
CheckDavid has quit [Quit: Connection closed for inactivity]
bedeho has joined #bitcoin-wizards
Dyaheon has quit [Ping timeout: 260 seconds]
itsme_ has joined #bitcoin-wizards
Dyaheon has joined #bitcoin-wizards
<bsm1175321>
@sipa your ECMH is in no way homomorphic, correct? It's simply mapping a hash to a group with associativity? (e.g. H(a) + H(b) is unrelated to H(a x b) for any suitable definition of + and x)
<sipa>
yes
<sipa>
it requires a random oracle in between for security
<bsm1175321>
I now realize that the last time I thought about it was because I read your ref [5] (Bellare & Micciancio incremental hash functions)
<sipa>
which would break any homomorphic properties
<bsm1175321>
yes
bedeho has quit [Ping timeout: 272 seconds]
<bsm1175321>
When I read [5] I was unhappy with all their variants and came up with my own: take all the data and put it into a Merkle tree. A simple "incremental" hash function is a Merkle path to the location to add the *next* entry. It's log(n) in size and can be updated in the way they state.
<bsm1175321>
Of course that is ordered where yours is unordered.
<gmaxwell>
and then it doesn't work without making the data normative and ordered and you cannot remove from it without having all the data or getting an update proof.
<gmaxwell>
which is precisely what we're trying to avoid there: having a commitment scheme that forces nodes to keep the whole utxo set, since there are proposals that eliminate that requirement in exchange for other tradeoffs.
packet has quit [Ping timeout: 240 seconds]
moli_ has joined #bitcoin-wizards
mol has quit [Ping timeout: 260 seconds]
packet has joined #bitcoin-wizards
<bsm1175321>
gmaxwell: yep, I like it. Now to figure out proofs of presence and absence... ;-)
<bsm1175321>
Using this ECMH scheme, a single block is also described by a single ECMH hash...and if committed to, can be added directly to the running tally.
<bsm1175321>
Does this improve the situation with validationless mining at all?
<gmaxwell>
No, not really. validationless mining is cooperative.
<bsm1175321>
Darn, but that's what I thought too... :-/
<gmaxwell>
One could block VFM based on non-cooperating parties by doing something like commitment = H(H(coinbaseoutputs)|H(accumulator)). But then cooerating VFM miners could just share H(accumulator) values.
MaxSan has quit [Ping timeout: 260 seconds]
<gmaxwell>
The reason I point out that it's cooperative is that if someone spy mines on your stratum port and you dont like it, you can start giving them invalid work and make them waste their time. :)
<gmaxwell>
but to whatever extent uncooperative VFM exists you could dampen it that way.
<bsm1175321>
I wonder if the commitment could be required to involve the privkey of the coinbase in a verifiable manner...such that divulging the preimage of the commitment would share your coinbase privkey...
bedeho has joined #bitcoin-wizards
bedeho has quit [Ping timeout: 240 seconds]
kmels has quit [Ping timeout: 260 seconds]
<bsm1175321>
I think not...whatever method is used to verify the commitment without the privkey (e.g. used by miners other than the creator of this block) can be shared at an intermediate computational stage.
notthrmo is now known as thrmo
Fibonacci has quit [Ping timeout: 240 seconds]
<bsm1175321>
sipa: proof of presence is possible by presenting the sum of all hashes, *except* the one you're interested in, if computing the additive inverse is hard.
<bsm1175321>
e.g. instead of subtracting spent inputs, compute inputs as e.g. H("input"+txid) and outputs and H("output"+txid) and sum them all.
<sipa>
computing the inverse is trivial
<sipa>
we need for spedning
<bsm1175321>
Computing the preimage of the additive inverse is trivial?
<sipa>
it's a modular inverse in the MuHash case
<sipa>
it's a sign flip in the ECMH case
<sipa>
otherwise removing entries from the hash would be hard
<sipa>
then how can someone who receives a UTXO set verify its integrity?
thrmo has quit [Ping timeout: 240 seconds]
<sipa>
ah, i think i see what you mean
<bsm1175321>
The commitment is to sum(outputs)+sum(inputs) rather than sum(outputs)-sum(inputs)
<sipa>
assume that you somehow have a group in which computing the inverse is hard
<sipa>
and now just compute a hash for all creations, and one for all spends
<bsm1175321>
yes.
<sipa>
sounds like you need an RSA group
<bsm1175321>
It's an O(1) proof too, which is pretty interesting considering Merkle proofs are O(log(N))
<sipa>
unfortunately, RSA groups have a trusted setup
<sipa>
(the person coming up with the modulus needs to know its factors)
<bsm1175321>
sipa: why RSA? What's wrong with just prefixing the preimage with "input" or "output"?
<sipa>
that doesn't make computing an inverse hard
<bsm1175321>
Oh I see. You give me a txid, I can compute H("output"+txid), take its inverse, and add it to the known commitment, to generate any proof you want.
<sipa>
yup.
<bsm1175321>
darn.
<sipa>
but in an RSA group you cannot invert
<sipa>
unless you know the factorization of the group modulus
<sipa>
... apart from the trusted setup, that sounds very appealing actually
<bsm1175321>
Unfortunately I can't figure out a way to do proof of absence. The "unordered" bit precludes it. You'd have to impose an ordering to get proofs of absence.
<sipa>
you can produce of proof of spentness
<sipa>
or a proof of creation
<sipa>
or a proof of unspentness
<bsm1175321>
As separate commitments, yes...
<sipa>
if you have a commitment to both the multiplication of all the creations and one to the multiplication of all the spends
airbreather has quit [Read error: Connection reset by peer]
<bsm1175321>
That's a hell of a lot simpler than imposing some kind of ordering.
<sipa>
proofs would be 768 bytes, though
<bsm1175321>
Kind of kills the advantage of proofs being O(1)...
<sipa>
producing a proof also requires iterating over all unspent outputs, i think
<sipa>
(a proof of unspentness)
<bsm1175321>
Yes but that can be optimized by keeping intermediate sums in a binary tree.
<sipa>
with 384 bytes per node in the tree...
<sipa>
many times larger than the blockchain itself, i think
<bsm1175321>
Perhaps there's another way to make additive inverses hard...
airbreather has joined #bitcoin-wizards
<bsm1175321>
Or, use multiplication instead of addition...
<sipa>
that's what MuHash does
<sipa>
and a multiplicative inverse is easy
<sipa>
... except in an RSA group :)
<bsm1175321>
Not in elliptic curves ;-)
<sipa>
there is no multiplication of EC points
<sipa>
and if you mean multiplication by integers, that's still trivial to invert
<bsm1175321>
Now I'm super confused. Both pubkey derivation from a privkey and ECDH are ec point multiplications I thought...
<sipa>
multiplication of an EC point with an integer, yes
<sipa>
if a * B = C (with a an integer, and B and C points), it's hard to compute a from B and C
<sipa>
but trivial to compute B from a and C
<bsm1175321>
Ah I see...
<sipa>
because B = (1 / a) * C
<bsm1175321>
yep
bedeho has joined #bitcoin-wizards
airbreather has quit [Ping timeout: 246 seconds]
<bsm1175321>
Perhaps if there were some kind of pairing, such that you compute the commitment on both sides of the pairing in different ways, such that on the "other" side of the pairing, the additive inverse requires knowledge of a preimage that you don't have...
bedeho has quit [Ping timeout: 246 seconds]
Noldorin has quit [Ping timeout: 240 seconds]
<bsm1175321>
I don't think that works...nodes can compute everything on the "other" side of the pairing anyway...
pro has quit [Quit: Leaving]
<gmaxwell>
I see you reinvented RSA accumulators above.
<gmaxwell>
Note that they require trusted setup. You can get rid of the trusted setup by using a UFO ("unfactorable object") but they makes the numbers ~10x larger.
<bsm1175321>
In this literature, "revocation" can be directly mapped onto a "spent output", and they can indeed prove both presence and absence using accumulators.
<fibonacci_>
When do Fibonacci fragments get implemented?
danrobinson has joined #bitcoin-wizards
airbreather has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
<danrobinson>
fibonacci_: oh it's the main focus of most modern blockchain research
<danrobinson>
they've got us working in shifts
<sipa>
wth are fibonacci fragments?
bedeho has joined #bitcoin-wizards
bedeho has quit [Ping timeout: 260 seconds]
pavel_ has joined #bitcoin-wizards
bedeho has joined #bitcoin-wizards
paveljanik has quit [Ping timeout: 240 seconds]
Fibonacci has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
Fibonacci has quit [Quit: Leaving]
kmels has joined #bitcoin-wizards
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
kmels has quit [Quit: Saliendo]
tromp has quit [Remote host closed the connection]
<fibonacci_>
danrobinson: are you serious?
<danrobinson>
i am not
<fibonacci_>
It's the extra 5 decimals lol
<fibonacci_>
That was funny then
<fibonacci_>
You had me... it would be fruitful research to implement the Golden Ratio though for sure
<fibonacci_>
And it would take the attention of all the brilliant minds to accomplish it
<fibonacci_>
DNA is the most efficient data management tool known to man and crypto should be emulating it any way possible
Fibonacci has joined #bitcoin-wizards
<fibonacci_>
A very simple implementation is adding an extra 5 decimals for 13 total so that when bitcoins price goes through the roof the satoshi has a fragmentation of an additional 10000 units. 13 decimals seems to me to be the best way to break up the satishi. Just something for consideration
bedeho has quit [Remote host closed the connection]
bedeho has joined #bitcoin-wizards
<Fibonacci>
Self similarity in multiple blockchains would allow for easier mending of multiple blockchains
danrobinson has quit [Quit: danrobinson]
danrobinson has joined #bitcoin-wizards
cyphase has quit [Ping timeout: 240 seconds]
harrymm has quit [Read error: Connection reset by peer]
cyphase has joined #bitcoin-wizards
harrymm has joined #bitcoin-wizards
[7] has quit [Ping timeout: 255 seconds]
TheSeven has joined #bitcoin-wizards
<sipa>
Fibonacci: get lost
Dyaheon has quit [Ping timeout: 268 seconds]
<Fibonacci>
rude
<sipa>
then stop producing nonsense
Dyaheon has joined #bitcoin-wizards
chjj has quit [Ping timeout: 268 seconds]
<Fibonacci>
How is the addition of 5 extra decimals and talking about a means of more effectively merging blockchain networks by organizing the data nonsense?
<sipa>
i don't believe you have any clue what you're talking about
<sipa>
prove me wrong by showing some code
<Fibonacci>
The topic talks about long term application I'm talking about if bitcoin becomes more valueable.
<Fibonacci>
I'm not a coder
<sipa>
then stop producing sentences with random technical terms in it
harrymm has quit [Ping timeout: 268 seconds]
<Fibonacci>
I used multiple blockchains twice in one sentence my apologies
<Fibonacci>
I'm just using the best words I have to describe what I'm talking about but assuming I don't have a point before inquiring what I mean is the arrogance and dismissiveness that is so prevalent in the bitcoins Coding community and also why it has been stagnant for long periods
<Fibonacci>
It comes down to a few asshole creating cryptic language so they appear smart and projecting their ignorance on everyone who visits.
<Fibonacci>
ttyl
<Fibonacci>
If you guys were so smart things would operate on a much higher level. It's a joke. Get your shit together know it alls
Fibonacci has left #bitcoin-wizards ["Leaving"]
chjj has joined #bitcoin-wizards
<gmaxwell>
"creating cryptic language so they appear smart", says the guy calling five extra decimals "fibonacci fragments".
tromp has joined #bitcoin-wizards
harrymm has joined #bitcoin-wizards
tromp has quit [Ping timeout: 240 seconds]
pavel_ has quit [Quit: Leaving]
rockhouse has quit [Remote host closed the connection]
UnrealLife has joined #bitcoin-wizards
arowser has quit [Quit: No Ping reply in 180 seconds.]
PaulCape_ has joined #bitcoin-wizards
UnrealLife1 has joined #bitcoin-wizards
PaulCapestany has quit [Ping timeout: 255 seconds]
arowser has joined #bitcoin-wizards
arowser has quit [Read error: Connection reset by peer]
UnrealLife has quit [Ping timeout: 240 seconds]
tromp has joined #bitcoin-wizards
tromp has quit [Ping timeout: 240 seconds]
bedeho has quit [Remote host closed the connection]
rusty has quit [Ping timeout: 240 seconds]
BashCo has quit [Ping timeout: 246 seconds]
bedeho has joined #bitcoin-wizards
JackH has quit [Ping timeout: 268 seconds]
danrobinson has quit [Quit: danrobinson]
mol has joined #bitcoin-wizards
moli_ has quit [Ping timeout: 246 seconds]
UnrealLife2 has joined #bitcoin-wizards
UnrealLife1 has quit [Ping timeout: 246 seconds]
UnrealLife1 has joined #bitcoin-wizards
UnrealLife2 has quit [Ping timeout: 246 seconds]
tromp has joined #bitcoin-wizards
BashCo has joined #bitcoin-wizards
Belkaar has quit [Ping timeout: 240 seconds]
Belkaar has joined #bitcoin-wizards
Belkaar has joined #bitcoin-wizards
Belkaar has quit [Changing host]
tromp has quit [Ping timeout: 240 seconds]
bedeho has quit [Remote host closed the connection]
bedeho has joined #bitcoin-wizards
bildramer has quit [Ping timeout: 240 seconds]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
bildramer has joined #bitcoin-wizards
jannes has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
JackH has joined #bitcoin-wizards
tromp has quit [Ping timeout: 246 seconds]
laurentmt has quit [Quit: laurentmt]
Guyver2 has joined #bitcoin-wizards
vicenteH has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 240 seconds]
BashCo has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
bedeho has quit [Remote host closed the connection]
dnaleor_ has quit [Ping timeout: 268 seconds]
laurentmt has quit [Quit: laurentmt]
dnaleor_ has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
bedeho has joined #bitcoin-wizards
bedeho has quit [Remote host closed the connection]
Guest98 has quit [Ping timeout: 246 seconds]
thrmo has joined #bitcoin-wizards
fibonacci_ has quit [Quit: Connection closed for inactivity]
MaxSan has joined #bitcoin-wizards
UnrealLife1 has quit [Ping timeout: 240 seconds]
pro has joined #bitcoin-wizards
bedeho has joined #bitcoin-wizards
MaxSan has quit [Ping timeout: 272 seconds]
danrobinson has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 240 seconds]
mol has quit [Ping timeout: 272 seconds]
moli_ has joined #bitcoin-wizards
BashCo has joined #bitcoin-wizards
UnrealLife has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 258 seconds]
BashCo has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
danrobinson has quit [Quit: danrobinson]
str4d has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
rusty has quit [Ping timeout: 260 seconds]
tromp has quit [Ping timeout: 260 seconds]
<bsm1175321>
sipa, gmaxwell from my reading of the accumulator literature this morning (mostly https://eprint.iacr.org/2008/539.pdf), it seems to me that such accumulators not only require a trusted setup, but also require an authority possessing a secret key to create the accumulator.
<bsm1175321>
While witness information and proofs can be updated with public information, the required use of this secret key to update the accumulator would seem to veto its use in a crypto-currency like setup.
d9b4bef9 has quit [Remote host closed the connection]
bitjedi has quit [Ping timeout: 258 seconds]
d9b4bef9 has joined #bitcoin-wizards
tromp has quit [Ping timeout: 240 seconds]
laurentmt has joined #bitcoin-wizards
bitjedi has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
DrNo has quit [Ping timeout: 255 seconds]
DrNo has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
zakalwe has quit [Ping timeout: 240 seconds]
<sdaftuar>
sipa: regarding the rolling utxo set hash proposal: it seems like a goal is to make the hash be implementation agnostic, if i understand correctly?
<sdaftuar>
sipa: if that's right, how do you think about the optimization to exclude provably unspendable outputs from the utxo set? that seems like the sort of implementation-specific detail you'd want to avoid, maybe?
<sipa>
sdaftuar: ha, good point!
<sipa>
sdaftuar: well, not just implementation agnostic, but also efficient to maintain
<sipa>
but indeed - its specification would depend on what unspendable outputs are considered pruned
<sdaftuar>
right... so far, that rule is pretty simple, at least, so you could just hardcode that into a spec. seems slightly ugly to have to do that though
chjj has quit [Ping timeout: 240 seconds]
<gmaxwell>
sdaftuar: well we made that rule simple with the idea in mind that it could be normative.
<gmaxwell>
(the OP_RETURN rule)
<sdaftuar>
gmaxwell: looks like there's also a max script size check
<gmaxwell>
sdaftuar: oh do we also use that to prevent putting them in the UTXO set? well thats a good idea that we do.
<bsm117532>
One might check that the OP_RETURN exists in a block...making such pruning undesirable, but that's only relevant if one can prove presence or absence from the rolling utxo set hash.
<sipa>
bsm1175321: ... what?
DrNo has quit [Ping timeout: 260 seconds]
<bsm117532>
Excluding OP_RETURNS from the UTXO set commitment might be undesirable, but only if you can use it to prove the OP_RETURN is there...
<sipa>
you can trivially prove that the OP_RETURN is in the UTXO set by just giving the SPV proof of its inclusion
<sipa>
as it's unspendable, if it is created at any point in time, it will forever be in the UTXO set
<bsm117532>
That too.
<sipa>
(also, I don't care about OP_RETURNs, i consider them abusive)
Sprh has quit [Read error: Connection reset by peer]
<bsm117532>
But since your commitment is O(1), it could contain an arbitrary amount of unspendable junk and not bother anyone.
<sdaftuar>
bsm117532: not if you want to use it!
<sdaftuar>
ie if you want to give someone the utxo set and have them verify against the has, you need to keep the junk
<sdaftuar>
hash*
<sdaftuar>
so it's absolutely desirable to prune, as a practical matter. just philosophically a little ugly, i think
<sdaftuar>
(ie, where do you draw the line)
<bsm117532>
Yes, it depends on how this commitment gets used.
<sipa>
AFAIK, it's only useful to compare UTXO sets :)
<bsm117532>
sipa: There should be exactly one OP_RETURN in a block, preferably in the coinbase, preferably constructed from something like opentimestamps.
DrNo has joined #bitcoin-wizards
<sipa>
bsm117532: i wish opentimestamps supported sign-to-contract :)
cluckj has joined #bitcoin-wizards
cluckj has quit [Client Quit]
triazo has quit [Remote host closed the connection]
chjj has joined #bitcoin-wizards
<gmaxwell>
sipa: petertodd has a lame "but it's complicated" argument that basically amounts to getting people to write code that even verifies hashtree membership is super hard. It's true but if complicated is a bar no timestamp has any ground to stand on.
<sipa>
gmaxwell: i'm aware
<sipa>
i'm not arguing for it, just expressing my wish :)
<instagibbs>
I'm afraid that's a bit of cloud-yelling while certain groups are doing an op_return per file being timestamped...
<instagibbs>
(I do not disagree with s2c)
jcluck is now known as cluckj
dnaleor_ has quit [Ping timeout: 268 seconds]
MaxSan has joined #bitcoin-wizards
<JackH>
are there any code examples for CPFP anywhere?
<sipa>
how do you mean?
<JackH>
or how to construct it more specifically, as we are looking to implement CPFP features within our payment processing system in order to "help" low fee transactions
<sipa>
all you need to do is create a transaction that spends an unconfirmed output to yourself with higher fee
<JackH>
well we cant really ensure all transactions we process are going to clear within a day, so we might start running CPFP on some of them to push them through
<sipa>
also, offtopic here
dnaleor_ has joined #bitcoin-wizards
thrmo has joined #bitcoin-wizards
<andytoshi>
sipa: gmaxwell: petertodd is going to add s2c support
<andytoshi>
he asked me to please write a pure python function to do it tho so that he doesn't need a dep, and i've been procrastinating
<andytoshi>
i recently saw him in person ready to forcefully argue for it, but he was already coming around on his own it seemed :)
<bsm117532>
You guys have any links as to how s2c works?
<andytoshi>
but there's no dedicated write-up anywhere that i'm aware of
<andytoshi>
the idea is that for any point P, the operation x → `P + H(P||x)G` is a commitment operation ... in an ECDSA or schnorr signature, there are two points (the pubkey and "ephemeral key" which is made up per-signature) that you can do this operation with and still be able to produce a sig
<instagibbs>
I assume the ephemeral key would then be in two parts, and signer would prove it knows the other half?
<andytoshi>
that is how it works, yeah ... usually we use the word "nonce" instead of "ephemeral key", it's the same thing
<andytoshi>
so a signature that signs its pubkey _is_ actually a PoK of the secret nonce, but this isn't usually something people observe
LeMiner has quit [Read error: Connection reset by peer]
packet has quit [Ping timeout: 240 seconds]
packet has joined #bitcoin-wizards
tromp has joined #bitcoin-wizards
<JackH>
so is this going to work in bitcoin?
<JackH>
will it be a bip?
<andytoshi>
s2c? yes, it works in bitcoin today
<andytoshi>
no need for a bip, it's like a scriptless script, nobody needs to know that anyone else is doing it
<JackH>
has anyone created any yet that is on the blockchain as an example? or wont it show?
blackwraith has joined #bitcoin-wizards
<andytoshi>
it won't show, but if i had an example i would prove it to you
<andytoshi>
would be able to prove it*
<JackH>
sorry for asking a bit stupid, but in which cases can I use the feature?
<andytoshi>
i'm working on something that can make such sigs at https://github.com/apoelstra/sighacker but the actual s2c stuff isn't there yet, i got distracted by some other crypto
priidu has quit [Ping timeout: 246 seconds]
<andytoshi>
JackH: (a) timestamping, (b) anything where you want a signature to commit to something.... so for example your wallet might commit to its current state so that you have an untamperable audit log
tromp has quit [Ping timeout: 255 seconds]
<JackH>
current state could be balance at time of stamping for example?
<andytoshi>
more likely a merkle tree of everything it had done up to that point
<andytoshi>
but you could also throw your balance and anything else into that tree
harrymm has quit [Read error: Connection reset by peer]
<andytoshi>
JackH: so, take a look at the sig in tx ff1dca15029d1df57a601f180308bcb6b91f2e8e129668452eaf066cd0668fa6
<andytoshi>
the sha256 hash of 'This is andytoshi on 2017-05-16 21:30 UTC' is b9a31511e818c559b94ca06aa75bdd2491155b27e8c616e778d2ed8c22ddd057
<andytoshi>
and my original public nonce was 0308aec434612f56df3f02c4e678260424415882ebd3efc16d52e3f9c1e39afdb0 (you cannot know this unless i tell you)
<andytoshi>
you can check that the R value in the signature is the x-coordinate of <original nonce> + sha256(<original nonce> || <hash of 'This is andytoshi...'>)*G
deusexbeer has joined #bitcoin-wizards
<JackH>
hmm
<JackH>
oh wow you just did this one
<andytoshi>
yeah, one sec, i'm writing some sage code so you can see how to verify it
<JackH>
but with this, we can share pretty much anything, based on a regular tx, wow
<andytoshi>
well, commit to anything .. i did have to give you that extra data out of band
<andytoshi>
that's as much UX work as i'm willing to do :P
<gmaxwell>
fwiw the varrious python libraries for bitcoin txn parsing work from sage.
<Eliel_>
Is the point of s2c that it removes the need for an OP_RETURN output?
<gmaxwell>
Eliel_: yes.
<gmaxwell>
we'll I don't know about "the point" but it does that.
<gmaxwell>
and in doing so eliminates bloat and also makes the transactions much more indistinguishable from ordinary transactions.
<Eliel_>
I am currently scratching my head about it and wondering if I really understood what it's for :)
<Eliel_>
or if there's more potential hidden away that I can't quite perceive right now
<gmaxwell>
well, as mentioned it makes them undetectable. So it helps protect against censorship.
<sipa>
Eliel_: if your goal is publishing data, no, because you can't use s2c to publish anything
<andytoshi>
any situation where OP_RETURN would be appropriate, s2c is (except for explicitly publishing data in a provable way)
<gmaxwell>
but if your goal were publishing data op_return hardly does that in any case.
<gmaxwell>
(because its so expensive and size constrained)
<sipa>
Eliel_: if your goal is to commit/timestamp data, yes, s2c is better (undetectable and smaller on chain)
<andytoshi>
in addition it lets you tag specific signatures, and therefore specific txes, with some metadata, in a provable way
<andytoshi>
i have some vague ideas about using this in a wallet so i can have some assurance it has not been tampered with
blackwraith has quit [Ping timeout: 260 seconds]
<gmaxwell>
yea, one application we previously discussed at blockstream was having wallets use this to commit to their metadata.. in particular things like reference exchange rates. So later if you need to prove your accounting records to someone you can show that you weren't going back and cooking the books retroactively.
<andytoshi>
ooo i'd never thought of that one
<kanzure>
why not just timestamp your records as you go along?
<gmaxwell>
thats what this would do.
<kanzure>
also why is retroactive cooking a problem-- isn't the problem mostly inline book cooking up fraud the whole time with dynamic writing of like umpteen zillion different histories?
<JackH>
cant this be used as a password?
<mryandao>
what's s2c?
<kanzure>
sign to contract
<JackH>
if I have the R and use it to return the value, and if those two compute, I "log in"
<andytoshi>
kanzure: so, if you are timestamping tx data with the actual transactions, you can't make parallel timestamps like that
<sipa>
JackH: "use it to return the value" ?
<andytoshi>
you also get a timestamp at "precisely the time the tx was created", which is more precise than ordinary timestamps (which are "about and around this clocktime")
<JackH>
so this is saved on the blockchain, and in order for me to read it, I have R
<sipa>
R is on the blockchain
<andytoshi>
there are two Rs here
<kanzure>
oh, timestamping next to actual wallet transaction. so this does not use calendar window aggregation magic.
<sipa>
what you have is a proof that the R was computed using some particular data as entropy
<andytoshi>
kanzure: right, though you could do that in parallel
<MaxSan>
someone should respond to him. i cant form a response as well as you lot can. I need to make a coctail instead.
<sipa>
meaning that that entropy existed at the time the transaction was created
<andytoshi>
MaxSan: i might take a look at it, but generally reddit is a black hole when it comes to this sorta thing
<MaxSan>
yeah it is
<MaxSan>
its why I sort of hang out here but so many new folks come there
<MaxSan>
and you have to kinda defend the fort =/
<bsm117532>
Super interesting. Does petertodd want to put the opentimestamps root in a transaction like this, so using no OP_RETURNS?
<bsm117532>
And if you did, how would you find timestamped data? Or is the idea that there are many opentimestamps servers making their own timestamps?
<andytoshi>
bsm117532: yes, at some point in the near future. and you find the data same as you do now
<sipa>
bsm117532: you don't 'find' timestamped data, you get a proof
kmels has quit [Ping timeout: 246 seconds]
<bsm117532>
Well sure, my question was more about the level of aggregation...
<andytoshi>
you can see that already with OP_RETURN the thing that lands in the blockchain is very far removed from the actual data
<gmaxwell>
amusingly you could produce an exo-timestamper. E.g. whenever you transact you offer a timestamp server to timestamp for it. If you successfully return a useful proof to it.. it gives you tokens yous you can use to ask it to timestamp things later. :P
UnrealLife has joined #bitcoin-wizards
<gmaxwell>
and the timestamp server itself never transacts, except if no one else does for a long time.
<bsm117532>
gmaxwell: so every transaction could potentially have a timestamp (even someone elses!)
<gmaxwell>
yes. in what I described it would usually be someone elses.
JackH has quit [Quit: Leaving]
<bsm117532>
The timestamp server would have to give you the timestamp root, then you sign, then the timestamp server verifies it and broadcasts it if it's correct? If it's not correct it just discards it and says "that transaction has no timestamp commitments".
Cobra-Bitcoin has joined #bitcoin-wizards
<gmaxwell>
bsm117532: yea, and it would just give many users the same stuff to timestamp and only clear its queue when it gets an acceptable one.
<Cobra-Bitcoin>
Reddit is basically a misinformation producing machine
jannes has quit [Quit: Leaving]
UnrealLife1 has joined #bitcoin-wizards
<gmaxwell>
yea :(
<gmaxwell>
when I was a we lad I thought the internet would free the minds of the world, but improved technology and power imbalances have made it the greatest coercion tool ever imagined, I fear.
UnrealLife has quit [Ping timeout: 246 seconds]
<kanzure>
wait was freeing minds the goal?
<Cobra-Bitcoin>
I guess the internet was always supposed to be a place for the free exchange of information, but nobody said that that information had to be accurate, or reliable
<gmaxwell>
technology doesn't have goals, it has implications.
<Cobra-Bitcoin>
At some point, like with /r/btc, the lies become so great and enormous that nobody can even challenge them anymore effectively
<gmaxwell>
As a young man I thought the implication of everyone inexpensively being able to reach everyone else would have one set of benefits, which is somewhat has... But the costs weren't what I imagined.
<kanzure>
get better friends that don't spam you
<gmaxwell>
The first sign of trouble that I really saw was in 1998 or so, when a woman I was dating decided that she was actually an elf, and created a mailing list which was full of other people that earnestly thought they were elves. And with 100 of these people constantly talking to each other they became all quite convinced that this was all totally normal. Fortuately their views were more or less harm
dnaleor has joined #bitcoin-wizards
<gmaxwell>
less, but they easily could have been otherwise. So even without funded commercial or state-actor manipulation and fancy influence tools, shills, and whatnot .. a group of people managed to self-affirm themselves into a really weird space.
dclxvi has joined #bitcoin-wizards
<MaxSan>
i feel ive jumped into something here again lol
<MaxSan>
Where exactly do I find these elf girls? asking for a friend.
<gmaxwell>
uh. lol.
<MaxSan>
:P
<gmaxwell>
I doubt their mailing list exists anymore. I could try to remember it. I don't talk to her anymore, though for reasons unrelated to deciding she was an elf.
<MaxSan>
Only messin
<MaxSan>
..oO
<gmaxwell>
but yea, pre-internet it was much harder to form a cult.
<MaxSan>
But yeah self reinforcing views under closed walls is very easy to slip into
<MaxSan>
Not always negative/positive but are what they are. I have went from place to place on the internet and met the same people in small unrelated communities. Great minds think alike? unlikely in our case lol
<gmaxwell>
it's not just that though. _influence_ is unfortunately easy. Absent someone trying to manipulate it, it can fall into self-amplifying traps...
<MaxSan>
The more complex a topic is like bitcoin though the more people need to look at others for direction
<Cobra-Bitcoin>
The concept of a "social" or "mind" virus is interesting, like I've noticed the /r/btc folks repeat the exact same talking points, as if brainwashed or infected with a mind virus like something out of Ghost in the Shell
<gmaxwell>
Cobra-Bitcoin: to be fair, a lot of them are actually the same people under different names. :)
<MaxSan>
ding ding... 5 points lol
<gmaxwell>
Cobra-Bitcoin: Ver told Shrem that ver was spending $500k/mo 'promoting BU' (shrem later apologized for publishing ver's private info... :P) consider the kind of influence that gives you on a largely open venue like reddit.
vicenteH has quit [Ping timeout: 246 seconds]
<Cobra-Bitcoin>
He definitely has a shill army working his sub, after a while I see the same sets of usernames posting, the usual suspects, Adrian-X, Ant, increaseblocks, that Anna person, etc
<sipa>
can we not turn this channel into #rant-about-reddit?
<gmaxwell>
sipa: sorry, wasn't even really trying to rant about reddit.
<gmaxwell>
But rather the general problem with anonymous open communication channels that leave them super vulnerable to disruption.
<sipa>
i'm aware, and i think it's fine
<gmaxwell>
(including, FWIW, this channel.)
<sipa>
but i'd also like to keep the bitcoin drama out of here
<gmaxwell>
Fair enough.
<Cobra-Bitcoin>
A technical question sipa, what's going to likely happen if segwit doesn't activate?
<sipa>
Cobra-Bitcoin: i'd consider that a political question, but i'll bite: as long as there seems to be ecosystem support for it, i expect that a new deployment will be proposed
<sipa>
as far as development is concerned, i consider segwit done
<gmaxwell>
Cobra-Bitcoin: I've always just assumed that a new deployment would be proposed on the next available BIP9 bit, perhaps with the same or different activation criteria. The fail-to-active seems like it may be prudent based on feedback I've seen from users.
<gmaxwell>
Cobra-Bitcoin: or I'd say that the default for _any_ bip9 thing is that it keeps getting redeployed so long as there is interest for it. And stops getting redeployed if interest moves elsewhere (e.g. if a better option comes along)
<gmaxwell>
Cobra-Bitcoin: I think we'd probably already gear up for a redeploy but for segwit it's somewhat more complicated than most softforks because there are P2P interactions.
<gmaxwell>
E.g. it would be simpler to only have one deployment window programed at a time in a given piece of software.
<Cobra-Bitcoin>
I'd say the time for a hard fork is soon to be honest, a hard fork with segwit, and other fixes is needed
<Cobra-Bitcoin>
Bitcoin is slowly becoming extremely hard to change, so good to do the hard fork in the next few years
<gmaxwell>
Cobra-Bitcoin: well the BIP148 UASF is darn near exactly that.
<sipa>
Cobra-Bitcoin: hmm, i disagree
<sipa>
i don't think that fear of stagnation is a good reason for a hardfork
<gmaxwell>
as far as other changes, I think it's preferable to seperate things. Bundling things which could be logically seperated is a little coersive (perhaps more than a little). For segwit we carefully cut it to a core set of things which all depend on each other.
<Cobra-Bitcoin>
You can barely change the system as it is now, in 2-3 years, nobody will have any control whatsoever over Bitcoin
<sipa>
Cobra-Bitcoin: sounds awesome
<gmaxwell>
And stagnation would be very low on the list of risks that I'd account up for Bitcoin.
<sipa>
if the ecosystem wants segwit, a user-triggered softfork seems the best way to proceed
<sipa>
that does not require forking off those who aren't interested in it
<gmaxwell>
Cobra-Bitcoin: The kind of stagnation where changes only happen where they are very widely supported, and still accomidate people that would prefer to ignore them is a pretty good outcome generally. That doesn't imply an inability to adopt useful changes.
<gmaxwell>
we certantly don't want to end up like ethereum or ripple, which are more on the other end of the spectrum. :)
<sipa>
Cobra-Bitcoin: my wish is that people wouldn't see one controversial change as blocking other improvements
<Cobra-Bitcoin>
I'm talking about a situation where changes can't happen at all, even if they're good ideas and well supported, like with Segwit but much worse
<gmaxwell>
Cobra-Bitcoin: back when hearn and gavin started yelling about wanting a hardfork I proposed we do something that just did a number of the really obvious technical cleanup changes (timewarp, header bit recovery, etc.) but sadly they were vigorously opposed because they wanted to damnd removal of the blocksize limiti in trade.
<gmaxwell>
Cobra-Bitcoin: It's not clear to me if that outcome is really possible. Though the bar might move arbritarily high.
<gmaxwell>
Cobra-Bitcoin: if it is possible, it would be fantastic news. Though I agree with your thinking that it would be regrettable if we didn't get in some of the known improvements.
<gmaxwell>
But at the same time the set of improvements we know of today are going to be tiny compared to the ones we'll eventually find.
<Cobra-Bitcoin>
Some improvements are better than nothing
<gmaxwell>
maybe, though at what cost?
<sipa>
Cobra-Bitcoin: why would changes stop happening at all? if it's just because miners don't want something, and others do, then the ecosystem can easily force miners
<gmaxwell>
yea, miners really aren't much of a concern there.
<sipa>
Cobra-Bitcoin: if it's due to a disagreement inside the users of the system, a split may happen
<sipa>
i think that would be sad, but not terrible if done in a respectful way
<Cobra-Bitcoin>
The ecosystem has shown that it won't do anything that has even the possibility of a split or ruining Bitcoin's brand
<sipa>
and for good reason
<gmaxwell>
and I think that segwit adoption has show that ecosystem can easily gather overwhelming support around a tech improvement.
<sipa>
but at some point too much may become too much
<gmaxwell>
The biggest complication there is that people have misrepresented BIP9 as a miner vote and managed to present miner votes as somehow a virtuious way of 'deciding' things.
<gmaxwell>
Cobra-Bitcoin: I think you're perhaps being too anxious there. Bitcoin should exist and be heavily used for hundreds or thousands of years.... some months delay in an improvement will see like nothing.
<gmaxwell>
(in hindsight)
MaxSan has quit [Ping timeout: 268 seconds]
<Cobra-Bitcoin>
Bitcoin is in it's "early history" right now, so we should all be doing like Satoshi did and getting as much set in stone as possible before the system becomes too hard to be changed in 3-5 years
<sipa>
i don't think "too hard to change" is necessarily an outcome
<sipa>
too hard to hardfork perhaps
<gmaxwell>
For even simple web technology like HTTP2 which has none of the complex consensus implications -- it's taken years to get it speced and deployed.
<sipa>
disagreement about how to deal with this one aspect of scalability shouldn't hinder other improvements, and i hope that eventually we'll see that
<gmaxwell>
4 byte ASN numbers in BGP, -- again, BGP far less global consistency requirements than Bitcoin, but not none at all-- started their discussion in 2001, was finally standarized in 2007, and was first deployed on the internet in 2012 (and then promptly caused an internet wide partition due to corner case behavior making it not actually a soft-fork) :P
<gmaxwell>
(this change was required for there to be more than ~65535 globally routable networks on the internet.)
smk has joined #bitcoin-wizards
<Cobra-Bitcoin>
Hopefully Core will be a bit more aggressive with the next Segwit deployment
<gmaxwell>
Yea, probably: we know a lot more now than before.
<gmaxwell>
One of the problems with softforks is that it's hard to gauge support in advance of launching them but you must program the software completely in advance.
<gmaxwell>
We didn't know for sure that within a few months we'd have 90%+ nodes ready for it, for example... we could have guessed but it would have been a guess.
<Cobra-Bitcoin>
It's amazing how many downloads Core binaries get...
<gmaxwell>
We now have another year of testing and expirence, a deployment on litecoin, and overwhelming feedback from the user and business communities.
<gmaxwell>
And we know that our lazy but safe triggering mechenism is getting gamed by a couple oversized miners.
<Cobra-Bitcoin>
People are updating their nodes more often now, the current set of full node operators are a lot more engaged
Cobra-Bitcoin has left #bitcoin-wizards [#bitcoin-wizards]
<gmaxwell>
Cobra-Bitcoin: hard to know in detail though.. e.g. if a bunch of those are just 'moral supporters' who only own a few bitcents and never transact, it might not mean as much as it seems.