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
belcher has quit [Quit: Leaving]
onabreak has quit [Quit: Page closed]
onabreak has joined #bitcoin-wizards
thrmo has quit [Ping timeout: 240 seconds]
CryptAxe has left #bitcoin-wizards [#bitcoin-wizards]
rusty has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
AaronvanW has quit [Remote host closed the connection]
arubi has quit [Ping timeout: 248 seconds]
pro has quit [Quit: Leaving]
Aranjedeath has quit [Quit: Three sheets to the wind]
superkuh has quit [Quit: back tomorrow.]
tromp_ has quit [Quit: Konversation terminated!]
skeuomorf has joined #bitcoin-wizards
rusty has quit [Ping timeout: 240 seconds]
bedeho has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
Giszmo has quit [Quit: Leaving.]
moa has joined #bitcoin-wizards
moa has quit [Changing host]
moa has joined #bitcoin-wizards
legogris has quit [Remote host closed the connection]
legogris has joined #bitcoin-wizards
DrNo has quit [Ping timeout: 240 seconds]
DrNo has joined #bitcoin-wizards
_whitelogger has joined #bitcoin-wizards
nullfxn has joined #bitcoin-wizards
UnrealLife has joined #bitcoin-wizards
UnrealLife has quit [Client Quit]
TheSeven has quit [Ping timeout: 255 seconds]
[7] has joined #bitcoin-wizards
bedeho has quit []
rusty has quit [Ping timeout: 240 seconds]
arubi has joined #bitcoin-wizards
bedeho has joined #bitcoin-wizards
d9b4bef9 has quit [Remote host closed the connection]
fletom has quit [Remote host closed the connection]
fletom has joined #bitcoin-wizards
moa has quit [Quit: Leaving.]
deusexbeer has joined #bitcoin-wizards
Dyaheon- has quit [Ping timeout: 240 seconds]
Dyaheon has joined #bitcoin-wizards
jannes has joined #bitcoin-wizards
aib has quit [Ping timeout: 240 seconds]
d9b4bef9 has quit [Remote host closed the connection]
d9b4bef9 has joined #bitcoin-wizards
molz_ has quit [Read error: Connection reset by peer]
moli_ has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
rusty has joined #bitcoin-wizards
JackH has quit [Ping timeout: 260 seconds]
Antitrust has joined #bitcoin-wizards
<stevenroose>
I'm amazed actually about the amount of blocks mined by unknown miners/pools. Sadly, 99% of those blocks seem to signal nothing.
<Raccoon>
CPU/GPU mining capabilities should have never been removed from clients, even if the odds are astronomically slim.
<stevenroose>
Raccoon, well, I think it kinda makes sense to have separate mining software than client software
<stevenroose>
The majority of the users wont be mining anyway
<Raccoon>
You can't impress upon users the idea of decentralization if it's not even made available -- banned -- due to impracticality.
<Raccoon>
That tells users that the experiment is failed.
<stevenroose>
I do agree that there should be more user-friendly mining software
<stevenroose>
like you owuld have guiminer in the past
<Raccoon>
Or, you know, impliment a common core mining software that hardware miners adhere to, API.
<Raccoon>
Then people can buy compatable USB plug-n-go hardware miners that the bitcoin software autodetects
<Raccoon>
but
<Raccoon>
in the absense of any decentralized and standardized mining software, all we are left is with capitalism driven pool miners
<Raccoon>
people who make money by making mining possible
<Raccoon>
closed source
<Raccoon>
If you want to get involved with bitcoin mining, you have to go through either Chase or Bank of America
<Raccoon>
or find some old source code and roll your own
skeuomorf has quit [Ping timeout: 260 seconds]
Antitrust has quit [Remote host closed the connection]
<Eliel_>
Raccoon: that sort of API exists, actually. However, my impression is that not many miners use it.
<stevenroose>
Well, it used to work like that
<stevenroose>
BFGMiner or the other one that it was a fork of, they used to detect almost all hardware miners
<stevenroose>
I don't know now, I'm speaking years ago
<Raccoon>
If it were built into the in-your-face client wallet(s), people might give it more credence.
<stevenroose>
I do agree that mining software and hardware should be way more accessible, but I don't agree it should be shipped by default with all clients
<stevenroose>
I's like shipping a pickaxe with a golden ring :D
<Raccoon>
I don't see why not. The ethos of Bitcoin is that all users are also gate keepers.
<Raccoon>
Or at least are encouraged to become one.
<Raccoon>
And yes, your analogy fits.
<Raccoon>
As it should.
<Raccoon>
Not only are you opening up a checking account, but you own the whole fucking bank.
<Raccoon>
Here's your banker's hat and vault and ledger and everything else you need
<Raccoon>
"Some hardware upgrades may be required. Click here for some sites selling mining hardware."
mountaingoat has quit [Ping timeout: 246 seconds]
<Raccoon>
Imagine the non-pool participation if it were that easy
<Raccoon>
Alas, Chase Inc. may actually buy up one of the mining pools
<Raccoon>
And that's that
rusty has quit [Ping timeout: 240 seconds]
harrymm has quit [Read error: Connection reset by peer]
AaronvanW has joined #bitcoin-wizards
mountaingoat has joined #bitcoin-wizards
<adlai>
mining is not banking, though. running a node is banking. mining is being a rate limiter on the interbank messaging.
skeuomorf has joined #bitcoin-wizards
<adlai>
you can be a bank that doesn't operate its own interbank messaging relay, but you then need to rely on at least one such relay
Guyver2 has joined #bitcoin-wizards
mountaingoat has quit [Ping timeout: 268 seconds]
mountaingoat has joined #bitcoin-wizards
pro has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
PaulCapestany has quit [Quit: .]
PaulCapestany has joined #bitcoin-wizards
str4d has quit [Ping timeout: 272 seconds]
JackH has joined #bitcoin-wizards
skeuomorf has quit [Ping timeout: 255 seconds]
bedeho has quit [Remote host closed the connection]
bedeho has joined #bitcoin-wizards
<bsm1175321>
I want open source mining hardware...
bedeho has quit [Ping timeout: 260 seconds]
MaxSan has joined #bitcoin-wizards
bedeho has joined #bitcoin-wizards
bedeho has quit [Remote host closed the connection]
bedeho has joined #bitcoin-wizards
bedeho has quit [Remote host closed the connection]
bedeho has joined #bitcoin-wizards
bedeho has quit [Remote host closed the connection]
<stevenroose>
bsm1175321, I think a crowdfunder for one would work great :p
bedeho has joined #bitcoin-wizards
bedeho has quit [Remote host closed the connection]
laurentmt has joined #bitcoin-wizards
MaxSan has quit [Ping timeout: 246 seconds]
kmels has joined #bitcoin-wizards
paveljanik has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
laurentmt has quit [Quit: laurentmt]
laurentmt has joined #bitcoin-wizards
<bsm117532>
stevenroose: would have to find some real VHDL and fab experts, to figure out how to make such a thing worthwhile.
<bsm117532>
Every time I bring this up, the consensus seems to be that fabs are so finicky and custom that all the development time is in tweaking your design for a specific fab, and the value of the open-source VHDL would be near-zero.
<stevenroose>
I guess if one of the already existing mining firms would do a crowdfunder for an open source model, they would make profits. the only problem is that I think currently mining is still a bit too profitable for them to do that over just mining themselves
<stevenroose>
I think when the bounty decreases, mining will automatically become less profitable and more decentralized since mining hardware manufacturers will make more profits selling their hardware than to mine themselves
c0rw1n has quit [Ping timeout: 260 seconds]
<stevenroose>
but then again, once mining manufacturers are more incentivized to sell, I doubt if there is a lot of real value in open source hardware
laurentmt has quit [Quit: laurentmt]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
superkuh has joined #bitcoin-wizards
<Eliel_>
stevenroose: I don't think mining hardware maker profits are really dependent on the bounty. They can set the price to whatever level they think they'd get if they mined themselves.
<Eliel_>
of course, if competitors sell cheaper, then they'll naturally end up mining themselves.
<Taek>
Not too hard to track down I think. I was recently quoted $11M in fixed costs to produce a 14nm miner. The recent Bitmain I think is only 16nm. So if you can crowdfund $100M or so, you can probably print a pretty good ASIC
<Taek>
Though, I'm not actually sure if that firm would be comfortable open sourcing the resulting designs
<Taek>
considering that the annual block reward is in the ballpark of $1B, I think there's a great business case to go for it
<Taek>
you'd need to see how much hashrate you could get for $100M though
c0rw1n has joined #bitcoin-wizards
GreenF has joined #bitcoin-wizards
Guest98 has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
Conficker has quit [Ping timeout: 240 seconds]
MaxSan has joined #bitcoin-wizards
thrmo has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
Giszmo has joined #bitcoin-wizards
<bsm117532>
A crowdfunded entity with a contractual commitment to NOT mine, only develop and sell mining hardware...and open source all designs...
tromp_ has joined #bitcoin-wizards
<bsm117532>
How could crowd-funders ensure non-discrimination in creation of mining hardware?
<bsm117532>
There's an awful strong incentive to collude with miners and mining pools...
<kanzure>
someone was arguing to me the other day that we should find a matrix math heavy pow function, and then abuse the machine learning asic industry or something (i think the assumption was that matrix math asic limits have been met by nvidia by now or something?)
<othe>
well, thats an issue for the legal system then
<bsm117532>
othe: One would want a carefully written charter/contract for an open source mining company, so that the legal system was capable of enforcing terms in a way which help said entity decentralize mining...and prevent it from doing the opposite.
<bsm117532>
kanzure: new nvidia chips contain dedicated "tensor" engines, which could be abused for mining.
<kanzure>
yea but i think purpose-specific asic manufacturing would probably outperform that.. just a hunch.
talmai has joined #bitcoin-wizards
<bsm117532>
Well sure. I'm sure one could optimize a compute-heavy mining algorithm to make any given GPU essentially ideal. If I imagine memory consumption, computations per memory access, bandwidth, etc are independently tunable knobs within the mining function.
<bsm117532>
At that point a purpose-specific ASIC would have a very hard time competing with the general purpose GPU...
<Taek>
then you've gone and optimized your algorithm around a single chip. Hardware is still getting better, and you've basically locked in a single hardware implementation as the winner
<Taek>
if that implementation is owned by nvidia, then you've made nvidia the new bitmain
<bsm117532>
Yeah I'm not saying this is a good idea...
<kanzure>
re: memory-hard functions, i thought there was a concern that DRAM manufacturers are even less decentralized than <90nm asic manufacturers?
<Taek>
indeed
kmels has quit [Ping timeout: 240 seconds]
<bsm117532>
Well, in as much as fabs have kind-of become a shared resource...the bitcoin mining industry just uses them like anyone else.
<Taek>
seems that currently the bottleneck is a really high fixed cost for making ASIC masks. My hunch then is that you could make a new PoW algorithm that optimizes around reducing the cost of making masks
<kanzure>
there are maskless asic manufacturing techniques but i dunno if they are compatible with the 16nm stuff. for example, micromirror arrays or liquid crystal displays as masks.
<Taek>
I don't know what all goes into masks, but I'd guess that a lot of it deals with catering specifically to the algo you want to implement
<kanzure>
my backgroud w/ maskless manufacturing stuff is mostly re: microfluidics, i was speccing out a microfluidic fabrication tool and i hated the idea of masks so i wanted to use a standard household micromirror array projector etc.
<luke-jr>
Raccoon: BFGMiner still supports CPU/GPU
talmai has quit [Ping timeout: 240 seconds]
chjj has quit [Ping timeout: 246 seconds]
bedeho has joined #bitcoin-wizards
dbarrett has joined #bitcoin-wizards
talmai has joined #bitcoin-wizards
abpa has joined #bitcoin-wizards
kmels has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
talmai has quit [Ping timeout: 240 seconds]
Giszmo has quit [Quit: Leaving.]
MaxSan has quit [Ping timeout: 240 seconds]
<phantomcircuit>
kanzure, newer processes absolutely require a mask
laurentmt has quit [Quit: laurentmt]
harrymm has joined #bitcoin-wizards
<phantomcircuit>
bsm117532, the issue is who owns the mask
Giszmo has joined #bitcoin-wizards
<bsm117532>
The mask is a physical mask?
<bsm117532>
Perhaps the actual charter of an open-source hardware organization would be to create copies of the mask for distribution. Is that feasible?
bedeho has quit [Remote host closed the connection]
iddo_ is now known as iddo
iddo has joined #bitcoin-wizards
iddo has quit [Changing host]
CubicEarth has joined #bitcoin-wizards
BashCo has quit [Ping timeout: 240 seconds]
bedeho has joined #bitcoin-wizards
CubicEarth has quit [Ping timeout: 246 seconds]
bedeho has quit [Remote host closed the connection]
bedeho has quit [Remote host closed the connection]
JackH has quit [Ping timeout: 240 seconds]
Chris_Stewart_5 has quit [Ping timeout: 268 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
MaxSan has quit [Ping timeout: 240 seconds]
bedeho has joined #bitcoin-wizards
MaxSan has joined #bitcoin-wizards
<Taek>
masks don't translate well between fabs, every time you switch to a new fab you're going to need a new set of masks, more or less
<Taek>
also, at least the guys I'm talking to didn't seem interested in open-sourcing the hardware designs. They said they have some proprietary optimizations they do on the chips
<bsm117532>
All the more reason to find a way to do it...
Ylbam has joined #bitcoin-wizards
MaxSan has quit [Ping timeout: 240 seconds]
GreenF has quit [Ping timeout: 246 seconds]
bedeho has quit [Remote host closed the connection]
laurentmt has joined #bitcoin-wizards
bedeho has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
uiuc-slack has quit [Read error: Connection reset by peer]
uiuc-slack has joined #bitcoin-wizards
dermoth has joined #bitcoin-wizards
mol has joined #bitcoin-wizards
moli_ has quit [Ping timeout: 240 seconds]
<dermoth>
Hey there... moving a discussion from the dev channel; I was thinking about the issue of block size vs. propagation time...
<dermoth>
What if the block header included a bloom filter on tx inputs (or rather hash + params), so miners could at least include any transactions that the bloom filter tells for sure cannot be double spends from the accompanying block header.
<dermoth>
in a few additional kb's the miners could include many transactions that are save until they can actually download the rest of the block data and validate it.
kristofferR has joined #bitcoin-wizards
<dermoth>
gmaxwell, let'S continue the topic here.... you mentioned a proposal... was it a BIP, mailing list thread, etc...?
<gmaxwell>
dermoth: About a year ago someone proposed this on bitcoin-dev mailing list (or bct? I forget) creating a bloom filter of the txins spent by a block so that miners could do even more mining without validating and not miss out on collecting (most of the) fees.
nullfxn has quit [Quit: leaving]
bedeho has quit [Remote host closed the connection]
<gmaxwell>
But it runs into the issue that validationless mining is really super toxic to lite client security (thus scalability)-- so increasing the amounts of it is not a public good, and if miners just want to optimize their income they just centeralize further-- which is simpler and safer than these approaches.
<gmaxwell>
Plus fibre (and a lesser extent BIP152) and what not already transfer the actual block with minimal information.
<gmaxwell>
I'm looking for the thread.
bedeho has joined #bitcoin-wizards
<dermoth>
Shouldn'T miner centralisation be considered toxic too? and I'd like to understand the arguments about SPV client as what I'm proposing is merely to solve the 0tx-block issue... I'm not proposing to replace any of the existing validation in place
<dermoth>
thanks for looking
<gmaxwell>
AJ towns was the author btw.
<gmaxwell>
of what I'm referring to, still looking for it but I know the author now.
<gmaxwell>
:P
<gmaxwell>
dermoth: from a security perspective prolonged validationless mining and pool style centeralization are very close to the same thing.
<gmaxwell>
In both cases, users get a chain that has only been validated by one party, even when it has multiple blocks.
<gmaxwell>
FWIW from a private email I sent to stephen pair:
<gmaxwell>
--
<gmaxwell>
AJ towns previously proposed miners commit to a tiny bloom filter for
<gmaxwell>
of includable transactions, with small enough space that it could
<gmaxwell>
the input ID they already included, this allows near instant checking
<gmaxwell>
still fit in a single IP packet. Even without any commitment, miners
<gmaxwell>
could simply send this filter: today all (or virtually all) SPV mining
<gmaxwell>
is done between known and at least semi-trusted parties; so a
<gmaxwell>
bilateral agreement to exchange such masks would likely fit their
<gmaxwell>
business needs even if it isn't useful for network security.
<gmaxwell>
--
<gmaxwell>
so now to find the message from AJ.
bedeho has quit [Ping timeout: 255 seconds]
<gmaxwell>
I found the post, but now I need fo figure out how to link to it.
<dermoth>
thanks... gmane?
<dermoth>
just give me the mailing list /subject
<gmaxwell>
doesn't appear to be in list archives. And the most interesting part of the discussion was actually in private message between him and I, lemme find out if he has any issue with sharing it with you.
<gmaxwell>
(where I point out that the filters would actually be bigger than FBRP block messages)
<dermoth>
how big?
<dermoth>
approx
rusty has joined #bitcoin-wizards
<gmaxwell>
he computed 7168 bytes for current (at the time) blocksizes.
<dermoth>
that'S way too much
<gmaxwell>
he gave figures for it, I believe.
<gmaxwell>
keep in mind that there are several times more inputs than transactions in a block.
<dermoth>
I'm not an expert, but using what seems to be a very trustable bloom filter calculator 30 tx with only 1% false positive takes only 3.51kb
<dermoth>
oh right
<gmaxwell>
30 tx? a typical block has about 5000 inputs.
<dermoth>
let's go with 30k, 10%, 17.55k
<dermoth>
oops I meant 3k tx
<dermoth>
for the rearlier sentense!
<gmaxwell>
dermoth: right thats larger than a FBRP block, (two bytes per transaction).
<dermoth>
3k, 1% 3.51kb. 30k, 10%, 17.55kb
<gmaxwell>
or right at the size.
<bsm117532>
FWIW since bloom filters provide effectively no privacy protection (as hoped when BIP37 was written), it's much simpler to use Cuckoo filters, and they're much easier to reason about. Just consider a filter that contains the first N bits of the txid (or keyhash, or whatever).
smk has joined #bitcoin-wizards
<sipa>
bsm117532: we're not talking about BIP37
<dermoth>
I'm wondering how both scale... argualibaly you can allow much larger number of false positives
<sipa>
privacy for block transmission is not an issue
<gmaxwell>
3k inputs means maybe 1500 transactions, which would take 3000 bytes in the FBRP.
<bsm117532>
sipa: yes so why use bloom filters? You can dump the extra parameter (number of hash functions) and just transmit the first N bits of each object instead. Faster and simpler.
<dermoth>
bsm117532, but if any tx isn't in your mempool you need to retrieve it
<gmaxwell>
bsm117532: that is not what a cuckoo filter is, FWIW. (I mean it's one step, but in a cuckoo filter additional hash data constraints what slots a item can be in)
<sipa>
bsm117532: that's effectively what BIP152 does (send the first 48 bits of a salted hash of the txids)
<sipa>
but in doing so, it transfers the whole blocks
<gmaxwell>
which doesn't support dermoth's dubious goal of making it possible to mine without validation more. :)
<sipa>
not just its spent inputs
<dermoth>
lol
<gmaxwell>
dermoth: FWIW, in both FBRP and fibre there is no "you need to retrieve it".
<bsm117532>
It's been a while since I read the Cuckoo paper.... But this idea of "just transmit the first N bits" works as long as the underlying object is uniformly distributed (e.g. a txid).
<gmaxwell>
in FBRP the sending side always knows a minimum set of tx that you already have (which get mapped to two byte IDs) and then sends any additional ones explicitly. And fibre uses an erasure code to send correction data that lets you recover the missing transactions without the sender knowing what you're missing.
<dermoth>
I'll need to sit down and read the BIP... my thought is if you have the first bits of the tx hash how can you tell a tx you're including in the next block isn't a double spend?
<gmaxwell>
bsm117532: yes but the performance is only competative/better bloom with the positional constraint. The position contains additional information about the match.
<gmaxwell>
dermoth: BIP152? you don't as I said, it doesn't satisify your goal. But bsm117532 points your goal would be better satisified by a cuckoo filter (which is true, though he mangles the description of a cuckoo filter a bit).
<gmaxwell>
And what I was pointing out that FBRP and Fibre (which do the vast majority of the block-miles transport) don't have the "but you have to get more data" problem.
<bsm117532>
... "but does not support any compact proofs of existence or non-existence" :-( :-( :-(
<sipa>
bsm117532: read on
<sipa>
it's also not incompatible with it
<gmaxwell>
Big problem with all the prior utxo like commitments is that there is no clear leader yet (making radically different tradeoffs), and they are very incompatible with each other.
rusty has quit [Ping timeout: 258 seconds]
<gmaxwell>
and are all, except perhaps bramc's txo bitfield, pretty IO costly too. So this is compatible with all of them, has no IO cost, and at least lets you do the things that don't need compact (non)membership proofs.
<bsm117532>
sipa: very interesting.
katu_ has quit [Ping timeout: 245 seconds]
<bsm117532>
sipa: how could you build on this to enable (non-)membership proofs?
<gmaxwell>
You can't.
<gmaxwell>
but you can run a thing that can do them along side it.
<gmaxwell>
Without any gratitious cost.
<gmaxwell>
Which you cannot do with any of the compact proof compatible things, they all have significant IO costs.
<bsm117532>
gmaxwell: But wouldn't that "thing" incur all the negatives you mention above?
<sipa>
bsm117532: no
<sipa>
the problem is that for example a UTXO commitment structure may require future full nodes to always maintain a UTXO set
<sipa>
or may remove that need for some use cases, but not all
<sipa>
or may eliminate it entirely, but only by choosing a large bandwidth increase for transactions
<sipa>
the problem is that it's not clear which of those choices we'll want to make
<sipa>
and they are incompatible with eachother
<sipa>
this rolling UTXO set hash is compatible with all of them
<gmaxwell>
(sipa is walking down lists of the actual implications of existing proposals)
chjj has quit [Ping timeout: 240 seconds]
<sipa>
because interestingly, it does not actually require to keep a UTXO set... all you need to do is see blocks (to know what to add), and what outputs are being spent (which you already need to do in order to validate)
katu has joined #bitcoin-wizards
mol has quit [Ping timeout: 246 seconds]
<bsm117532>
Doesn't the associativity of the update operation make it very easy to compute an alternative history having the same hash value?
<sipa>
if you do it naively, yes
<sipa>
read the mail, it addresses that
afk11 has quit [Remote host closed the connection]
<bsm117532>
Is that what you mean with gaussian elimination?
<sipa>
that's one of the ways to attack the construction if you use XOR as combinator
<sipa>
say you use 256-bit hashes and xor them
<sipa>
generate a few hundred random outputs, compute their hashes
<sipa>
now you're trying to find a subset of them which xor to a given valeu
<gmaxwell>
bsm117532: if you just mean an 'alternative history that results in the same utxo set' well duh sure, but that is not a bug. The utxo set is the same, which is the goal. It's a hash of the set, not of its update order.
<sipa>
ah
<sipa>
well you commit to the hash of the tip block as well
<bsm117532>
No I meant alternative history with the same *hash* but different utxo set.
<sipa>
bsm117532: that's not possible if you use one of the provably safe constructions
<sipa>
Wagner's paper shows that that problem is at least as hard as computing the discrete logarithm
<bsm117532>
Very interesting...I discarded some related ideas a while ago for all the reasons you suggest re: insecure XOR combinator...
<sipa>
yup, me too
<sipa>
i had come up with the XOR construction myself, later discovered it was insecure, and then discarded the whole idea of order-independent hashes
<gmaxwell>
it's a fairly simple proof. If you try to add members of a DL hard group to match a fixed group where the members are generated by a random oracle, and you have a blackbox solver that can take a stream of random members and find a set that adds up to the target, then you replace your random oracle with a box that takes random numbers times G and outputs them. Then you use your blackbost k-sum
<gmaxwell>
solver to find the discrete log.
<bsm117532>
I was looking for ways to combine proofs of work.
<bsm117532>
Which, if you could do, could allow you to improve mining decentralization.
<gmaxwell>
s/blackbost/blackbox/
<bsm117532>
(e.g. sub-block or tx level mining -- and a mechanism to aggregate it into a single hash)
chjj has joined #bitcoin-wizards
dnaleor_ has quit [Ping timeout: 240 seconds]
<bsm117532>
sipa: https://arxiv.org/pdf/1601.06502.pdf (Elliptic Curve Multiset Hash) seems to be the real kicker for this idea. Can you elaborate as to why you described it as "controversial"?
bedeho has joined #bitcoin-wizards
<sipa>
it uses binary curves, whose security has been less certain recently
Dyaheon has quit [Ping timeout: 240 seconds]
<sipa>
(curves with a coordinate field GF(2^n), as opposed to mod a large prime)
MaxSan has joined #bitcoin-wizards
dnaleor_ has joined #bitcoin-wizards
Dyaheon has joined #bitcoin-wizards
<bsm117532>
sipa: and all that is needed to replace that controversy is another way to map hash functions to ECC points, correct?
<sipa>
bsm117532: yup, and it seems that in all mod p curves, that's an operation that at least requires a square root operation
<sipa>
which is "hard" for mod p
<bsm117532>
So you're mapping a sha512 hash to two secp256k1 points (deterministically, I assume), and adding them?
<sipa>
no, one
<sipa>
interpret the output of your hash as an X coordinate
<sipa>
find the corresponding Y
<sipa>
if it has one, you're done
<sipa>
if it doesn't compute a new sha512 (by appending some counter to its input, or by hashing the last 32 bytes again, or ...)
<sipa>
and start over
<sipa>
50% chance you need 1 iteration
<sipa>
25% chance you need 2
<sipa>
12.5% chance you need 3
<sipa>
etc
bedeho has quit [Remote host closed the connection]
bedeho has joined #bitcoin-wizards
<bsm117532>
Aaaaah I see
smk has quit [Ping timeout: 260 seconds]
<bsm117532>
And with a 512 bit hash you've got a 2^-256 probability that the algorithm fails. Except...birthday...probably means the algorithm is guaranteed to succeed?
pro has quit [Quit: Leaving]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
JackH has joined #bitcoin-wizards
Guyver2 has quit [Remote host closed the connection]
pro has joined #bitcoin-wizards
epsi10n has joined #bitcoin-wizards
bedeho has quit [Remote host closed the connection]
<gmaxwell>
it's guarenteed to be successful, that isn't the concern.
<gmaxwell>
computing the sqrt is slow and non-batchable.
<gmaxwell>
curves over 2^n don't have that issue, you can use the half-trace to decompress points.
<gmaxwell>
but they have a much weaker security story overall.
<gmaxwell>
Authors of that paper argue that it's no big deal, but don't factor in improvements.
<gmaxwell>
that comparison also ignores the complexity.
<gmaxwell>
fast code for multiplication Fp is trivial, supporting another elliptic curve with state of the art performance not so much.
<MaxSan>
gmaxwell: if your such a dam master of bitcoin why isnt segwit activated yet eh?!/
epsi10n has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<MaxSan>
EH?!
<MaxSan>
;)
<gmaxwell>
MaxSan: uh. it's all part of my evil plan?
rusty2 has quit [Ping timeout: 240 seconds]
<MaxSan>
I knew it all along! Quoted for twitter! ;)
<MaxSan>
Not sure if anyone has heard of Radix but they be releasing their patents soon, very curious as to what they have inside them
<MaxSan>
making very bold claims..
kmels has quit [Ping timeout: 268 seconds]
<gmaxwell>
MaxSan: smelled like snakeoil a year ago, don't see why it would change because they've changed the name of it.
<sipa>
never heard of
<gmaxwell>
'eMunie' one of these "omg I just heard of 'sharding' stack overflow and it will solve all the words problems!" things.
<JackH>
Ignoring coinbase transactions (described later), if the value of a transaction’s outputs exceed its inputs, the transaction will be rejected—but if the inputs exceed the value of the outputs, any difference in value may be claimed as a transaction fee by the Bitcoin miner who creates the block containing that transaction. For example, in the illustration above, each transaction spends 10,000 satoshis fewer than
<JackH>
it receives from its combined inputs, effectively paying a 10,000 satoshi transaction fee.
<JackH>
is this not wrong?
<JackH>
should it not be that any value difference can be either miners fee or also change?
<gmaxwell>
JackH: no, change is an explicit output.
<gmaxwell>
The network itself has no concept of change, your wallet does.
<JackH>
so my wallet code does the actual change, not the rules?
<sipa>
as far as the network is concern, change is just another output
<JackH>
oh wow, I didnt know this
<sipa>
it does not know that it goes back to yourself
<MaxSan>
gmaxwell: yeah maybe. I have some faith. its the claims they are making which are a bit more bold than that..
<sipa>
if it did, privacy of transactions would be almost impossible to achieve
<JackH>
I always assumed change was part of the tx after miners fee and output
<MaxSan>
although if it sounds too good to be true, it generally is.
<MaxSan>
if you listen to their claims it falls into that category
<MaxSan>
but we wont know until its out in the open
<gmaxwell>
MaxSan: if you don't care about decenteralization then scale relative to cryptocurrency usage today is a non-issue. I think my desktop can process something like 500,000 signatures per second.
<gmaxwell>
so anything that talks about scale without also talking about security assumptions and tradeofs is pretty much automatic snake oil unless it's just simple software optimization.
<MaxSan>
absolutely. I understand the problem. Its when they put all these claims together it raises a lot of eyebrows
bedeho has joined #bitcoin-wizards
bedeho has quit [Ping timeout: 240 seconds]
mol has joined #bitcoin-wizards
flandero has joined #bitcoin-wizards
AaronvanW has quit [Remote host closed the connection]