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
<tromp>
sizeshift doesn't need 4 bytes. 1 byte obviously suffices:)
<tromp>
same for proofsize
<tromp>
you could also make that halfproofsize
<tromp>
allowing up to length 510 cycles
<kallewoof>
Hm.. I agree sizeshift should be 1 byte but proofsize could just stay at 4 for simplicity, no?
<tromp>
if you want to be extremely flexible, then you could go up to 2 bytes
<tromp>
but 4 bytes is way overkill
<kallewoof>
Fair enough..
<kallewoof>
So, sizeshift 1 byte, proofsize 2 bytes
<tromp>
yes, both unsigned of course
<kallewoof>
*nod*
<tromp>
your sizeshift is alrd limited by edges being 32 bit
<tromp>
that means you cannot handle sizeshift > 33
<kallewoof>
Because I'm using uint32's?
<tromp>
yes
<kallewoof>
Should I switch to uint64's?
<tromp>
only if you can imagine requiring many minutes of time per proof attempt, or dozens of GB of memory use
<kallewoof>
Feels like it's taking a lot of space already. That switch would double the proof size. I think it's like 180 bytes now
<kallewoof>
Yeah, I think we can make that a separate pow id when that day comes.
<kallewoof>
Or fix the code to deal when sizeshift > 33
<tromp>
with 1 byte halfproofsize, the smallest proof you cannot handle is 510*4 = 2040 bytes
<kallewoof>
Right now shiftsize / proofsize are #defined and unchangable. I obviously want to change that but I wanted to keep the imported code as close to the original as possible initially.
<tromp>
i think only a real consensus PoW would need sizeshift > 33
<kallewoof>
s/shiftsize/sizeshift
<tromp>
it's *way* too much work for any rate limiting purposes, even many decades from now
<kallewoof>
Yeah, I am keeping the values way too low as it is to keep things feasible. I would like to optimize to be able to raise the sizeshift / memory requirements.
<tromp>
is there something like a varint array?
<tromp>
edges should only be larger than uint32 if sizeshift is more than 33
<kallewoof>
for (int i = 0; i < 42; i++) varint[i] = deserialize(...);
<kallewoof>
^ like that, you mean?
<tromp>
i mean the size encoding is done only once for all 42 values
<kallewoof>
Ahh. If that's the case you could just put in a 1 byte size parameter at the beginning and then spew the values, no?
<kallewoof>
e.g. \0x02 [uint16] [uint16] ...
<tromp>
well the edge size is implied by sizeshift alrd
<tromp>
what zcash did is actually encode proof as n*k bits, for n indices each of which fits in k bits
<tromp>
that is most compact, but takes some more effort to (de)serialize
<kallewoof>
Yeah... ideally this should be easy to do for anyone.
<kallewoof>
I will check out the zcash method though
<tromp>
with fixed proofsize, there is a lot of variance in #attempts needed
<kallewoof>
Yeah, I've noticed.
<tromp>
which is not that desirable for rate limiting purposes
<tromp>
there is a simple way to avoid that
<tromp>
allow a range of proofsizes
<kallewoof>
Ahh.. right.
<tromp>
e.g. any size from 34 to 64
<kallewoof>
I think that is definitely the way to go. :)
<tromp>
yes, the single size was really picked with consensus pow in mind
<tromp>
it's good to be picky there
<kallewoof>
Right. Would it be a useful idea to use the range as a way to tune difficulty? I.e. a node under high pressure might shrink the range. Right now the approach is SHA256(cuckoo-cycle()) < target where target is tuned
<tromp>
yes, it can be used as a rough difficulty control. it's just not as precise as what hashcash allows
rusty has quit [Ping timeout: 260 seconds]
<tromp>
and the range of difficulties would be a priori limited
isle2983 has quit [Ping timeout: 240 seconds]
asok has quit [Ping timeout: 252 seconds]
<kallewoof>
*nods* Well, that's nice. Ideally I would like the CC version to be relatively speedy but require lots of RAM. I'll play around with a proofsize range and see what I can find.
<tromp>
e.g. from lowest difficulty [12,254] to highest difficulty [254,254]
<kallewoof>
Why 254 as max?
<tromp>
still have 1 byte encoding in mind:)
<kallewoof>
Oh. Wouldn't it be 255 though?
<tromp>
also, you don't want proofs larger than 1 KB
<tromp>
cycle lengthb always even
<kallewoof>
oh right.
<tromp>
those ranges are about a factor 200x in diffculty apart
asok has joined #bitcoin-wizards
<tromp>
if you need a wider range, then sha256 check on top seems necessary
Guest76166 has quit [Remote host closed the connection]
<kallewoof>
I think the standard approach will be SHA256(CC) but I could be wrong. It's up to the nodes. Or should be, anyway. (Right now it's hard coded.)
<tromp>
well, of course yhou can also increase size for extra difficulty
<kallewoof>
I made an attempt at making sizeshift variable but ran into some issues. Can't remember what, now, but that should be done, ideally.
<tromp>
did you rewrite cuckoo cycle to allow hex headers?
<tromp>
or do your test vectors happen to be ASCII?
btcdrak has quit [Quit: Connection closed for inactivity]
cluckj has joined #bitcoin-wizards
<kallewoof>
I am just shoving binary data into it.
<kallewoof>
No rewrites. It seems to work fine, though?
<kallewoof>
I am using cuckoo_miner.h and cuckoo.h, mostly unmodified.
<tromp>
from which code do you run your testvectors?
<kallewoof>
I am not actually running those test vectors in the code right now. I pulled them directly out of a peer-to-peer challenge/solution interaction as someone wanted test vectors. I intend to add them to the tests. There is one test using arbitrary data in pow_cuckoo_cycle_tests.cpp right now.
<tromp>
i see
<tromp>
ok; looking forward to see your bip gain traction. let me know if you have any more cuckoo cycle questions
edvorg has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
Samdney has quit [Quit: Verlassend]
<kallewoof>
Thanks, I will!
jtimon has quit [Ping timeout: 240 seconds]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
Giszmo has quit [Quit: Leaving.]
AaronvanW has quit [Ping timeout: 255 seconds]
King_Rex has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-wizards
talmai has joined #bitcoin-wizards
punindented has quit [Quit: Connection closed for inactivity]