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
se3000 has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
se3000 has joined #bitcoin-wizards
alpalp has joined #bitcoin-wizards
<kanzure>
Taek: right, totally plausible. also-- if someone can do that for multiple blocks in a row, then it sounds like PoW is broken ;).
<kanzure>
s/multiple blocks in a row/indefinitely
jtimon has quit [Remote host closed the connection]
<kanzure>
but yeah, it's highly vulnerable to DoS
<kanzure>
.. and double spending..
wasi has quit [Ping timeout: 245 seconds]
wasi has joined #bitcoin-wizards
rhett has joined #bitcoin-wizards
se3000 has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
AaronvanW has quit [Remote host closed the connection]
cyphase has quit [Ping timeout: 246 seconds]
cyphase has joined #bitcoin-wizards
rhett has quit [Ping timeout: 245 seconds]
PRab has joined #bitcoin-wizards
brg444 has quit [Ping timeout: 240 seconds]
brg444 has joined #bitcoin-wizards
brg444 has quit [Remote host closed the connection]
igno_peverell has quit [Ping timeout: 245 seconds]
rhett has joined #bitcoin-wizards
sdfgdsfg has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
Chris_Stewart_5 has quit [Ping timeout: 264 seconds]
abpa has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rhett has quit [Ping timeout: 245 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 258 seconds]
jcluck has joined #bitcoin-wizards
cluckj has quit [Ping timeout: 265 seconds]
jcluck is now known as cluckj
NewLiberty has joined #bitcoin-wizards
HostFat_ has joined #bitcoin-wizards
HostFat has quit [Ping timeout: 248 seconds]
Giszmo has quit [Quit: Leaving.]
warren has joined #bitcoin-wizards
Newyorkadam has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 265 seconds]
<petertodd>
kanzure: yeah, a merkle proof for a specific bit of published data is log2(n)
<kanzure>
hi. what was your concern though?
<petertodd>
kanzure: it was unclear to me how pubkeys came into this
<kanzure>
in my scheme, i have a list of pubkeys in each block, plus an aggregate signature
<petertodd>
kanzure: what is the signature signing?
<kanzure>
so, this list is how i'm avoiding inclusion of merkle tree updates/diffs in each block
abpa has joined #bitcoin-wizards
<kanzure>
the signature signs the merkle root
<petertodd>
but why would there be any upodates/diffs in a proof-of-publication scheme?
<kanzure>
the participant is signing off that they have a merkle proof
<kanzure>
well, i'm trying to prevent against double spending
<kanzure>
in a "blocks are only a merkle root" schemes, you end up with information withholding collusion stuff-- is it a double spend? nobody knows until 50 years later when two transaction subgraphs are found that conflict...
<kanzure>
the list of pubkeys is how you know if the spender /should/ have a merkle proof for that block
<kanzure>
if they aren't in that list, then their absence of a merkle proof is entirely understandable and OK
<petertodd>
eh, I don't think that's so simple... you need a pow scheme that enforcees publication - without block contents other miners can't mine. that's a much simpler way to deal with this IMO
<kanzure>
without block contents, other miners can mine sure they can.... they can publish random merkle roots basically. it's totally fine.
<petertodd>
no, that's unacceptable - heck, the fact miners can do that in bitcoin is terrible
<kanzure>
it's all client-side :)
<petertodd>
so the obvious thing to do thre is to make the pow prove you have posession of prior block contents
<kanzure>
there are no prior block contents in my system (other than merkle roots and a list of pubkeys)
<petertodd>
bitcoin *kinda* does that in that without priuor block contents you can't be sure of validity
<petertodd>
yes, I see what you're doing now, though I'm dubious it's worth it - you still have the withholding problem on the pubkey list itself
<kanzure>
i should clarify that in my system there's really not many rules around the contents of the merkle tree --- whereas most utxo commitment schemes are really hyper-anal about the contents and structure of the tree (in a consensus enforceable way)
<kanzure>
describe withholding problem on pubkey list?
<kanzure>
the blockhash covers the list of pubkeys-- if the full list of pubkeys is unavailable, the block is de facto invalid
<petertodd>
simple, if I withoold the pubkey list, you have no ability to prove non-inclusion
<kanzure>
block validity is determined as having all block contents, so that means the merkle root and the pubkey list and the aggregate signature and the nonce
<kanzure>
and the blockhash has to match
<petertodd>
yeah, but that's exactly the type of scheme I'm talking about! but I'd argue we use probabalistic sampling to make not having full block contents drastically reduce your hashing power
<petertodd>
rmemeber that in a single-use-seal model, a message closing a seal can be ~ the size of a pubkey - just a single signature
<kanzure>
why would you want to have blocks with partially withheld information on the pubkey list in this case?
<petertodd>
I'm saying the threat is the same in both cases
<kanzure>
the threat in the "blocks are defined as valid only when: ..." case, the threat is trivially detectable. if the hash doesn't match, reject the block as invalid.
<petertodd>
sigh, do you see how your solution to the problem is just as inefficient as a single-use-seal w/ published signatures scheme?
<petertodd>
you haven't improved efficiency at all
<kanzure>
i agree it has inefficiency for sure heh
<petertodd>
and since it's no more efficient, why bother with the aggregate signature at all?
<kanzure>
what's the block data structure look like in your single-use seal scheme btw?
<petertodd>
ideally a key-value merkle tree, with the pow partly tied to proving you have posession of random samples of prior block's k-v trees
<kanzure>
and how do you do consensus enforcement of posession of random samples? everyone has to follow the entire history of the entire tree?
<petertodd>
no, you use pow as a random beacon, and prove you have posession by re-hashing those random samples
<kanzure>
OK so one modification to your scheme that i would accept, would be something like: as a client-side rule, coins that are proofed from a block that did not have the pubkey listed should be valued as less than the face value of the coin, because of the risk of double spending.
<petertodd>
same idea as behind my anti-validationless-mining bit for segwit
<kanzure>
in my scheme, i was trying to go for something like "not everyone needs to have the entire tree anyway" (unless you're spending/receiving only.)
<petertodd>
eh, those schemes quickly end up with coins being worthless
<kanzure>
(in which case you need to know if your spender is withholding information from you.....)
<kanzure>
so, by intorducing a list of pubkeys, i haven't improved efficiency, but i don't need everyone to follow an impossibly huge merkle tree update set
<petertodd>
why is it "impossibly huge"? the merkle trees in the scheme I'm talking about would be about the same size as the pubkey list
<kanzure>
er, then what's the advantage of merkelization there?
<petertodd>
er, sorry, that's not quite right... I mean, if you want to have the full block contents, they'd be about the same size
<petertodd>
if you have a wallet, you can discard all but one branch of the tree
<petertodd>
(plus the samples the PoW needs, which I believe can be kept small in number)
<kanzure>
full block contents, in your scheme, would include merkle tree updates/diffs/deltas, right? i just don't see how you're doing that otherwise.
<petertodd>
no! there's no updates/diffs/deltas at all, it's just publication
<kanzure>
but it's a merkle tree, not publication
<petertodd>
there's no block-to-block state
<petertodd>
no, the merkle tree is how the block is hashed - that's still publication
<petertodd>
that's like saying because bitcoin blocks are hashed as merkle trees, they're not publication
<kanzure>
as a recipient, how do i know if you're withholding information from your participation in a block?
<petertodd>
because the subset of info where you could publish a spend is constrained by the key associated with the seal
Chris_Stewart_5 has quit [Ping timeout: 250 seconds]
<petertodd>
it's like defining the publication of where something you be in a bitcoin block as "must be in tx #3 and no other"
<kanzure>
okay... but you don't know the contents of the merkle tree. it wasn't published. you can only receive this from the spender.
<kanzure>
you can check if the spender is giving you the right path of course-- but only if they give you something
<petertodd>
but you do know the block header, and thus I'd be giving you proof of what was published for that block for the specific key
<petertodd>
if I don't give you that proof, I haven't proven to you that the coin is valid
<kanzure>
yes-- so let's say you own 1 coin, you're offline, a block is made, you don't have a proof that you didn't spend during that block. you're saying that clients are able to reconstruct a proof-- without communicating with miners? how? there's no block contents to look at...
Chris_Stewart_5 has joined #bitcoin-wizards
<petertodd>
why would they have to communicate with miners? like any system, they ask someone who is running a node with block contents
<petertodd>
similarly, in your pubkey scheme, if they can't find someone willing to give them that minimal block contents they're screwed
<kanzure>
okay.. but the miner didn't publish block contents. at least, according to your description of the scheme.
<kanzure>
the spender should be willing to give the block contents
<petertodd>
huh? miners do publish block contents - they have to distribute thre blocks they mine to other miners, or those other miners won't build on top of them
<kanzure>
okay, so your scheme is not "blocks have a list of pubkeys", it's a list of other contents apparently?
<petertodd>
basically, I want a PoW scheme where if you don't have a high % of prior block contents, your mining efficiency will drop quickly - that appears to be doable
<petertodd>
blocks are a key-value mapping
<petertodd>
note how in bitcoin, blocks are *also* a key-value mapping, where the keys are tx #'s
<kanzure>
i need a more declarative statement of your key-value tree. it's supposed to be a set of single-use seals, right?
<petertodd>
no, it's data being published; single-use-seals aren't published themselves; messaging closing seals are published
<petertodd>
*messages
<kanzure>
ok. and the assertion is that seal closing messages are better than a list of pubkeys somehow. and,
<petertodd>
yeah, it's certainely simpler
<kanzure>
and your statement is that my solution to information withholding is a non-solution (or something), so therefore we shoud use a list of messages that close seals
abpa has quit [Ping timeout: 258 seconds]
<petertodd>
I'm saying I don't think you actually solved it in a way that's any more efficient
<kanzure>
when you're offline (in my scheme), the list of pubkeys is useful because you can prove to your recipient that you were not involved in that block
<petertodd>
since I need the full list of pubkeys anyway, I might as well just publish the set of messages closing seals fo rthat particular block instead of the list
<petertodd>
but you can equally prove that by showing that the messages published aren't valid closes of the seal you want to prove wasn't closed
<kanzure>
so... wait. what? i thought in your system, you have to check each possible message against whatever you're verifying as a recipient, right? so wouldn't that be less efficient?
<kanzure>
*each given message in the block
<petertodd>
you mean bandwidth efficient or computationally efficient?
<kanzure>
yea i guess we should limit to talking about bandwidth efficiency, since that was my original goal, sorry
<kanzure>
and bandwidth efficiency should be about the same i think
<petertodd>
right, so if bandwidth efficiency is the same, why add all that complexity? I doubt computational efficiency will matter as much as bandwidth
<kanzure>
but now i'm uncertain about any difference in the two schemes. in my proposal, there's a computational advantage at least, it's a key look up and a signature verification, whereas yours i think you have to computationally check everything.
<petertodd>
verifying that signatures fail is cheap and quick
<petertodd>
sure, I agree there's an advantage, I just doubt the computational advantage is worth the cost
<kanzure>
ok w/e that's a trivial detail that i doubt either of us care about
<kanzure>
i'm still munching on your information withholding claims
<kanzure>
my specific goal was information withholding from the *spender*, not information withholding from miners
<petertodd>
right, but I'd argue, to prevent the former you need to prevent the latter - if you assume that mining is decentralized
<kanzure>
er i mean, withholding perpetuated by a spender. and i was assuming that miners publish all the details so that miners will build on a hashing-valid block.
<petertodd>
well, I'm asuming that spender has to prove to recipient that they haven't withheld
<petertodd>
if you assume minres publish everything, this gets a lot easier
<kanzure>
miners could publish less than everything, but it would be invalid.......
<kanzure>
(and my goal was to make "everything" be very bandwidth friendly)
<petertodd>
yes, because you have an inefficient flat block structure - that's not bandwidth friendly
<petertodd>
if my seal publication scheme did that I'd be done and trivially so
<kanzure>
my problem was that i was assuming client-side validation proposals for the block structure were including merkle tree updates/diffs stuff. i didn't know someone had proposed just a list of seal closing messages in the block.
<petertodd>
yeah, it's a pretty minimalist proposal, and one I haven't written up fully yet (working on it!)
<kanzure>
this is partly a result of most previous merkle root proposals being about utxo commitments and "gee how do we efficiently communicate utxo merkle tree updates in a consensus compatible way" stuff
<petertodd>
yup
<kanzure>
what precisely is the missing ingredient that you are looking for?
alpalp has quit [Ping timeout: 240 seconds]
<petertodd>
I'm not sure if I am missing anything required to make this feasible actuallyt
<petertodd>
I've got a bit of work to improve the efficiency by maybe another 100x
<petertodd>
(unpublished work)
<kanzure>
it just feels so dumb that we don't have anything that is a constant sized merkle root for the block data structure and that's it
<kanzure>
we should start from "everything is constant sized" and work backwards, instead of doing the design the other way
<petertodd>
?
<petertodd>
ah, but see, so in tree chains, what you'd have is more like that
<kanzure>
well i mean, my reason for thinking about merkle roots in the first place was i wanted a million transactions in a block capped to 100 kilobytes or something heh
<petertodd>
yeah, see I don't think that works - need to shard mining
Newyorkadam has quit [Quit: Newyorkadam]
<kanzure>
i have another proposal cooking where everyone has their own personal ledger and they do block signing stuff, and then they track a number of other ledgers from other people, and it's all p2p in a very disgusting way.... but yeah.
<petertodd>
sounds compelx :)
<kanzure>
where are you getting your 100x from..? was that 100x in bandwidth?
HostFat_ has quit [Quit: Leaving]
<petertodd>
100x reduction in bandwidth
<kanzure>
i guess basic stuff like picking a better encoding scheme can provide some of that...?
<petertodd>
well, this is a clever probabalistic scheme
rhett has joined #bitcoin-wizards
wasi has quit [Ping timeout: 245 seconds]
GAit has quit [Ping timeout: 250 seconds]
GAit has joined #bitcoin-wizards
wasi has joined #bitcoin-wizards
stiell has joined #bitcoin-wizards
alpalp has joined #bitcoin-wizards
alpalp has joined #bitcoin-wizards
alpalp has quit [Changing host]
rhett has quit [Ping timeout: 268 seconds]
alpalp has quit [Ping timeout: 268 seconds]
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
TheSeven has quit [Ping timeout: 258 seconds]
pro has quit [Quit: Leaving]
TheSeven has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 258 seconds]
wasi has quit [Ping timeout: 245 seconds]
wasi has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
arubi has joined #bitcoin-wizards
priidu has quit [Ping timeout: 268 seconds]
rhett has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
aalex has quit [Read error: Connection reset by peer]
aalex has joined #bitcoin-wizards
wasi has quit [Ping timeout: 245 seconds]
wasi has joined #bitcoin-wizards
paveljanik has quit [Quit: Leaving]
paveljanik has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
paveljanik has quit [Changing host]
Chris_Stewart_5 has quit [Ping timeout: 264 seconds]
BashCo has quit [Remote host closed the connection]
BashCo has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 252 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
paveljanik has quit [Quit: Leaving]
BashCo has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
edvorg has joined #bitcoin-wizards
<fluffypony>
yes
<fluffypony>
wrong window, lo.
<fluffypony>
lol
AaronvanW has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
JackH has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 268 seconds]
ratbanebo has joined #bitcoin-wizards
CrazyLoaf has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
<luke-jr>
jl2012: why would you suggest softforking a larger locktime, in the context of a HF? :P
<jl2012>
Well, you still want to keep some kind of backwards compatibility
<jl2012>
Changing the tx format would be too much
<jl2012>
Another option is a secondary witness for both absolute and relative lock time. Also a soft fork
<jl2012>
Or just make lock time as part of scripts
<jl2012>
I'm actually doing something like that. Users may sign a script. So signing a CLTV is same as per input nLockTime
<jl2012>
Will tidy it up and publish soon
alferz has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
alferz has quit [Ping timeout: 244 seconds]
maaku has quit [Ping timeout: 260 seconds]
maaku has joined #bitcoin-wizards
BashCo_ has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 264 seconds]
maaku has quit [Ping timeout: 260 seconds]
alpalp has joined #bitcoin-wizards
alpalp has joined #bitcoin-wizards
alpalp has quit [Changing host]
maaku has joined #bitcoin-wizards
alferz has joined #bitcoin-wizards
rhett has quit [Ping timeout: 264 seconds]
alferz has quit [Ping timeout: 244 seconds]
sdfgdsfg has quit [Quit: Noam Chomsky]
alferz has joined #bitcoin-wizards
ThomasV has quit [Quit: Quitte]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
bsm1175321 has quit [Remote host closed the connection]
bsm1175321 has joined #bitcoin-wizards
ManfredMacx has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
alpalp has quit [Ping timeout: 265 seconds]
BashCo_ has quit [Ping timeout: 265 seconds]
BashCo has joined #bitcoin-wizards
Giszmo has joined #bitcoin-wizards
edvorg has quit [Ping timeout: 246 seconds]
paveljanik has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
paveljanik has quit [Changing host]
pro has joined #bitcoin-wizards
gribble has quit [Disconnected by services]
gribble has joined #bitcoin-wizards
Giszmo has quit [Ping timeout: 258 seconds]
Giszmo has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
retrohacker has left #bitcoin-wizards [#bitcoin-wizards]
ManfredMacx has quit [Quit: Bye]
laurentmt has joined #bitcoin-wizards
BashCo_ has joined #bitcoin-wizards
Topogetcyrpto has quit [Quit: Topogetcyrpto]
laurentmt has quit [Client Quit]
draynium_ has quit [Ping timeout: 248 seconds]
BashCo has quit [Ping timeout: 250 seconds]
se3000 has joined #bitcoin-wizards
<Taek>
petertodd: Your linearization scheme couldn't use bloks as a random beacon unless you had some way to prove that the maximum expected value that could be created by re-rolling a block is less than the value of the block
<Taek>
which means you'd have to limit the size of a transaction spend
<Taek>
no, you'd have to limit the size of all transactions spent within the block
<Taek>
If I spend 50 transactions that are $10,000 each in a single block (but only $5,000 is real, the rest is fraud), the variance on the outcome of the solution is going to exceed the cost of tossing a block.
<Taek>
further, if I understand correctly, this sort of attack can go completely undetected because I never need to publish the results of the transactions that end up fraudulent. I can keep the failures to myself.
MoALTz has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 258 seconds]
Topogetcyrpto has joined #bitcoin-wizards
<JackH>
where is Peter Todds alternative merkle tree structure? I believe I read something about a key:value type of tree
BashCo_ has quit [Remote host closed the connection]
BashCo has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
BashCo has quit [Ping timeout: 265 seconds]
devylon has joined #bitcoin-wizards
Topogetcyrpto has quit [Ping timeout: 250 seconds]
Topogetcyrpto has joined #bitcoin-wizards
igno_peverell has joined #bitcoin-wizards
BashCo has joined #bitcoin-wizards
Aranjedeath has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
ThomasV has joined #bitcoin-wizards
se3000 has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
NewLiberty_ has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 258 seconds]
<Taek>
I had an alternate idea for preventing exponential blowup of spending - make it illegal to merge outputs
<Taek>
if outputs only ever split, then their history can only grow linearly
<Taek>
people with more money will typically end up with more outputs and therefore more history, but it sort of makes sense that there is more burden to send lots of money than to send only a little money
<Taek>
I think it's also pretty easy to measure the cost of splitting an output
<Taek>
spending a split output to two different people requires sending twice as much history
<Taek>
and every time the output is sent the amount of history increases by a small amount
<Taek>
If you assume some discount for history, you can discount the value of an output based on how much history it has
<Taek>
this is no different than sending a transction fee
NewLiberty_ has quit [Ping timeout: 258 seconds]
<Taek>
the output amount may say 0.1btc, but if it carries 50MB of history, you might discount it to 0.099 btc. Then when you send it, that next person discounts it to 0.989 btc, just a tiny bit less than what I was counting it as
<Taek>
*0.0989
<Taek>
since I only received it as 0.099, my cost to send it was not too high
<Taek>
If I choose to split it though (say, send half of it to that person and half of it back as change), I'll have to double the discounts. The receiver is going to disount by 0.0011, and I'm going to have to discount the change address by another 0.0011 for when I want to spend it again
<Taek>
That becomes I think a fairly simple optimization process when a wallet is trying to figure out the best way to send outputs
<Taek>
I guess it's a little harder, because someone who intends to split outputs frequently is going to prefer having outputs with little history
<Taek>
as the cost of doubling that history is cheaper
<Taek>
hmm
<Taek>
I guess it's only easy to price the discount of an output if you know in advance how many times you'll need to split it
<Taek>
Though, if you want to get really ugly you could probably set up networks of output trading, where people with lots of tiny outputs will trade you for your big outputs, so that you don't need to do history splitting.
rhett has joined #bitcoin-wizards
priidu has joined #bitcoin-wizards
MoALTz_ has joined #bitcoin-wizards
se3000 has joined #bitcoin-wizards
MoALTz has quit [Ping timeout: 248 seconds]
danrobinson has joined #bitcoin-wizards
<danrobinson>
taek: didn't someone suggest this separately as a solution for anonymity of transactions that are validated on-chain?
<kanzure>
Taek: privacy implications of splitting can probably be resolved through other means anyway (confidentiality through various moon magics)
<kanzure>
another way to solve information withholding problems is if you could give someone a copy of block data in such a way that the recipient must pay a certain fee for receiving and utilizing that version of the data
<kanzure>
and then you just have to agree on the fee, and pay it, or provide some reasonable evidene of being able to pay for it
nikivi has joined #bitcoin-wizards
<bsm117532>
Doesn't this stink of "solving cryptographic problems with economics" though?
<kanzure>
crypto cannot stop someone from withholding information from you
nikivi has quit [Client Quit]
<kanzure>
the miner can distribute the block contents to the recent spnders and to other miners (like in coalitions or collusion schemes); optimal defense i guess is to not require knowledge of previous merkle tree contents --- any block can have a totes random merkle tree decided by whatever happy miner got that block.
* bsm117532
is reading about Oblivious Transfer again.
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
<yoleaux>
bsm117532: Sorry, that doesn't appear to be an HTML page.
<bsm117532>
An OT extension protocol
<bsm117532>
operations only.
<bsm117532>
hundred) that are used as a base for obtaining many OTs via the use of cheap symmetric cryptographic
<bsm117532>
works by running a small number of “base OTs” depending on the security parameter (e.g., a few
<bsm117532>
This is conceptually similar to public-key encryption where instead of
<bsm117532>
then used to encrypt the large message.
<bsm117532>
is used such that the RSA computation is only carried out to encrypt a symmetric key, which is
<bsm117532>
encrypting a large message using RSA, which would be too expensive, a hybrid encryption scheme
se3000 has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Chris_Stewart_5 has joined #bitcoin-wizards
<bsm117532>
I'm thinking of a totally different context though: SPV clients obtaining the contents of their wallet without the server knowing anything about their wallet.
se3000 has joined #bitcoin-wizards
Chris_Stewart_5 has quit [Ping timeout: 264 seconds]
<bsm117532>
Since blockchain data can be independently validated against the block headers, blockchain data censorship reduces to (a) falsifying PoW headers or (b) isolating the target from contacting non-censoring servers (e.g. DDoS).
<kanzure>
not quite just (a)--- is it false if nobody ever checks? etc.
Chris_Stewart_5 has joined #bitcoin-wizards
<bsm117532>
I'm assuming SPV clients have block headers. (again I know we're thinking about different problems)
ThomasV has quit [Ping timeout: 258 seconds]
MoALTz_ is now known as MoALTz
abpa has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chjj has quit [Ping timeout: 246 seconds]
abpa has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
blackwraith has joined #bitcoin-wizards
priidu has quit [Ping timeout: 240 seconds]
Aranjedeath has quit [Quit: Three sheets to the wind]
nikivi has joined #bitcoin-wizards
belcher has quit [Ping timeout: 250 seconds]
nikivi has quit [Quit: zzz]
nikivi has joined #bitcoin-wizards
nikivi has quit [Quit: irc]
belcher has joined #bitcoin-wizards
sausage_factory has joined #bitcoin-wizards
<bsm117532>
These protocols have a tremendous amount of overhead in "checks" that the server is sending you the correct data. I wonder how much it could be sped up if you're accessing a data structure with its own internal, DMMS-type cryptographic consistency check. You could get corrupted data, but it seems to me a retry costs less than all their checks...
blackwraith has quit [Ping timeout: 256 seconds]
blackwraith has joined #bitcoin-wizards
sausage_factory has quit [Ping timeout: 250 seconds]
d9b4bef9 has quit [Remote host closed the connection]
sausage_factory has joined #bitcoin-wizards
d9b4bef9 has joined #bitcoin-wizards
blackwraith has quit [Ping timeout: 248 seconds]
rusty2 has joined #bitcoin-wizards
sausage_factory has quit [Ping timeout: 250 seconds]
priidu has joined #bitcoin-wizards
se3000 has quit [Quit: My iMac has gone to sleep. ZZZzzz…]