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
<mmeijeri>
would be a nice little side project
<BlueMatt>
naa, the wirehair stuff is super well optimized - its written to be fast and smart about memory usage, not neccessarily perfect against people giving it garbage data, I think
<mmeijeri>
though I need to need to start making some money soon...
<mmeijeri>
ah ok
<BlueMatt>
but the guy who wrote it seems to be a pretty competent engineer, so I wouldnt be surprised if there werent any major issues
<BlueMatt>
heh, what, bitcoin holdings arent enough to live on? :p
<petertodd>
BlueMatt: my understanding was there's a variance exploit with previous attempts at this stuff
<BlueMatt>
previous attempts included a "compressed section" as well as an uncompressed section on top to address that (at least slightly), yes
<petertodd>
BlueMatt: right
Chris_Stewart_5 has joined #bitcoin-wizards
<BlueMatt>
somehow i remembered the numbers on doing that being more than sufficient, but i may be wrong
Newyorkadam has quit [Quit: Newyorkadam]
<uiuc-slack1>
<amiller> petertodd: i and a couple others are working on that, its not too hard
<petertodd>
amiller: good to hear
<petertodd>
amiller: eta?
<uiuc-slack1>
<amiller> three weeks?
<uiuc-slack1>
<amiller> ive learend my lesson, two weeks isn't prudent, so 3 seems reasonable
<BlueMatt>
lol
<petertodd>
amiller: heh, looking forward to it then!
<mmeijeri>
@bluematt: would putting the wirehair stuff into a separate process help?
<uiuc-slack1>
<amiller> what is wirehair?
<BlueMatt>
amiller: the fec used in fibre
<uiuc-slack1>
<amiller> ah, neat
<BlueMatt>
its actually super impressive...if you ever need a fec for something, I'd highly recommend it instead of all of the other random garbage floating around
<BlueMatt>
mmeijeri: i suppose that would alleviate some concerns, yes?
<BlueMatt>
specifically the wh256 variant
<mmeijeri>
might help with scaling too, if that's an issue
<BlueMatt>
you mean to be able to freely thread it?
<mmeijeri>
yeah, possibly using docker swarm
<BlueMatt>
you'd probably blow too much time streaming the data back and forth between instances, I'd think
<mmeijeri>
all inside a data center though
<BlueMatt>
and i dont think its super scalable, but would have to go dig
<BlueMatt>
so if you're in trusted mode i dont think it'll help much
<mmeijeri>
but then you'd lose the advantage of joint reconstruction, so it's probably not a good idea
<BlueMatt>
i mean...the single-threaded performance of the thing is like a few ms to encode/decode...dont think its a big deal
<mmeijeri>
right
<BlueMatt>
might help if you're doing multi-untrusted-peer reconstruction
<mmeijeri>
let's not prematurely optimise it then!
<BlueMatt>
because those use different fec instances
<mmeijeri>
of course it has been enormously optimised already
<BlueMatt>
yea, all this stuff is pretty heavily tuned already, im not too worried about it
<BlueMatt>
i would have to go revisit if we're talking about 10MB blocks, but for what its targeted at its pretty good
kenshi84 has joined #bitcoin-wizards
rusty2 is now known as rusty
<BlueMatt>
rusty: did you ever go back and sync up with greg about mempool sync using iblts?
<BlueMatt>
(or the tradeoffs between iblt and other encoding schemes for that)
blackwraith has quit [Ping timeout: 260 seconds]
<rusty>
BlueMatt: no... I guess there are two reasons for mempool sync, one is to save inv bandwidth, and second is to use that knowledge of others' mempool state for more aggressive block compression. But there's enough hair involved in any scheme (how often do you send, how do you handle privacy issues with new txs, etc) that it's more than I'm prepared to chew right now.
<BlueMatt>
I'm not convinced about the second option, but there is a better second option: to improve privacy by relaying transactions slower
<BlueMatt>
ie if you're only relaying transactions once per minute to your peers, they're all bucketed
<BlueMatt>
and its harder to do transaction-origin attacks
<BlueMatt>
of course this assumes we dont want to get rid of the mempool command and associated expose-your-mempool attacks
<BlueMatt>
though I think policy has generally be to not fix such issues, because too hard
<BlueMatt>
(such issues being fingerprinting that two nodes, connected to over different networks, are actually the same node)
Chris_Stewart_5 has quit [Quit: WeeChat 0.4.2]
bildramer1 is now known as bildramer
<rusty>
BlueMatt: yeah, you need to share state if you want to close down those last few missing txs without a RTT. It's unclear if we need that in the short term though.
<BlueMatt>
agreed
<BlueMatt>
and think likely not
<BlueMatt>
esp if we use double-spends in compact block reconstruction
<rusty>
?
<BlueMatt>
eg txn that dont make it into our mempool because we saw a conflicting one first
<BlueMatt>
remember some limited number of them
Ylbam has quit [Quit: Connection closed for inactivity]
<BlueMatt>
and use for compact block reconstruction
<BlueMatt>
attacker always wins, obviously, but not a huge deal
AnHry has joined #bitcoin-wizards
<BlueMatt>
i mean you can also use a fibre-like encoding over tcp
<BlueMatt>
or just fibre's encoding
<rusty>
BlueMatt: yeah, with RBF that may become a thing. Though in practice, perhaps not, since that will mainly be used for things unlikely to get into a block.
<BlueMatt>
send limited amount of fec along with block to recover top 10k of missing txn or so
<BlueMatt>
rusty: well rbf should, in theory, converge across the network
<BlueMatt>
but, yea, have to remember limited number of rbf txn as well
<rusty>
BlueMatt: yeah, but miners tend to lag creating new blocktemplates AFAICT, so may happen more than naively expected?
<BlueMatt>
well many miners are giving up $$$$ to avoid running rbf
<BlueMatt>
plus, yes, there is lots of lag there
<rusty>
Anyway, we can always beat any scheme with more direct knowledge of mempools, by knowing missing txs. Of course, once we're under a handful of packets it's theoretical.
Newyorkadam has joined #bitcoin-wizards
<BlueMatt>
I'd prefer to send 10kb of fibre fec over keeping knowledge....
<BlueMatt>
i mean if you end up needing much more than that the numebr of tcp rtts is gonna be nontrivial, so doing a protocol-level rtt shouldnt matter much
<rusty>
BlueMatt: with fees a thing now, I think we'll see more "like I expected" blocks, so the problem becomes easier. Some heuristics as to how much FEC data to send may end up being Good Enough (eg. get aggressive if block is exactly what I expected).
<BlueMatt>
yea
AlineGomes has joined #bitcoin-wizards
ptrx has quit [Ping timeout: 260 seconds]
<mmeijeri>
why are miners avoiding running rbf?
* mryandao
is curious too
propumpkin has joined #bitcoin-wizards
copumpkin has quit [Ping timeout: 256 seconds]
bramc has joined #bitcoin-wizards
<bramc>
Looking at my code coverage is a bit depressing. Days of debugging and I'm still staring at a sea of red
rusty has quit [Read error: Connection reset by peer]
rusty2 has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
jtimon has quit [Ping timeout: 256 seconds]
bramc has quit [Ping timeout: 260 seconds]
mmeijeri has quit [Quit: Page closed]
pro has quit [Read error: Connection reset by peer]
pro has joined #bitcoin-wizards
AnHry has quit [Quit: Konversation terminated!]
uiuc-slack1 has quit [Remote host closed the connection]
uiuc-slack has joined #bitcoin-wizards
cyphase has quit [Ping timeout: 258 seconds]
rusty2 has quit [Ping timeout: 240 seconds]
cyphase has joined #bitcoin-wizards
<gmaxwell>
BlueMatt: I'm of the opinion that iblt is not that interesting because the constant factor overheads are considerable.
<gmaxwell>
And at least on the numbers I was modling for mempool sync, wiped out a lot of the potential gains.
<gmaxwell>
(also we don't care if it's super cpu fast.)
JayDugger has joined #bitcoin-wizards
<bitcoin-wizards8>
to gmaxwell - how do you c bitcoin change in the next 2 years?
<bitcoin-wizards8>
wil there be new functions ?
JayDugger has quit [Quit: Leaving.]
<bitcoin-wizards8>
What is the developers vision ?
CubicEarth has joined #bitcoin-wizards
Burrito has quit [Quit: Leaving]
pro has quit [Quit: Leaving]
bitcoin-wizards8 has quit [Ping timeout: 260 seconds]
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 255 seconds]
NewLiberty_ has joined #bitcoin-wizards
NewLiberty_ has quit [Ping timeout: 256 seconds]
<fluffypony>
wut
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #bitcoin-wizards
copumpkin has joined #bitcoin-wizards
propumpkin has quit [Ping timeout: 248 seconds]
Ylbam has joined #bitcoin-wizards
Fibonacci has joined #bitcoin-wizards
<Fibonacci>
I have an idea to improve forks in crypto
<Fibonacci>
Rather than simply a double which can be disruptive to a coins ecosystem so to speak
<Fibonacci>
Use a more optimal ratio
<Fibonacci>
Namely the Golden ratio
<Fibonacci>
This mimics natural growth and could be a much more fluid way to achieve a more equitable trading value for coins that require inflationary methods
<Fibonacci>
1.61803398875
<Fibonacci>
I call it a Fibonacci Fork
<Fibonacci>
Because the Golden ratio can be approximated as you add and divide the numbers of the Fibonacci sequence
<Fibonacci>
For coins containing 21m coins this works quite nicely because it happens to be a Fibonacci number
<Fibonacci>
So inflation to the next number of coins at the golden ratio falls to another fibonacci number 34. Adding the zeros still keeps the ratio harmonious.
<Fibonacci>
This natural growth progression is optimal for many reasons and a dramatic improvement on traditional halving methods.u
<Fibonacci>
I propose we implement this method on a project and see if there are advantages that can be gleaned and perhaps even implementation can be further progressive in other financial arenas.
<Fibonacci>
Coins or stocks without a fibonacci number of units can simply be forked or split at the golden ratio 1.61803398875
<Fibonacci>
Thanks for considering my concept for improving this important aspect of global trade
<Fibonacci>
JordanBockart@gmail.com for feedback
<Fibonacci>
Best regards
moli_ has joined #bitcoin-wizards
Newyorkadam has quit [Quit: Newyorkadam]
Newyorkadam has joined #bitcoin-wizards
kenshi84 has quit [Remote host closed the connection]
kenshi84 has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 255 seconds]
kenshi84_ has joined #bitcoin-wizards
BashCo has quit [Remote host closed the connection]
BashCo has joined #bitcoin-wizards
kenshi84_ has quit [Ping timeout: 260 seconds]
BashCo has quit [Ping timeout: 256 seconds]
Guyver2 has joined #bitcoin-wizards
norotartagen has joined #bitcoin-wizards
BashCo has joined #bitcoin-wizards
CubicEarth has quit []
kenshi84 has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 248 seconds]
AlineGomes has quit [Quit: Connection closed for inactivity]
kenshi84 has joined #bitcoin-wizards
wasi has quit [Ping timeout: 255 seconds]
paveljanik has quit [Quit: Leaving]
wasi has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 255 seconds]
Guyver2 has quit [Quit: :)]
uiuc-slack has quit [Remote host closed the connection]
uiuc-slack has joined #bitcoin-wizards
Fibonacci has quit [Quit: Connection closed for inactivity]
droark has quit [Read error: Connection reset by peer]
[d__d] has quit [Remote host closed the connection]
[d__d] has joined #bitcoin-wizards
kenshi84 has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 240 seconds]
aalex has quit [Read error: Connection reset by peer]
BashCo has joined #bitcoin-wizards
aalex has joined #bitcoin-wizards
BashCo has quit [Read error: Connection reset by peer]
BashCo_ has joined #bitcoin-wizards
Newyorkadam has quit [Quit: Newyorkadam]
jannes has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
nba_btchip has quit [Ping timeout: 258 seconds]
Fibonacci has joined #bitcoin-wizards
nba_btchip has joined #bitcoin-wizards
c0rw1n_ has joined #bitcoin-wizards
c0rw1n has quit [Ping timeout: 240 seconds]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
pro has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
Sosumi has joined #bitcoin-wizards
sipa has joined #bitcoin-wizards
<bsm117532>
So I was just thinking about petertodd's opentimestamps. What (if anything) would be wrong with incorporating the root of the timestamp tree into the block header? (Making the bitcoin node be the "calendar server" equivalent of petertodd's software)
<bsm117532>
This also presents the possibility that adding timestamps could be paid for with tx fees.
<sipa>
that burdens every node with more header data, including those who do not care about timestamps
<bsm117532>
There's really no good reason to have multiple people competing for block space with different calendar servers and different OP_RETURN transactions.
<sipa>
absolutely
<sipa>
thankfully, you only need one
<bsm117532>
sipa but it's more economical to have only one root hash than a bunch of OP_RETURNS.
<sipa>
false dichotomy
<sipa>
you can have a single OP_RETURN with the same functionary as putting it in the header
<bsm117532>
Well then I'd assert that all users would want timestamps, including light clients, and therefore need the timestamp root hash in any case.
<sipa>
to have a single header root requires coordination between the multiple timestamp services
<sipa>
that seems crazy
<bsm117532>
Hahaaaa
<sipa>
by incorporating it into the same tree as transactions, you minimize the upfront costs for everyone
<sipa>
in exchange for a logsize growth of the proof size
<bsm117532>
Holding a Merkle proof for the timestamp txn, in addition to block headers is a larger burden on headers-only clients than having a single hash in the block header.
<bsm117532>
Regarding coordination: that's exactly why I'm suggesting to move the functionality into the coind itself.
<sipa>
i really don't understand why you think these are related issues
<sipa>
you need coordination to combine multiple commitments into one
<bsm117532>
I'm confused. Which two things do you think are unrelated?
<sipa>
that applies both to having it in the header or in an OP_RETURN or in a dummy coinbase output or in short-last-branch output
<sipa>
if you're able to build the infrastructure for coordination, you can just as well do it for an OP_RETURN
<kanzure>
this relieves the pressure on the blockchain to contain irrelevant data
<kanzure>
bsm117532: i think the more interesting aspect of the calendar server concept is that, it could be applied to transactions (clients must hold the data to prove their transaction happened)
<sipa>
and by putting it into the header you get an O(1) size increase for every node, for every block
<sipa>
not coordination
<sipa>
so the question is just about the proof costs
<sipa>
by using an output, you get a O(log n) size increase per individual proof, for the single party interested in the timestamped data
<sipa>
i think it's ridiculous to think the O(1) for everyone is ever a better deal
<kanzure>
sipa, i think bsm117532 is trying to argue that consensus among bitcoin node operators and miners is probably easier than consensus among OP_RETURN users or something for "which OP_RETURN gets to be the single OP_RETURN".
<bsm117532>
Conversely I think it's ridiculous to think a financial system can be useful without timestamps! :-P
<sipa>
bsm117532: i agree
<sipa>
but we already have timestamps
Uglux has joined #bitcoin-wizards
<sipa>
and they're using logspace merkle proofs!
<sipa>
kanzure: that's fair... you can argue about systems for coordinating commitments into one, or not
<sipa>
kanzure: but that discussion is orthogonal to having it in headers or in the existing merkle tree
<bsm117532>
But you need two log(n) proofs: one to the txn containing the OP_RETURN, and another to the data that was merkled into the OP_RETURN. I'm replacing one log(n) with O(1) which is smaller for everyone, assuming everyone needs timestamps.
<sipa>
not everyone needs everyone's timestamps
<bsm117532>
Everyone needs the root of a potential timestamp that someone might feed them a log(n) proof for. If they didn't have it, they'd have to make another query for another log(n) proof.
<sipa>
same argument: why don't we just store all transactions in the header directly? everyone needs transactions!
sipa has left #bitcoin-wizards [#bitcoin-wizards]
<bsm117532>
Hrmph. I thought that was a perfectly friendly discussion...
<kanzure>
"why don't we just store all transactions in the header directly? everyone needs transactions" well, in the sense of validity, you must transfer all the transactions with the header anyway, so...
<kanzure>
(or otherwise provide the data)
sipa has joined #bitcoin-wizards
<bsm117532>
I guess his argument would be that not everyone needs *all* timestamp roots. They just need the ones they're interested in. So k*log(n) if they're interested in k of them, as opposed to height*O(1).
<sipa>
say there is a need for A transactions in every block, and B timestamps in every block
<sipa>
by combining them into one tree, you have O(blocks) cost for everyone, plus O(log(A+B)) per party interested in a commitment
<sipa>
by building two separate trees, you have O(2*blocks) cost for everyone, plus O(log(B)) per party interested in a commitment
<sipa>
by cascading the trees, you have O(blocks) cost for everyone, plus O(log(A)+log(B)) per party interested in a commitment
<bsm117532>
Well...we do need commitments to many things. These could be collapsed for light clients so that the header was only a nonce+(commitment hash) where they can retrieve the contents of the commitment hash if they're interested in txns, or timestamps in that block. But, this still a O(n) algorithm for light clients when we need to be moving to a O(log(n)) algorithm for light clients.
<sipa>
i agree there may be many things to commit to
<sipa>
but my view is that the only important classification is whether it's data needed for full validation or not
<sipa>
as every full node will always need a fully expanded tree for those things, so they should be prioritized
<sipa>
i really don't think any lightweight client cares whether they need 500 bytes for a commitment proof or 1000 bytes for a commitment proof
<sipa>
when they already need 30 MB worth of headers
<bsm117532>
But, all data is needed for full validation, no?
<sipa>
your timestamps are not
<sipa>
bitcoin transactions are
<sipa>
the witness root is
<sipa>
merged mining commitments are not
<sipa>
a fee sumtree may be
<sipa>
a utxo tree commitment may be
<sipa>
to be clear: of course you need whatever entry is the commitment data for full validation, or the headers would not be verifiable against the tree
<sipa>
but a full node does not need to know what your timestamps commits to
<bsm117532>
Well there is proofs-of-proofs-of-work and amiller's improvements, which could bring light clients to log(height) complexity.
<sipa>
it does need to know the transactions that the merkle tree commitment too
<sipa>
that's true... but still
<sipa>
do you really care that a timestamp proof is 500 bytes large?
<sipa>
*larger
<bsm117532>
So then sipa, let's say there were a bunch of new commitments: TXO, UTXO, STXO, timetamp Merkle, etc. Where would you put them all?
NewLiberty has joined #bitcoin-wizards
<bsm117532>
sipa: Not really.
<bsm117532>
especially since it's off-chain data.
Uglux has quit [Quit: Leaving]
<sipa>
if i could hardfork bitcoin, i'd put them directly under the merkle root
<sipa>
bsm117532: exactly
<sipa>
so just coordinate with a number of parties, and put them in an op_return or a coinbase output
<bsm117532>
The big difference is that a timestamp Merkle root has no consensus meaning. Some of those other commitments could...
<sipa>
i'd say there should be a top merkle tree, whose leaves are TxRoot, WitnessRoot, UTXOCommitment, TimeStampMerkle, ...
<sipa>
in fact, s/TimeStampMerkle/EverythingNotConsensusCritical/
CheckDavid has joined #bitcoin-wizards
<bsm117532>
However it would be nice if there was a somewhat organized way to put EverythingNotConsensusCritical in without (a) competition for block space or (b) ad-hoc mechanisms like OP_RETURN
<sipa>
i think that's purely psychological
<bsm117532>
It certainly is.
<bsm117532>
It's "code smell".
<sipa>
we could just as easily agree to just have a single OP_RETURN for everything as having dedicates place for it in the header/tree structure
<bsm117532>
That would be equivalent, if slightly ad-hoc.
<sipa>
i also think in practice, these things don't really matter
<sipa>
proof costs are easily dominated by the size of the tx tree branch now
<sipa>
maybe at some point in the future that changes
grubles has quit [Quit: Leaving]
<bsm117532>
I guess a calendar server could take BTC payments for adding timestamp data too...Letting the miner extract that fee adds a pretty big transaction burden that could be relayed over e.g. Lightning instead.
<bsm117532>
Though the calendar server could easily take your fee and omit your timestamp. :-/
<sipa>
if the calendar server is a miner, it could provide a frequent stream of weak PoW that contains your timestamp committed to
<bsm117532>
That's an interesting idea...
<sipa>
while that's still cheatable, it would mean the miner needs to waste money in order to provide those proofs
<sipa>
unfortunately, it pretty much only works when miners have known identities
<sipa>
and aren't too spread out
<bsm117532>
sipa: The miner wouldn't have to waste money...he could just show you a block header (containing your timestamp) + merkle proof with weak PoW. He could later omit your timestamp, but you know he did actively mine a root hash containing your timestamp. This doesn't cost the miner anything but bandwidth...
<sipa>
bsm117532: i mean, if a miner would intentionally want to not produce a block that contains your proof
<sipa>
it costs him nothing to include it
<bsm117532>
Ah yes I see.
<sipa>
but if he needs to produce PoW with it, but not actually produce a block, he's wasting money
<bsm117532>
It's merge mined though...it's his usual mining process, just with insufficient PoW to be an actual block. That doesn't cost anything.
laurentmt has joined #bitcoin-wizards
<sipa>
he doesn't know ahead of time that the hash will be insufficiently low
<sipa>
the only strategy that leads to him creating weak pow that includes your timestamp, but does not lead to full PoW that does include it, is by dropping full PoW satsfiying hashes on the floor
<sipa>
that costs money
<bsm117532>
I mean, if the miner sets his target at 600*target (as you'd do with pool mining), he can produce a weak-PoW proof that contains different timestamp data every second.
<sipa>
that's why you should demand a constant stream of PoW
<sipa>
not just once
<bsm117532>
I think you need a *not* in that sentence 5 lines up
<sipa>
which sentence?
<bsm117532>
err...
grubles has joined #bitcoin-wizards
<bsm117532>
nevermind
<bsm117532>
Parse error
<bsm117532>
Yes, correct, I agree.
<bsm117532>
One could go a step further and aggregate these weak PoW hashes to get better time resolution if desired...
JayDugger has joined #bitcoin-wizards
<bsm117532>
petertodd: Do I have a correct understanding of your calendar servers? They aggregate once per second and provide proofs. But there's nothing stopping them from dropping your timestamp later, no? What do you think of this idea of combining it with (weak-) mining?
<gmaxwell>
the mining doesn't provide any evidence that the timpstamp won't be dropped either, and because it won't end up in the history it is cheaply forged.
<bsm117532>
gmaxwell: For that one would need a proof that the stream of weak-PoW headers were strictly append-only. In principle this could be done by keeping the entire stream and committing to that in the block too. (Hey commitments to commitments! It's turtles all the way down.)
<bsm117532>
Yeah it would have to be a DAG/braid to get timestamps that fast...not sure how.
Davasny_ has joined #bitcoin-wizards
Burrito has joined #bitcoin-wizards
abpa has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
laurentmt has joined #bitcoin-wizards
BashCo_ has quit [Remote host closed the connection]
bildramer1 has joined #bitcoin-wizards
bildramer has quit [Ping timeout: 258 seconds]
BashCo has joined #bitcoin-wizards
s4z has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
Fibonacci is now known as FibonacciCoin
AnHry has joined #bitcoin-wizards
s4z has quit [Remote host closed the connection]
FibonacciCoin is now known as Fibonacci
<sn0wmonster>
Q: i have been doing some work in bitmessage lately, a system that uses the "send-everything-to-everyone" information theoretic privacy model, and uses PoW to fight spam (e.g. hashcash),
<sn0wmonster>
is it doomed to end up like bitcoin that only GPUs can use it?
<sn0wmonster>
(by "use" i mean "hash", sorry)
<sipa>
PoW only works when you can accurately measure the cost of it
<sipa>
bitcoin can do this by incentiving PoW, and having a blockchain which brings all PoW into scooe for everyone
<sipa>
i don't see how bitmessage can do it
<sipa>
except by manually adjusting the amount of PoW needed from time to time
AlineGomes has joined #bitcoin-wizards
<sn0wmonster>
i think that's how it is done at the moment, a custom multiplier in the options
<sn0wmonster>
so that means that if spammers spend $100 to send enough spam on the network to the point others need to up their PoW, it could theoretically get to a point that individual users would need to spend $100 just to have their messages sent in other words?
<c0rw1n_>
wouldn't it mean that all users collectively would have to spend $100? ( i might be being an idiot )
Guyver2 has joined #bitcoin-wizards
s4z has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
chjj has quit [Ping timeout: 240 seconds]
Noldorin has joined #bitcoin-wizards
<sn0wmonster>
you might be right
<sn0wmonster>
actually no wait, because the PoW for one person sending their own message would be what matters
<sn0wmonster>
since PoW is not required to read it
laurentmt has quit [Quit: laurentmt]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
isle2983 has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
isle2983 has quit [Quit: Leaving]
dnaleor has quit [Ping timeout: 240 seconds]
s4z has quit [Remote host closed the connection]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
isle2983 has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
chjj has quit [Ping timeout: 248 seconds]
s4z has joined #bitcoin-wizards
isle2983 has quit [Ping timeout: 260 seconds]
blackwraith has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
s4z has quit [Remote host closed the connection]
isle2983 has joined #bitcoin-wizards
uiuc-slack2 has joined #bitcoin-wizards
uiuc-slack has quit [Write error: Broken pipe]
sausage_factory has joined #bitcoin-wizards
blackwraith has quit [Ping timeout: 240 seconds]
isle2983 has quit [Ping timeout: 240 seconds]
wasi has quit [Remote host closed the connection]
wasi has joined #bitcoin-wizards
isle2983 has joined #bitcoin-wizards
blackwraith has joined #bitcoin-wizards
sausage_factory has quit [Ping timeout: 255 seconds]
dnaleor is now known as everyone_
everyone_ is now known as dnaleor
chjj has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
paveljanik has quit [Changing host]
Chris_Stewart_5 has quit [Ping timeout: 255 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
celsosouza has joined #bitcoin-wizards
mmeijeri has joined #bitcoin-wizards
<mmeijeri>
@bluematt: is the 496 on line 136 a typo for 4096?
<BlueMatt>
8*496*1024
<BlueMatt>
4063232
<BlueMatt>
looks like i just divided out 4MB
<BlueMatt>
so, no, dont think so
<BlueMatt>
(technically I belive it needs doubling for segwit, though)
<BlueMatt>
ofc with segwit its more complicated because to meet that you'd have to have all txn be FEC_CHUNK_SIZE / 2 + 1 in size, roughly
<BlueMatt>
and so you'd not really quite get 8MB max
<BlueMatt>
but...whatever
<BlueMatt>
speaking of which...if someone is bored, optimal (and fast) packing of transactions into fec chunks is an interesting problem
<BlueMatt>
current algorithm roughly juts plops transactions into place starting on chunk boundaries and fills any remaining space in the last chunk of said tx with any transactions which would not cross a chunk boundary
<BlueMatt>
but there are more clever things to do to try to optimize to not create too much empty space, while still avoiding a transaction being missed from causing the fec to need to recover any more chunks than neccessary
<BlueMatt>
the current one seems to work reasonably, but if someone finds themselves bored on a rainy sunday afternoon......
<mmeijeri>
ok, good
<mmeijeri>
I've been reading the code today and I wondered why you have four nested loops looping over node x chunk x node x chunk
<yoleaux>
Hash preimages, ZKCPs, atomic swaps and HTLC's : Mailing list archive : mimblewimble team in Launchpad
handlex has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
handlex has joined #bitcoin-wizards
<bsm117532>
"Hash-locktimed transactions" is an implementation of 2-party fair exchange, using timelocks, FWIW.
<bsm117532>
2-party fair exchange is a very fundamental and important primitive. The original Bitcoin only solved the problem of 1-way sends (resolving double-spends). The only way I know of to atomically swap data is using timelocks like this. (Unfortunately, I'd love to find another way)
GoldenAngle has joined #bitcoin-wizards
<GoldenAngle>
It's fibonacci but I'm just here to listen.
handlex has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Davasny_ is now known as Davasny
jannes has quit [Quit: Leaving]
hashtag has joined #bitcoin-wizards
hashtag_ has quit [Ping timeout: 248 seconds]
<BlueMatt>
mmeijeri: i recall there being some reason for it
<BlueMatt>
(re: the vector<bool> vs handcoded bitvector)
<BlueMatt>
oh, probably didnt want to have the indirection of dynamically allocated memory there
<BlueMatt>
which can be shit for performance
<BlueMatt>
or, at least, annoying
<BlueMatt>
there are sprinkles of random super-optimization and sprinkles of "wow, this could be made faster" all over the place ;P
Davasny has quit [Remote host closed the connection]
<BlueMatt>
mmeijeri: where is said loop?
<BlueMatt>
I've never done an actual audit of O-complexity of the fire codebase, so there may be dragons hiding
<BlueMatt>
but I hope they're all in places where its not perf-critical
<BlueMatt>
well, that and you normally only have like 5 or 10 peers
<mmeijeri>
C++ had std::bitset for fixed size bit vectors
<BlueMatt>
oh, thats nice, didnt know that
<mmeijeri>
I looked it up yesterday, I thought there had to be a std solution for it
<BlueMatt>
PR's accepted :p
Fibonacci has joined #bitcoin-wizards
<mmeijeri>
lol
<BlueMatt>
what i really need to do is fix my stats script to handle the fact that my hk <-> eu link is broken
<BlueMatt>
so i can generate the stats pages again
aalex has quit [Ping timeout: 252 seconds]
pinheadmz has joined #bitcoin-wizards
dnaleor has quit [Quit: Leaving]
pinheadmz has quit [Client Quit]
handlex has joined #bitcoin-wizards
dnaleor has joined #bitcoin-wizards
q4 has quit [Ping timeout: 245 seconds]
JHistone has quit [Ping timeout: 256 seconds]
Guyver2 has quit [Remote host closed the connection]