DougieBot5000 has joined #bitcoin-wizards
<rusty> phantomcircuit: I'd like to see SPV nodes do something like "adopt-a-block" where they pick (one or more) random blocks and store and verify it, then maintain proofs of all spends of outputs in that block.
Zooko-phone has quit [Ping timeout: 256 seconds]
<maaku> rusty: how do you verify the inputs to the block though?
<maaku> i mean it's a good idea, but there's an engineering challenge there
<rusty> maaku: best effort; but I think it's kind of a ratchet as more people do this.
<gmaxwell> certantly easy to do that in pruned nodes; (though random blocks by themselves are not quite ideal as you have a discovery problem)
<gmaxwell> rusty: with the bitcoin commitment structure there is almost nothing to can verify statelessly like that, at least not without huge overhead-- can't verify signatures or fees or the coinbase output amount. :(
bbhank has quit [Quit: Page closed]
<gmaxwell> this old page https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs walks over some of that (I may have shown that to you before)
<rusty> gmaxwell: sure, but you can provide proofs if future blocks have double-spends.
<maaku> rusty: I mean, for a given input all you have is the txid hash of the input. i suppose you could build a bloom filter of all the inputs to the block and do a bloom filter "wallet" sync.
<maaku> I shudder to think what that do to full nodes resource usage though :\
<rusty> maaku: yeah, don't do that. But you'd need something like that to get txs which spend from your adopted block(s).
<maaku> wait duh bloom filters are over scriptPubKeys not txids
Zooko-phone has joined #bitcoin-wizards
<gmaxwell> rusty: well my point at that page was less the random checking and more the random verification a check, I was still assuming someone somehere ran a (pruned) full node and would notice the invalidity and then it would propagate.
cryptonaut has joined #bitcoin-wizards
MAKOHYPE is now known as bosnia
<gmaxwell> but indeed some kind of filtering could make actual fraud discovery also perhaps work.
cryptonaut is now known as Guest8949
<rusty> gmaxwell: I'm trying to push it to the extreme, where SPV nodes can fill archive and fraud proof requirements which currently require full nnodes.
<maaku> rusty: I think that's the desired end-state of pruned nodes
<rusty> gmaxwell: not sure it's possible, if most nodes won't relay txs to you they're not personally interested in though.
<rusty> maaku: yeah, and I guess the "last N blocks" is the thing you want assured in *practice*.
<maaku> so with txout commitments that's the goal -- you sync utxo state and work your way backwards N blocks
<rusty> maaku: That would be nice. adopt-a-block might still make sense for archival purposes. But as gmaxwell said, discoverability problem.
<gmaxwell> well I've suggested before that listening nodes could advertise a single short nonce and a size, and from that you can compute at any time what block range(s) they will have.
<gmaxwell> which solves discoverability.
<gmaxwell> but I was thinking that more in terms of pruned full nodes, not SPV adopt a block.
<akrmn> rusty: that's why I'm telling people subchains are good for scaling (you can constraint outputs to subchains). But still waiting for sipa's response to that.
<akrmn> Mike Hearn suggested SPV some storing random subsets of blocks but I doubt that would be reliable.
<rusty> gmaxwell: yeah, you could still hack it by relaying requests (and results) I guess. Might have to if SPV nodes are generally not listening nodes.
<akrmn> *SPV nodes
hearn has quit [Quit: Textual IRC Client: www.textualapp.com]
<rusty> maaku: BTW, I re-read my notes on SPV proof minimization. My conclusion was that it's far easier if we select a point to optimize for; I was using the genesis block but that's not actually what we want.
<rusty> maaku: it's an engineering question, really. 144 blocks ago? 1008 blocks?
<moa> pruned nodes could keep last-120 plus adopt-N-blocks
<gmaxwell> moa: bitcoin core won't even currently run without 288 of the most recent, fwiw.
<moa> oh right ... last-288
<moa> 120 is coinbase spend
Zooko-phone has quit [Ping timeout: 265 seconds]
<maaku> moa: 100
<moa> hah
<moa> is there any work done on researching UXTO distributions over block height? ... i.e. are some block 'eras' more uxto dense than others?
afk11 has quit [Ping timeout: 265 seconds]
<gmaxwell> very much so.
eudoxia has quit [Quit: Leaving]
<moa> som inherently not all blocks are 'equal' in the snese that some blocks have more value than others in terms of informational content
<moa> so not som
jgarzik has quit [Read error: Connection reset by peer]
jgarzik has joined #bitcoin-wizards
afk11 has joined #bitcoin-wizards
jgarzik has quit [Read error: Connection reset by peer]
wallet42 has quit [Quit: Leaving.]
jgarzik has joined #bitcoin-wizards
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Read error: Connection reset by peer]
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Changing host]
jgarzik has joined #bitcoin-wizards
Burrito has quit [Quit: Leaving]
jgarzik has quit [Read error: Connection reset by peer]
jgarzik has joined #bitcoin-wizards
jposner_ has quit [Remote host closed the connection]
jgarzik has quit [Read error: Connection reset by peer]
jgarzik has joined #bitcoin-wizards
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Read error: Connection reset by peer]
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Changing host]
jgarzik has joined #bitcoin-wizards
prodatalab has joined #bitcoin-wizards
DanielBTC has joined #bitcoin-wizards
DanielBTC is now known as Guest60637
afk11 has quit [Quit: Leaving.]
GAit has quit [Read error: Connection reset by peer]
Guest7319 has quit [Remote host closed the connection]
GAit has joined #bitcoin-wizards
Guest60637 is now known as DanielBTC
Guest8949 has quit [Quit: Leaving]
Adlai has joined #bitcoin-wizards
belcher has quit [Quit: Leaving]
Dr-G has quit [Read error: Connection reset by peer]
Dr-G has joined #bitcoin-wizards
Dr-G has joined #bitcoin-wizards
nessence_ has quit [Read error: Connection reset by peer]
Dr-G has quit [Disconnected by services]
Dr-G2 has joined #bitcoin-wizards
shen_noe has quit [Quit: Leaving]
SubCreative has quit [Ping timeout: 265 seconds]
SubCreative has joined #bitcoin-wizards
SubCreative has joined #bitcoin-wizards
peterlie_ has quit [Remote host closed the connection]
Sub|afk has joined #bitcoin-wizards
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
SubCreative has quit [Ping timeout: 265 seconds]
wallet42 has quit [Ping timeout: 264 seconds]
nessence_ has joined #bitcoin-wizards
nwilcox has quit [Quit: leaving]
www has joined #bitcoin-wizards
DanielBTC has quit [Quit: Leaving]
bosnia is now known as bosma
metamarc has joined #bitcoin-wizards
bosma is now known as BATTLEFRONTHYPE
BATTLEFRONTHYPE is now known as bosma
kgk has joined #bitcoin-wizards
p15 has joined #bitcoin-wizards
jae has joined #bitcoin-wizards
jae is now known as Guest83499
jgarzik has quit [Read error: Connection reset by peer]
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Read error: Connection reset by peer]
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Read error: Connection reset by peer]
jgarzik has joined #bitcoin-wizards
jgarzik has quit [Changing host]
jgarzik has joined #bitcoin-wizards
justanot1erusr has joined #bitcoin-wizards
justanotherusr has quit [Quit: Reconnecting]
shesek has quit [Read error: Connection reset by peer]
shesek has joined #bitcoin-wizards
[7] has quit [Disconnected by services]
TheSeven has joined #bitcoin-wizards
shesek has quit [Ping timeout: 244 seconds]
shesek has joined #bitcoin-wizards
goregrind has quit [Read error: Connection reset by peer]
mjerr has joined #bitcoin-wizards
goregrind has joined #bitcoin-wizards
rht__ has joined #bitcoin-wizards
Guest83499 has quit [Remote host closed the connection]
Giszmo has quit [Quit: Leaving.]
priidu has joined #bitcoin-wizards
mjerr has quit [Remote host closed the connection]
mjerr has joined #bitcoin-wizards
paveljanik has quit [Quit: Leaving]
OneFixt has joined #bitcoin-wizards
Crowley2k has joined #bitcoin-wizards
cosmo has quit [Ping timeout: 256 seconds]
_biO_ has joined #bitcoin-wizards
arubi_ has quit [Quit: Leaving]
sy5error has quit [Remote host closed the connection]
Mably has joined #bitcoin-wizards
priidu has quit [Ping timeout: 250 seconds]
priidu has joined #bitcoin-wizards
Mably has quit [Ping timeout: 252 seconds]
darwin_ has joined #bitcoin-wizards
grandmaster has joined #bitcoin-wizards
DougieBot5000 has quit [Quit: Leaving]
Mably has joined #bitcoin-wizards
hktud0 has quit [Read error: Connection reset by peer]
_biO_ has quit [Read error: Connection reset by peer]
hktud0 has joined #bitcoin-wizards
jrayhawk has quit [Ping timeout: 265 seconds]
jrayhawk has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
antanst has joined #bitcoin-wizards
antanst has left #bitcoin-wizards [#bitcoin-wizards]
CoinMuncher has joined #bitcoin-wizards
<weex> theymos: phantomcircuit do dns seeds do that sort of checking of nodes they're advertising?
AaronvanW has joined #bitcoin-wizards
<gmaxwell> weex: sipa's DNS seed (and other seeds running his software) perform some limit tests.
<weex> my other question is what does an spv node do when post-fork it ends up on the other side, rebuild from genesis block or just get all inconsistent with itself
<gmaxwell> I don't understand the question, where do you think an inconsistency is coming from?
<weex> first of all i don't know how it handles peers that are different forks
b_lumenkraft has joined #bitcoin-wizards
<weex> does it drop the minority or the ones that disagree with what it stored as its best block
<gmaxwell> SPV nodes follow the chain with the most apparent proof of work.
<gmaxwell> Number of peers is irrelevant unless you're partitioned.
<weex> most apparent being highest difficulty?
<theymos> weex: AFAIK none of the DNS seeds do any in-depth checks. I think they'd include hardforking XT nodes, for example.
<gmaxwell> weex: the most work. Not highest difficulty, if you just mean difficulty at the tip. The sum of difficulty of the blocks. Perhaps #bitcoin for basics questions. :)
<weex> heh, ok...i was just trying to figure out how the world of coffees might be affected by this proposed hard fork
justanot1erusr has quit [Ping timeout: 244 seconds]
<weex> i imagine a lot of code doesn't assume this kind of thing might happen so lots of conjecture is to be expected
JackH has joined #bitcoin-wizards
Sub|afk has quit [Ping timeout: 256 seconds]
rusty has quit [Ping timeout: 264 seconds]
<theymos> Peer discovery is something I've been thinking about for a while. I feel like Bitcoin Core should maintain more info about past peers and try to always connect to a few that seem long-term-reliable/trustworthy (in addition to some newer ones), and this data should also be used for the DNS seeds.
<theymos> I suppose it's difficult to do this in a way that wouldn't make things even easier for a patient Sybil attacker. But the current way of mostly connecting to "fresh" peers doesn't seem very solid.
<gmaxwell> theymos: it does. it maintains two tables, one of peers that have proven functional in the past; and one for the rest. If a peer is evicted from the first list it goes into the second. Obviously it could do more health testing of the first, but the gain from doing so may not be big since peers are not authenticated.
go1111111 has quit [Read error: Connection reset by peer]
<gmaxwell> theymos: its initial connections are to old peers, not fresh ones. (also in current versions it won't DNS seed probe at all if it successfully gets connected fast enough)
<theymos> I know a little about the current mechanism, but it seems too simple. I don't have any testing supporting this, but I worry that it's too easy for you to fill up your tested-good table with relatively bad peers and evict excellent peers. I was thinking that it should maintain a score for peers, so peers would be considered a lot more trustworthy/valuable if they were the first peer to relay a ne
<theymos> w block to you, for example. I guess authentication would be necessary for this to be useful long-term.
<gmaxwell> theymos: tested good table can't be replaced, they can just age out by not working.
<gmaxwell> (thats something that was changed somewhat recently)
_biO_ has joined #bitcoin-wizards
<theymos> oh, cool!
<gmaxwell> (in response to an academic paper that presented some attacks against the scheme.. some we knew about, some that were new)
gill3s has joined #bitcoin-wizards
<gmaxwell> right now the biggest problems with it, I think, are that its awfully slow to try more peers, and also learns nothing about the network once it's already connected up (e.g. no connection probing/rotation)
JackH has quit [Ping timeout: 240 seconds]
<theymos> Yeah, probing/rotation would probably be good. Only one of your peers needs to be honest, so there's a lot of room for connecting to possibly-untrustworthy peers. I feel like there's a ton of network data that Core could be collecting (but isn't) to ensure that it has at least one good peer.
rusty has joined #bitcoin-wizards
<gmaxwell> theymos: the trick there is that you want the opposite behavior for wallet privacy.
<gmaxwell> because you want to not connect to _any_ spy nodes.
<gmaxwell> so then there are perhaps hybrid approaches where you have 4 long time consistent sockets which you never rotate and you do all your txn announcenet via those, and 4 that you rotate, and only take in txn via those...
<gmaxwell> theymos: though if someone builds an out-of-band relayer using the new functionality for that in 0.11 perhaps thats less of an issue.
<gmaxwell> but the fact that right now people are incentivized to setup socket sucking spy nodes is irritating.
<gmaxwell> and there are several commercial players effectively attacking the network at varrious levels in order to gather information on users.
<gmaxwell> (even if I were indifferent to user privacy, reducing the incentive to goof with the network would be good)
<theymos> It's pretty hard to protect against spying because you can never tell when a peer is spying. You pretty much have to use Tor, I guess.
<theymos> What do you think about including a high-latency mix network in Bitcoin? No commonly-used ones exist AFAIK.
<gmaxwell> The non-existance problem is what I think is the main barrier. Wumpus added a feature so you can disable p2p broadcast of wallet txn with a switch. Then a seperate (not yet existing, could be external) process can go broadcast for you.
<gmaxwell> e.g. over tor into a high latency mix network.
<gmaxwell> I'd like to ship such a think in bitcoin core if it existed and was reasonable.
<gmaxwell> high latency is relatively, some of the tor devs have been coauthors on papers about mixes where you can signal your desired latency... and even low latency traffic improves privacy for high latency traffic through the same relay.
c0rw|zZz is now known as c0rw1n
dEBRUYNE has joined #bitcoin-wizards
<gmaxwell> if the process is single hop you can largely prevent dos attacks by checking that the tx is valid, but if its multihop I dunno how to prevent dos.
<gmaxwell> other than hashcash.
<theymos> The no-broadcast thing is a good feature. I was thinking of creating a little script that would accept email containing a tx and then broadcast it on the network. Then you could use the old mixmaster-type networks (are these networks still maintained anymore, though?).
go1111111 has joined #bitcoin-wizards
<gmaxwell> theymos: Yes, exactly. I hoped that it would be a reasonable starter project for someone since they could fuss around with whatever programming tools they want.
c0rw1n is now known as c0rw|away
<gmaxwell> theymos: I don't know, they were kind of a couple years ago, the email exit points are always weak because they get harassment complaints. Thats one reason why a bitcoin centric service would be easier to maintain.
andy-logbot has quit [Remote host closed the connection]
andy-logbot has joined #bitcoin-wizards
* andy-logbot is logging
b_lumenkraft has quit [Read error: Connection reset by peer]
rusty has quit [Ping timeout: 265 seconds]
ThomasV has joined #bitcoin-wizards
sl01 has joined #bitcoin-wizards
<amiller> <gmaxwell> (in response to an academic paper that presented some attacks against the scheme.. some we knew about, some that were new)
<amiller> which ones? are there new papers out on this out I don't know about yet?
<gmaxwell> Bitcoin eclipse attacks paper, lemme get you the cite.
kgk has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<amiller> ok got it
damethos has quit [Quit: Bye]
n0n0_ has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 272 seconds]
AaronvanW has quit [Ping timeout: 246 seconds]
AaronvanW has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 240 seconds]
rubensayshi has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
p15 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
JackH has joined #bitcoin-wizards
sparetire_ has quit [Quit: sparetire_]
zebedee has joined #bitcoin-wizards
kyuupichan has quit [Read error: Connection reset by peer]
p15 has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 264 seconds]
Logicwax has joined #bitcoin-wizards
GAit has quit [Read error: Connection reset by peer]
dEBRUYNE has joined #bitcoin-wizards
GAit has joined #bitcoin-wizards
Tiraspol has quit [Ping timeout: 240 seconds]
Tiraspol has joined #bitcoin-wizards
MrTratta has quit [Ping timeout: 252 seconds]
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
airbreather has joined #bitcoin-wizards
rustyn_ has joined #bitcoin-wizards
rustyn has quit [Ping timeout: 264 seconds]
rustyn_ is now known as rustyn
damethos has joined #bitcoin-wizards
metamarc has quit [Read error: Connection reset by peer]
metamarc has joined #bitcoin-wizards
metamarc has joined #bitcoin-wizards
ThomasV has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Crowley2k has quit [Ping timeout: 244 seconds]
dEBRUYNE has quit [Ping timeout: 244 seconds]
nessence_ has quit [Remote host closed the connection]
nessence_ has joined #bitcoin-wizards
nessence_ has quit [Ping timeout: 255 seconds]
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
wallet42 has quit [Client Quit]
Quanttek has joined #bitcoin-wizards
<midnightmagic> adam3us: fwiw, your writing is easy to read and calm. Thank you; the clarity of your posts is much appreciated.
airbreather has quit [Remote host closed the connection]
chmod755 has joined #bitcoin-wizards
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence_ has joined #bitcoin-wizards
nessence_ has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Ping timeout: 250 seconds]
damethos has quit [Quit: Bye]
p15 has quit [Max SendQ exceeded]
p15 has joined #bitcoin-wizards
GreenIsMyPepper has quit [Ping timeout: 265 seconds]
gill3s has joined #bitcoin-wizards
p15 has quit [Max SendQ exceeded]
p15 has joined #bitcoin-wizards
eudoxia has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 256 seconds]
zebedee has quit [Ping timeout: 240 seconds]
kyuupichan has joined #bitcoin-wizards
MrTratta has joined #bitcoin-wizards
Quanttek has quit [Ping timeout: 252 seconds]
<adam3us> midnightmagic: thanks. i try. here's hoping gavinandresen & Mike Hearn can be yet persuaded to abandon the unilateral fork and bypass of the code review and maintainership of bitcoin.
<adam3us> midnightmagic: its kind of ambiguous whats going to happen.
<gavinandresen> adam3us: stop with the FUD, please
<adam3us> but thanks to jgarzik for helping steer the conversation to a BIP review oriented approach. hopefully we'll have a few more BIPs and can review it in the context of a decentralisation plan also.
<gavinandresen> code has to be written before it can be reviewed
<adam3us> gavinandresen: pardon me? your clarification on the dev-list is welcome
<kanzure> gavinandresen: forcing a hard-fork is also FUD :-)
<gavinandresen> I'm busy writing code.... then I'll be busy writing a BIP....
<kanzure> gavinandresen: you sent a nuclear email just last week; surely you remember this. "fuck you guys, i'm forking the network whether you like it or not"
<kanzure> (you used much better language though!)
<gavinandresen> kanzure: how do you think the tech should be governed? Council of Elders?
<kanzure> ((i would never imply that you have used poor language; i was paraphrasing in an uncharitable way))
<adam3us> gavinandresen: thats is good. but the question clearly that concerns people would be that you submit that BIP for review beside Jeff's and other proposals, and publicly not support the unilateral hard fork threat that Mike is pushing
<gavinandresen> you have an odd definition of 'unilateral'
<gavinandresen> ... if supermajority of exchanges, merchants and miners is 'unilateral' then I'm not sure what to say
<kanzure> the question of governance here is completely irrelevant
<adam3us> gavinandresen: do you see anyone other than mike in here agreeing with you?
<gavinandresen> governance is completely relevant: is Bitcoin goverened by the code people choose to run, or is it / should it be governed in some other way?
<kanzure> false dichotomy
prodatalab_ has joined #bitcoin-wizards
<gavinandresen> I'll say again: I'm happy to get behind some other proposal that reaches rough consensus. I like Jeff's proposal...
<kanzure> does that mean you are no longer threatening the hard-fork?
<gavinandresen> But I won't just sit on my hands and do nothing about scaling up because how and when is controversial
<adam3us> gavinandresen: as you know bitcoin is very technical and so if the entire technical community is telling you a unilateral fork is dangerous, that should be concerning no?
<gavinandresen> again, you have a very odd definition of unilateral. I'm 82% sure I've described the rollout plan to you before, and it is NOT unilateral
<adam3us> gavinandresen: not to discount the desire of the merchants exchanges at CEO level etc but i doubt they know the details at the level to judge safety, and seem completely unaware of the review and code change governance process which is in place for security & integrity of the system.
prodatalab has quit [Ping timeout: 256 seconds]
<kanzure> yeah, if those people actually have judged safety in a strict and rigorous way then i think that would be FANTASTIC news that we should be spreading all over the place; "bitcoin ceos most technically oriented ever"-- that would be like the greatest news ever.
<kanzure> "it turns out that all of the bitcoin company owners are actually coq wizards"
<gavinandresen> ok... so what is unsafe about bigger blocks?
<adam3us> gavinandresen: i thought i covered all of these topics mostly in my post to bitcoin-dev. but do you acknowledge the consensus review process for security review?
<kanzure> gavinandresen: wrong question... what is unsafe about hard-forks?
<gavinandresen> adam3us: not if Peter Todd is involved. He loves to think up miners-dancing-on-the-head-of-a-pin attacks that will never ever happen in practice.
<adam3us> gavinandresen: there are multiple questions but that is not the issue. that kind of issue could be, and is being hashed out in the technical discussion eg with jgarik's BIP
helo has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
<adam3us> gavinandresen: i think this is not just petertodd.. it seems to be every core dev and everyone else who has made significant number of patches.
<gavinandresen> really? I haven't seen any discussion of jgarzik's BIP, where has that been taking place?
<gavinandresen> (well, I saw the reddit discussion....)
p15 has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<kanzure> there was a bunch of discussion in #bitcoin-dev but i believe there were also emails?
<gavinandresen> If the safety argument is "hard forks are risky, therefore we can never do one" then... uhh... I dunno what to say.
<adam3us> gavinandresen: a number of people have been talking with him myself included (probably 6 or 7 technical people i think)
<adam3us> gavinandresen: that is a mischaracterisation
<gavinandresen> adam3us: great, so some secret Technical Council....
<kanzure> if you misharacterize basic conversation like this, why would you not make the same mistakes with bitcoin consensus code -_-
<adam3us> gavinandresen: he's been updating his BIP with the changes he's considered
<adam3us> gavinandresen: its public. i think some of this discussion would be better on list.
<gavinandresen> yes, and I've been wondering where the discussion for that is coming from.
<adam3us> gavinandresen: so i agree with you there.
nessence_ has joined #bitcoin-wizards
<adam3us> gavinandresen: discussion for what?
<kanzure> bip100
<gavinandresen> discussion for the changes to jgarzik's BIP. e.g. he suddenly went from 2MB to start to 1MB to start, I hadn't seen any discussion about that, have no idea what the reasoning was...
<gavinandresen> ... or the "I'll put in a 32MB cap so we have to go through this whole hard fork controversy again in a few years"
<adam3us> gavinandresen: so i think if you would post a BIP and retract the unilateral hard fork ultimatum that mike hearn is promoting daily, you would see more productive discussion on list. many people dont like controversy so this is creating the environment which fosters this kind of working is my guess.
<gavinandresen> I have a bunch of technical nits with that BIP, but I have little idea what gmaxwell/sipa think of it
nessence has quit [Ping timeout: 246 seconds]
helo has joined #bitcoin-wizards
<gavinandresen> Well, I'm not going to write a BIP until I've finished writing the code/unit tests/regression tests. And it seems to me that there is no danger to deploy that code for early testing to merchants and exchanges
<gavinandresen> It will do NOTHING until past a switchover date and a miner vote...
<adam3us> i have heard a whole lot of people - as far as i can tell its everyone who has a bunch of code checkins, saying that a hard-fork without consensus is unnecessarily dangers. we need to foster collaboration and consensus to reduce the risks.
<kanzure> if merchants, exchanges and miners just accept unreviewed code then i fear this network is going to implode
nessence_ has quit [Ping timeout: 246 seconds]
<gavinandresen> So if we DO need to do "an emergency hardfork" it will be much easier, because only the miners would need to update their systems.
<jgarzik> gavinandresen, private comments. reducing risk by starting out at 1MB, and then letting market take it from there
<jgarzik> gavinandresen, people dislike "unlimited" so 32MB seemed a compromise, where 2 hard forks are required to get beyond 32MB - thus two major user endorsements
<gavinandresen> jgarzik: cool. I actually have no problem with taking feedback privately, but I was reacting to the "but you've been TALKING to people in private!" comments from earlier....
<jgarzik> since we needed 32MB anyway
<adam3us> gavinandresen: it takes a while to get to 32MB if there are growth rate caps. so its not like today
<kanzure> feeding them private patches can easily change, in the future, to "feeding them patches that forks the network on their end into an altcoin". they can run whatever they want, but at the same time they might not be aware of the economic ramifications of hard-forking.
nessence has joined #bitcoin-wizards
<kanzure> private unreviewed patches, even
<kanzure> and how do they know that you didn't feed the other parties a different patchset anyway?
<kanzure> this is just... wtf.
<gavinandresen> kanzure: THE CODE IS NOT YET WRITTEN. IT WILL BE PUBLIC AND REVIEWED AND THEN ROLLED OUT IN AN XT RELEASE.
<gavinandresen> geez
<kanzure> okay using caps is nice, but you said: "And it seems to me that there is no danger to deploy that code for early testing to merchants and exchanges"
<gavinandresen> yes, after testing and review.
<kanzure> and if there are nacks everywhere?
<kanzure> well anyway; yes that will fix the different-patchsets concern.
<gavinandresen> This conversation would go better if we all could assume that we all have best intentions and are competent. I try really hard to do that....
<kanzure> it is hard to make that assumption when we receive nuclear threats
<adam3us> gavinandresen: you might have noticed that i do to. at least i try to explain that.
fanquake has joined #bitcoin-wizards
<gavinandresen> oh please, forking the open source project for a limited period of time is not a 'nuclear threat'
<kanzure> uh, that's not what you threatened
<adam3us> gavinandresen: you nor mike have been particularly clear about how its going to be limited in time
<gavinandresen> that is how open source works. If you're unhappy with the direction the project is going, fork the code....
<kanzure> you're misconstruing the history here
<kanzure> we are talking about blockchain history forks, not repository forking
<nsh> forking a project is a notably different proposition to forking a distributed consensus system :)
<adam3us> gavinandresen: its not how a consensus system works though. fork the code fine, whatever. lobby non-technical people in private to run it without a balanced presentation of risks, that is not an open or safe way to behave.
<gavinandresen> adam3us: I thought we were pretty clear: either the network will upgrade to bigger blocks, in which case Core will be forced to follow and re-integrate.
nessence has quit [Ping timeout: 240 seconds]
<gavinandresen> Or it won't, in which case XT will drop the bigger block patches and go with whatever Core does.
<kanzure> no, you were not clear at all; you said "i have convinced all these companies to run it anyway, already, and also even if i see nacks it will go forward" (actually you didn't say this; mike did)
<adam3us> gavinandresen: you know that gmaxwell, sipa, heck everyone has said that a non-consensus hard fork is the worst possible risk.
<adam3us> kanzure: precisely.
<nsh> well, if we can a priori exclude all the possibilities where something goes wrong, then i agree there's nothing to worry about
<kanzure> ((i apologize for misconstruing gavin vs mike comments))
<nsh> i'm glad we got this cleared up :)
<gavinandresen> A 50/50 split with half merchants/miners on one side and half on the other WOULD be terrible. That is not going to happen, CANNOT happen, with the patch I'm working on
<nsh> then the patch will be a proof of a hypothesis about byzantine consensus and i'll help proof read the paper the results
<adam3us> gavinandresen: i dont see how you can assure that it wont happen. that assumes the rest of the world takes your threat and runs with it.
<nsh> sorry, byzantine-consensus, macroeconomic and game-theory. prodigious :)
<nsh> *economics
<adam3us> gavinandresen: ie in the interests of pragmatism etc that you are going to force the issue and impose your BIP parameters over the majority views of everyone else, you are willing to play chicken with $3b of other peoples money?
<gavinandresen> adam3us: RE: lobbying in private: I have been extremely public this entire year about the need for bigger blocks. I've given at least three public talks, given interviews, posted to the -dev mailing list, written blog entries....
<adam3us> gavinandresen: yes and before that you had i gather many more months of private discussions where everyone technical NACKed the proposal.
<gavinandresen> adam3us: ... and my "lobbying" consisted of asking people whenever I met them: "what do you think needs to be done RE: scaling up?"
ThomasV has joined #bitcoin-wizards
<kanzure> yes and if you ask a bunch of economists they will say get rid of the scarcity; who cares?
<adam3us> gavinandresen: look i think that is a poor question to shape here. everyone who is sane wants to scale bitcoin. the question is a technical one of how within safety, security etc
<kanzure> indeed
<gavinandresen> adam3us: the NACKs were "lets wait" and/or "more testing/analysis" . Well, it's been 6 months of waiting and testing and analysis....
<adam3us> gavinandresen: well u and mike did one good thing which was to remind everyone we are only within 3x-4x excess capacity.
<gavinandresen> adam3us: see, for example, sipa's analysis of block size / fees posted to bitcoin-dev mailing list. I am perturbed that he didn't respond to my questions about that analysis....
<adam3us> gavinandresen: but you could say you did that job, and there are public attempts to do this by consensus, which i think you have to admit, is less risky
<gavinandresen> consensus is great, I'll say again: I'm happy to follow consensus on another proposal, if another reasonable proposal can get consensus. Heck, I'll even write the code....
<adam3us> gavinandresen: pieter is very distressed by the escalation of model of working, so as i said above, i expect his non-public interaction is more to do with not liking to interact in a perceived hostile space.
<kanzure> in case it's not clear, we are concerned that you haven't taken back the nuke threat
<adam3us> gavinandresen: so at this point i dont see why you dont just climb down from the threat gracefully and persuade mike to abandon the bitcoin-XT fork.
<adam3us> gavinandresen: if your proposal is better than jeff's or others based on merit i think people would be very happy to ACK it.
SDCDev has joined #bitcoin-wizards
lnsybrd has joined #bitcoin-wizards
<gavinandresen> well, I need to finish writing the code before I even HAVE a proposal. Pragmatic concerns like "how easy or hard will this be to backport" will influence the proposal
<kanzure> do you know which nuke threat we are talking about?
<adam3us> gavinandresen: i think the two things that are alarming people more than you seemed to account for, and i did warn about this privately, is overriding the code change governance model which is there for good reason; and secondly to push out a hard-fork without consensus
<gavinandresen> Releasing a version of XT that supports bigger blocks? Then asking merchants/exchanges to run it and announce "We're Big Block Ready!"
<kanzure> no, that's not what your email said specifically
* kanzure looks
<adam3us> gavinandresen: ^^ those are the questions which you are under-estimating the gravity of.
<gavinandresen> There is no "code change governance model" for Bitcoin-the-project. There is for Bitcoin Core, but I think it has been breaking down.
<adam3us> gavinandresen: i dont think anyone else thinks so. other than mike of course.
<adam3us> gavinandresen: you're well aware of the scalability work that has been done this past year for example.
* ThomasV grabs popcorn
<kanzure> adam3us: where's this email :-(
<gavinandresen> Yes, the scalability work is great!
nessence has joined #bitcoin-wizards
<gavinandresen> I would LOVE LOVE LOVE to be helping rusty with IBLT work instead of endlessly arguing in blogs, on IRC, etc.....
<adam3us> gavinandresen: and without that work changing a constant to 20MB might be problematic even on a host basis
nessence has quit [Read error: Connection reset by peer]
<adam3us> gavinandresen: well there's a simple answer to that…
<adam3us> gavinandresen: go do it and stop?
<gavinandresen> Ok, well, THERE's a fundamental difference where I think reasonable people can disagree. I think we need to create headroom for that scalability work, so we can grow into it.
<kanzure> "encourage miners to roll out a soft-fork to start producing bigger blocks"
<gavinandresen> I don't think that is dangerous
<gavinandresen> ... because miners aren't idiots.
<kanzure> hmm that wasn't the threat.. let's see...
<adam3us> gavinandresen: no i agree with that as does everyone else
<gavinandresen> If their blocks propgate slowly, they'll create smaller blocks.
hearn has joined #bitcoin-wizards
<gavinandresen> Yay! agreement!
<adam3us> gavinandresen: i prefer jeff's proposal over yours, and if you want to later move the conversation back on list i'll be happy to comment on both publicl
nessence has joined #bitcoin-wizards
<gavinandresen> adam3us: cool
nessence has quit [Read error: Connection reset by peer]
<gavinandresen> If Jeff's proposal gets consensus quickly, that'd be spiffy, I'll implement THAT instead of what I'm working on.
<kanzure> it was in this email that you threatened to hand everything over to the miners? hmm
<kanzure> still looking. i think there was one more.
<adam3us> gavinandresen: "There is no "code change governance model" for Bitcoin-the-project.  There is for Bitcoin Core, but I think it has been breaking down." i think that is a non-constrictive statement. yuo just admitted ^^ that you thought the work done under this model over the last year was great work.
<gavinandresen> kanzure: I don't think I ever said that. If I did, then I was high on crack.
<kanzure> i doubt it; most people write great code when on crack.
* nsh smiles
nessence has joined #bitcoin-wizards
<JackH> poor gavin lately :/ so much fighting
<adam3us> gavinandresen: and when you've implemented jgarzik proposal or your proposal or someone elses will you get mike to push it via Bitcoin-XT
<kanzure> ((actually now i'm curious to hear how you think crack influences you; but that's off-topic i guess.))
nessence has quit [Read error: Connection reset by peer]
<adam3us> JackH: no this is good, talking is better than not talking *always*
<gavinandresen> adam3us: Bitcoin Core process works OK for incremental changes. For anything controversial... not so much. See the P2SH controversy for the first good example.
<nsh> that analysis may not take account of all of the terrible changes that haven't been made, and their value
<JackH> I know, I have been following this alot myself. nice to see gavin in here, but still a rotten page in the book of Bitcoin with all this
<adam3us> gavinandresen: i dont know if you have this view, but the consensus afterwards was that the one you pushed for was worse than the one you overrode
<adam3us> gavinandresen: on p2sh. people just didnt care enough to fight. size limits on it.
<gavinandresen> adam3us: "get mike to push it..." Well, I'm being really mean to Mike-- I'm making him be Benevolent Dictator of the XT project
kyuupichan has quit [Remote host closed the connection]
<adam3us> gavinandresen: well collaborate with mike, rather.
kyuupichan has joined #bitcoin-wizards
<JackH> what surprises me the most about this debate: gavin, is how you have fought so hard to keep in implementing XT
kyuupichan has quit [Remote host closed the connection]
llllllllll has joined #bitcoin-wizards
<gavinandresen> Sure, I think Mike and I will continue to encourage merchants/exchanges (and eventually miners) to upgrade to a codebase that supports bigger blocks.
<JackH> you made it into a goal
<adam3us> gavinandresen: the question is serious and the crux of it however: going ahead with unilateral actions.
<gavinandresen> If Core supports bigger blocks, then cool!
<kanzure> (isn't there something broken about using block version number "voting" from miners for a hard-fork about max block size. isn't that one of the things in the list of things that should never be done?)
<Eliel> There will be a chain with support for higher transaction throughput and lot of people will migrate to it. What I don't know is if it'll end up being named Bitcoin. It doesn't look like everyone here understands this.
<adam3us> gavinandresen: so as that looks to be happening anyway within the consensus process .. thanks in part to you and mike reminding people .. why is there a need even for bitcoin-XT as a vehicle now?
kyuupichan has joined #bitcoin-wizards
<gavinandresen> So... I've called Bitcoin Core the "reference implementation" .... implying that there will be other implementations. And there are, but none of them have really taken off yet.
<Eliel> it doesn't matter even if everyone here agrees 1MB blocks are the way to go. It will still happen.
<kanzure> Eliel: that's not helpful
<kanzure> Eliel: although your previous comment was more helpful
<adam3us> gavinandresen: you could save a lot of devs a lot of stress, and reduce risk etc etc by just retracting (even just temporarily!) the unilateral assertions that you and mike have been making about forking the codebase tied to a network fork overuling the rest of the core deve teams advice
<gavinandresen> If Bitcoin is successful, there will be a LOT of implementations. I think I agree with Mike that the governance model for Bitcoin Core (NOT the bitcoin project) cannot work in the long run
<adam3us> gavinandresen: yes but this is why libconsensus is being worked on, it can be dangerous to diverge via subtle bugs
kyuupichan has quit [Remote host closed the connection]
kyuupichan has joined #bitcoin-wizards
<kanzure> gavinandresen: so more specifically it sounds like you do not want to participate in the bitcoin-core development team long-term?
<adam3us> gavinandresen: lets give you a hypothetical, say bitcoin is not $3b but $30 trillion. do you really think its appropriate that one person who disagrees with the rest of the technical experts can get away with bypassing all other opinions?
<kanzure> long-term, mind you
<kanzure> adam3us: he has already said yes- that's mike's position, yo
<adam3us> kanzure: but thats not rational
<kanzure> neither is mike
<JackH> so you just want to work on another reference implementation?
<gavinandresen> adam3us: sure, if that one person can convince a supermajority of people that their vision is correct.
<adam3us> kanzure: nah mike is rational, just pragmatic, and has different assumptions about scaling that ends with fiber channel links in datacenters.
damethos has joined #bitcoin-wizards
<JackH> but, cant you do that without forking the network?
<kanzure> adam3us: fair enough
<kanzure> JackH: agreed; working on a different implementation can still occur without forking the network, or convincing miners to start pumping out hard-fork block version numbers
<adam3us> gavinandresen: should the super-majority include the technical people who understand the technical risks?
<gavinandresen> adam3us: history is full of times when one expert was right but conventional wisdom of the time was wrong...
<gavinandresen> If I was an asshole I'd claim I was the Galileo of Bitcoin :-)
<adam3us> gavinandresen: this thing feels like reactor design by lynchmob on the receiving end
<hearn> my ears were tingling ...
<kanzure> gavinandresen: nobody has ever claimed that the bitcoin currency will disappear with 20 MB blocks. they have claimed lots of risk related to a controversial hard-fork. these are separate topics dude.
lnsybrd has quit [Quit: lnsybrd]
<adam3us> kanzure: exactly.
<nsh> (history is devoid of times precedent here)
<gavinandresen> adam3us: there's another place reasonable people can disagree-- what are the risks versus benefits of proposed changes ?
<nsh> (to suggest otherwise is inexcusable folly)
<nsh> -times
<adam3us> hearn: afternoon. some air clearing, which hopefully gets somewhere productive.
<hearn> adam3us: with due respect, i think there's something important here. you and a few others have some deep expertise in a very narrow area of the bitcoin project (theoretical cryptography). as you have yourself said, many other areas are not really your cup of tea. for example, UX.
<hearn> now what i'm seeing in these discussions is a dismissal of everyone elses expertise. bitcoin needs everyone, with all their backgrounds
<nsh> ($10 billion is not secured on cutting-edge UX)
<hearn> gavin and myself have both been around longer and written far more code
<kanzure> hearn: argument from authority; boring predictable try again please.
<JackH> but hearn, if we dont agree with that?
<kanzure> hearn: you can surely do better tha nthat
<hearn> so it would be nice if we could all start by recognising each others experience
<adam3us> gavinandresen: why would it be worth even the controversy to impose a view for your preferreed parameters vs jeff's for example thats where we are right now.
<hearn> kanzure: shush
<JackH> I mean, you need all the business to go along with your ideas
<kanzure> hearn: no; we should start yb abjectly rejecting all prior experience. we should not be speaking from authority.
<JackH> our business for sure wont switch to XT
<JackH> not under these circumstances
<adam3us> hearn: ack.
<kanzure> gavinandresen: there are some limits to where reasonable people can disagree.
<hearn> adam3us: do you recognise and understand the concerns myself and most other wallet developers have about what happens when blocks get full? we can start here, i think
<hearn> adam3us: that is, we think our wallets will break and our users will get very upset. understandably so.
<hearn> (well, we are already starting to see complaints, but that will get a lot worse)
<kanzure> block size topic is different from the nuclear threat prevention we were attempting above
<Eliel> ... I'm appalled that people are using words like "impose" in this context... no single person is able to do that in this context. You'd have to misunderstand the most basic nature of Bitcoin to claim anything like that.
<kanzure> it is wrong to misconstrue these topics as the same one
<nsh> so best would be to try and formally model how your perception of that risk increases in line with the projections of transaction volume tend to the current capacity ceiling
<adam3us> gavinandresen: i think things have shifted - there are now multiple proposals in review in bitcoin-dev. why would you not once written submit a BIP there and see which one wins the design review and safety parameters etc and then help implement whichever that is?
<nsh> and to see where the point of transition is relative to the risk of problems associated with non-consensus hard-fork
<nsh> because it may vary between interest, and that might help us discuss facts, and not perceptions
<hearn> adam3us: a BIP is a document that describes what is being done - as the patch and its parameters are not yet finalised, it would make sense to write a BIP after the patch is written, or alongside it. which is what gavin is doing, i believe
<kanzure> i think that gavinandresen should consider that he can work on an alternative reference implementation without forking the network; if that's really what he wants, then he should be happy to learn that network blockchain forking is unnecessary for that to happen.
<adam3us> hearn: of course. i never said i didnt want to see a throughput increase that feeds into decentralisatoin work and later algorithmic work. i spelled it out at the bottom of my post you responded to
<hearn> beforethen other documents have been written and debated. they don't have numbers, but that doesn't seem like a big deal.
<hearn> adam3us: alright. then you understand why we are so concerned. that is good.
<adam3us> gavinandresen: i think things have shifted - there are now multiple proposals in review in bitcoin-dev.  why would you not once written submit a BIP there and see which one wins the design review and safety parameters etc and then help implement whichever that is?
Madars has quit [Ping timeout: 255 seconds]
<hearn> adam3us: so do you understand why we feel the block size needs to be increased, with the process starting now?
<kanzure> this is unrelated
<nsh> everyone understands why. the divergence is on the urgency
<gavinandresen> yes, that's what I'm doing. As I implement, tiny little details become clear-- for example, the code is much simpler if all of the information needed to decide how large a block can be is in the block header... (so dependent only on timestamp and version)
<hearn> adam3us: and why we feel frustration with the apparent inability to start that process?
<adam3us> hearn: the process seems to be moving along now.. (with some thanks to you and gavinandresen)
<nsh> is it not started? what would be the formal start, hearn?
<adam3us> hearn: i refer to the list of proposals kanzure just posted for evidence
<gavinandresen> adam3us: my impression is that until sidechains launched the process wasn't going to go anywhere, because greg and pieter were busy.....
<hearn> and yet this morning when i read my mail, i see a message from one of your coworkers (mark) saying that there's no consensus around any proposal
<kanzure> gavinandresen: completely wrong; gmaxwell was posting and discussing the most comments perhaps he ever has, during the weeks leading up to the sidechain release
<hearn> so who am i to believe? ultimately the decider is wladimir. but he has said for as long as a change is controversial, it won't be accepted.
<hearn> hence -> deadlock
<kanzure> gavinandresen: if you go look at his timestamps on his reddit comments emails etc. it's truly impressive that he was able to type on two keyboards at once one for bitcoin discussion and the other for sidechain development
<adam3us> gavinandresen: well i think fwiw sipa spent > 75% of his work time and free time on bitcon-core work with the exception perhaps of a week or two on crunch to push sidechains out.
<kanzure> ((i am only an amateur at two-keyboard typing))
<gavinandresen> kanzure: sure, but my last several emails to gmaxwell were just ignored, so I had no idea what he was thinking or what was going on. Hence, frustration on my part....
<adam3us> hearn: not everyone agrees on the ordering of things, maaku has a different view. we have independence in bitcoind matters
<kanzure> gavinandresen: fair enough
<kanzure> hearn: everyone is always going to point out when you misconstrue hard-fork threats for max block size scalability issues
<JackH> hearn: why dont you just accept that people think 20MB is too much?
<kanzure> JackH: i believe he has said other numbers he's okay with
<hearn> the exact number is certainly open to negotiation
<kanzure> JackH: so that's not fair
<hearn> i see today the chinese miners have reached consensus on 8mb
<hearn> 8 is a lucky number, right?
<adam3us> gavinandresen: so now that the process has started (again thanks to you and hearn for pushing it forward) how about we work cordially and abandon the threat of unilateral hard-fork. work on reviewing and implementing various BIPs and decide a winner and plan and go deploy it?
<hearn> i am waiting to see what gavinandresen's patch does.
<kanzure> JackH: all i ask is that everyone has perfect recall and perfect memory of all statements that everyone has ever made; is that too much to ask? :-)
<helo> the sign of a stable government is slow (or no) change
<gavinandresen> 8 IS a lucky number. Not as good as eleven....
<nsh> so there is discussion, there is interest, there is plenty of good-faith, there is code being made ready to present, and then BIP being written. seems to me things are moving along
<hearn> gavinandresen: haha :)
* hearn doesn't have any favourite number, he feels left out ...
<hearn> maybe 99
<helo> NULL?
<hearn> i got 99 problems by 1 ain't 1
<hearn> oops. that joke was a bit mangled by bad typing
<nsh> aleph-gamel
<JackH> kazure: I know of the 8BM yes, but I am not sure if hearn explicitly said he was ok with that
<adam3us> gavinandresen: coincidentally i had suggested to jeff some different parameters including 8MB as a hard-cap. that will see that lasting for enough years to do quite a lot of other work.
<kanzure> JackH: i was kidding dude; i don't expect you to have perfect memory or to follow all posts simultaneously.
<adam3us> hearn: 1GB ;)
<kanzure> i am concerned by how nobody has disarmed the nuclear threat
<adam3us> hearn: sorry that was maybe not constuctive, perhaps not time for humor.
<JackH> yeah hearn, I actually posted something on bitcointalk, about how neither you or gavin can answer the question to what happens when we reach 20MB
<nsh> has anyone actually analyzed whether or not it's academic (like, if some other bottleneck will manifest before 32MB blocks)
<nsh> ?
<nsh> at some size it becomes academic, certainly
<JackH> and if we should increase again
<hearn> nsh: i'm absolutely sure it will
<adam3us> nsh: gavinandresen tested somthings up to 8MB I believe
<hearn> nsh: there will probably be many bottlenecks on the way up. it's the nature of scaling things.
* nsh nods
<nsh> might be worth trying to simulate
<gavinandresen> Parameters for the patch I'm working on: 8MB cap, earliest fork time 11 Jan 2016, requires 75% hashpower to support, two-week grace period (no big blocks) once 75% reached, cap doubles every two years.
Madars has joined #bitcoin-wizards
<hearn> nsh: what's more simply making bitcoin popular enough to hit scaling problems is a whole other kettle of fish
* nsh nods
<gavinandresen> ... oh, and stops doubling after 20 years.
<nsh> hah
<hearn> nsh: at some point Bloom filtering will stop scaling, for instance. i have kicked around a few ideas for what comes after. but ..... let's cross these hurdles as we come to them. our understanding and resources will be better by then anyway.
* nsh nods
<gavinandresen> That should be enough parameters to make EVERYBODY unhappy......
<JackH> you guys seriously actually believe that nodes will be serving many hundreds of gigabytes eh? eventually?
<hearn> JackH: it's kind of tough to imagine, isn't it
<gavinandresen> JackH: Sure, why not?
<kanzure> i think that not threatening people is a good start to making everyone happy
<adam3us> gavinandresen: oh auto-doubling? i think jgarzik had or review comments for example growth limiter at 50% or below/year.
<gavinandresen> JackH: if they can't serve hundreds of gigabytes, then they wont.
<hearn> JackH: but then i remember when the only person i could send bitcoins to was satoshi. the whole story of bitcoin has been unexpected and hard to imagine
<adam3us> gavinandresen: no growth rate limit?
<gavinandresen> adam3us: doubling every two years is 40% growth per year.
<hearn> JackH: anyway, the fact is, no technology grows exponentially for very long. growth slows and plateaus eventually. it's hard or impossible to guess exactly where
<adam3us> gavinandresen: sorry i thought you said per year.
<Eliel> kanzure: I think it'd be a good idea to realize that the very fact that those threats are credible means that gavin is actually just messenger. Not the origin of what you label a "threat".
<hearn> JackH: that's why successful systems tend to build the system they need to manage the next phase of growth, rather than try to design something that can handle infinite growth right up front
<JackH> the way I see it, is that your "patch" is killing my efforts of becoming a full node, thus I cannot verify, thus I cannot be part of the network
<adam3us> gavinandresen: but whats doubling the cap?
<kanzure> Eliel: can you elaborate?
<JackH> thus you are creating central points, like ISP's
<JackH> and then its bye bye to Bitcoin as a perfectly decentral system
<gavinandresen> adam3us: hmm? 8MB in 2016, cap would be 16 MB blocks in 2018, etc
<adam3us> Eliel: its clear everyone wants bitcoin to scale so that everyone can benefit
<kanzure> Eliel: they are credible only because i believe that companies miners and exchanges can be convinced to use patches that are against their interest or the interest of the network.
nessence has joined #bitcoin-wizards
<leakypat> The nuclear threat should be withdrawn, creates a lot of uncertainty and divisiveness , I'm sure wallet makers are way more concerned about a split than the blocks hitting the hard cap at some point
<helo> 50% max blocksize growth mid-subsidy starting from the first block
<adam3us> gavinandresen: ok. jgarziks' is 32MB hard-cap (that does not grow) and a growth limiter (i think 2x every 18mo) by soft-cap
<JackH> Despite the fact that our payment gateway, (yes we are running a payment gateway for Bitcoin in EU), is serving a full node and can scale hugely, this is still not enough for me.
<adam3us> adam3us: however not sure were exactly he is on the growth-limiter. someone could look at bip-100 latest
<helo> that would put it at 2.25MB right now, i think
<hearn> JackH: there are people who can't afford to run a full node today. shall we fix that by evicting the transactions your payment processor is handling so we get smaller blocks? the line has to be drawn somewhere.
<nsh> adam3us, what is the concern regarding unlimited growth?
<gavinandresen> adam3us: yup. As I said, that's OK with me, too, although the code is trickier.
<adam3us> gavinandresen: it does seem sensible to not provide system shocks, as a general principle. so jeff had mentioned that.
Mably has quit [Ping timeout: 246 seconds]
<hearn> JackH: anyway, this has been debated to death. look at http://www.gavinandresen.ninja for many articles discussing this topic
<adam3us> gavinandresen: ok so this sounds all agreeable and reasonable and i am sort of puzzled why we let this get so far out of whack.
<JackH> hearn: And even less will be able to run a full node. And if we get too many transactions we wont use Bitcoin itself anyway, but some sidechain or lighting. I wont take the risk of double spend for 10 min if we have 10 million transactions
<nsh> (is it wrong to assume abnormally-large blocks will be disincentivized by propagation time)
<helo> and it would be trivial to implement
<gavinandresen> adam3us: Bad timing maybe? I know everybody at blockstream has been super-stressed to get sidechains out....
<JackH> I have everything to gain in a sense from increased block sizes, from the point of view of the Bitcoin payment business. But I have everything to loose for allowing it to happen, by killing Bitcoin in the process
<adam3us> gavinandresen: so i think the thing that can simply return things to normal and get people focussed back on review simulations and network stats etc. is to clarify that (if you agree) you will participate with the BIP review process and take the winning outcome.
<helo> and it would be more likely to stay well below any system performance growth (bandwidth, etc)
<helo> and encourage off-chain uses for things that don't need to be on-chain
<Eliel> kanzure: There's enough pressure from the community to do something about this by now that if gavin doesn't do it, someone else will. Which is most likely very bad idea unless that someone else ends up being the entire bitcoin core team.
<kanzure> gavinandresen: blaming blockstream for your threats is poor form
<nsh> kanzure, that wasn't how i read it
<kanzure> nsh: go on
<adam3us> gavinandresen: there were a few too many 18hr days there for a few weeks for sure.
<helo> ^
<leakypat> kanzure: come on dude
<kanzure> leakypat: i'm listening
wallet42 has joined #bitcoin-wizards
<gavinandresen> adam3us: mmmm.... see BIP16 versus BIP17 for what I think is likely to happen with a "BIP review process"
<adam3us> gavinandresen: that was the p2sh one?
<gavinandresen> adam3us: yup
nessence has quit [Ping timeout: 250 seconds]
<helo> kanzure: "everyone that would be commenting was busy working on sidechains"
<gavinandresen> adam3us: Eventually I was just the bad guy and said "It's gonna be BIP16"
<kanzure> Eliel: i think that others forking the network is less likely to get wide adoption; companies are used to centralized systems so gavin going to them and saying "here's some patches yo" is something they would likely accept whereas anyone else bringing the patches would perhaps get significantly more suspicion.
<adam3us> gavinandresen: so you do realise that gmaxwell, luke-jr and others preferred luke-jrs bip over yours, and especially in hindsight realised that there is a defect in yours and luke's would have been better.
<hearn> please guys. let's not re-open P2SH
<hearn> it's done. it works. the world continues.
<kanzure> it can be used as a learning experience
<hearn> i agree with gavin that a "use the winner" process is rather the core of the problem here
<kanzure> i'm confused why you two are spouting different histories
<hearn> as there is no process to pick a winner
<gavinandresen> Yes, hindsight is 20/20, learn from mistakes and move on, perfect is enemy of the good, etc etc
<kanzure> was there a disagreement regarding which patch got merged?
Mably has joined #bitcoin-wizards
<kanzure> e.g. i mean an issue of historical fact
<hearn> e.g. the consensus that is so often discussed is a consenus of ....... who? who gets to be in that group and how did they get there? so i'm not sure how such a process would work
<adam3us> kanzure: its because gavin tried to exercise sort of initiative to short-cut the discussion he's suggesting this is relevant here. which i think could be discussed.
Giszmo has joined #bitcoin-wizards
<kanzure> adam3us: yes, i can see why others might not want to discuss that
<Eliel> kanzure: There isn't a shortage of people who can be convincing enough. Especially when almost everyone feels like some kind of a solution is needed.
<adam3us> gavinandresen: but as you brought it up i thought it relevant to actually point out that if you had not done that the other would have won, and they had misgivings and turned out to be correct.
<hearn> for what it's worth, i was not totally sold on P2SH either, but in the end realised i had got it wrong. i wanted a pure payment protocol based approach and hoped that requiring BIP70 to do multisig would incentivise (uh oh) the creation of the necessary infrastructure
<hearn> in practice that didn't happen. gavin was right - people weren't ready to leave bitcoin addresses
<kanzure> Eliel: yes, but the difference is how the solutions are implemented :-)
<hearn> lesson learned: trying to "incentivise" people to build what you want by blocking other solutions isn't a good idea
<JackH> hearn: would you change your mind if satoshi was to say that 20MB is not the right way forward?
<kanzure> helo: i didn't forget your message; i'm just confused what you wanted me to do or say in response to it.
<nsh> likewise consensus code updates, perhaps
nessence has joined #bitcoin-wizards
<hearn> JackH: lol, he already did
<JackH> hearn: those were different times and you know that
nessence has quit [Read error: Connection reset by peer]
<nsh> clearing your throat to get a discussion started is fine, and indicated
<nsh> growling the whole time to direct that discussion isn't
<hearn> JackH: satoshi said several times that the 1mb limit was only there until SPV clients existed, and after that the limit could be entirely removed.
<JackH> hearn: back then anything was a go
www has quit [Ping timeout: 256 seconds]
<nsh> and i'm sure no-one is trying to do the latter :)
nessence has joined #bitcoin-wizards
<kanzure> this rewrite of history is inappropriate
<JackH> hearn: we were like what? 200 dudes?
<hearn> JackH: so why ask me what i'd do if satoshi said X, when he already said it, if you're just going to immediately say "oh well that was different times"? seems like not a very useful question.
nessence has quit [Read error: Connection reset by peer]
<adam3us> gavinandresen: so given that there's momentum on multiple proposals in review it and its safer not have controversy for the success of the hard fork, and generally for public communication if the development people are acting colaboratively, how about using the process and implementing the winner?
instagibbs has joined #bitcoin-wizards
<helo> kanzure: how i read what gavin said re: bad timing
<hearn> adam3us: can you outline *specifically* what the process you have in mind is?
<adam3us> gavinandresen: it seems like you are OK for example with jgarzik's proposal or presumably variants of it because the parameters are quite different from yours.
<JackH> hearn: I asked if he was to say something now, not back then. But an updated satoshi idea
<instagibbs> hearn: I agree "consensus" is fuzzy. But (N-1)-core dev opposition clearly isn't it. "I"ll know it when I see it" sort of applies here
<kanzure> helo: ah; but the evidence is that the sidechain developers were actually actively commenting on reddit and in emails. look at the timestamps.
<hearn> adam3us: e.g. to the level we could implement it in a little web app or something
<gavinandresen> adam3us: how about not putting all our eggs in one basket and not putting some fuzzy process with no clear endpoint on the critical path?
nessence has joined #bitcoin-wizards
<kanzure> gavinandresen: so network consensus is definitely a basket
<kanzure> that's called a blockchain
<instagibbs> You clearly wouldn't say N/2 For, N/2 Against was consensus
<instagibbs> why is N-1 "maybe consensus"
nessence has quit [Read error: Connection reset by peer]
<hearn> instagibbs: what is N equal to here?
dEBRUYNE has joined #bitcoin-wizards
darwin__ has joined #bitcoin-wizards
<instagibbs> Specifically core dev set, to be clear
<adam3us> gavinandresen: because it is safer on several aspects that i explained in my post. its constructive, collaborative, benefits from peer review, gets more public discussion, stops us looking bad in public as the tech brains behind bitcoin, etc
<nsh> hearn, it's the bagholders of technical debt
darwin_ has quit [Read error: Connection reset by peer]
<nsh> (you do not want to be the sole bagholder of bitcoin's technical debt)
<hearn> instagibbs: and who is in that set?
<nsh> (i promise you)
nessence has joined #bitcoin-wizards
<instagibbs> hearn: Can you show me your list of core devs that have consensus for a fork?
nessence has quit [Read error: Connection reset by peer]
<instagibbs> including dissenters
<kanzure> hearn: btw i think your time would be better spent replying to adam3us' email than replying in here
<kanzure> someone requested in-line responses
<adam3us> gavinandresen: i'm not sure you maybe explained very clearly and perhaps that bit wasnt what you were focussing on, but the message that hearn would be in sole control of bitcoin maintainership of bitcoin for a non-trivial period is not good for security, integrity, avoidance of speciali interest lobbying, blackmail, getting hit by a truck etc etc. and jsut perception wise. (no offence to hearn - same would be true of any one person)
<hearn> in the event that i have a bad date with a truck, the github fork button will still work :)
nessence has joined #bitcoin-wizards
<hearn> but anyway, yes if bitcoin XT gets serious traction i would make gavin a maintainer
<kanzure> further misinterpretation
<gavinandresen> adam3us: you're confounding bitcoin-the-project with various implementations...
<kanzure> the fork button does not cause network hard-forks
<JackH> hearn: you will never get our business to follow you. I think that is all that remains to be said. Go ahead, fork away, try to split the network. But you wont gain consensus and we will never bow to centralisation from the people that paid you and Gavin
<hearn> i wouldn't worry about the mechanics of this. i have run several successful open source projects
<kanzure> you are clearly unable to read
<kanzure> do you really think adam3us meant "forking an open source project's source code repository"?
<kanzure> really?
<nsh> perhaps we need to use different words
<adam3us> gavinandresen: there is also quite a bit of infrastructure around bitcoin. the reviewer process requireing consensus approval to stop bugs getting snuck in if someones children were captive and they blackmailed for example.
<nsh> if this continues to be a problem :)
<nsh> what was the event that lead to the split between the western and eastern roman empires?
StephenM347 has joined #bitcoin-wizards
<hearn> kanzure: he was talking about maintainership so yes
<nsh> i'm sure it has a suitably cataclysmic name
<kanzure> hearn: okay so you think that maintainership has nothing to do with hard-forking?
<gavinandresen> ok, I think my time is better spent finishing writing regression and unit tests....
<adam3us> gavinandresen: and the security incident management etc
<JackH> we will never bow to XT
<adam3us> gavinandresen: no comment on choosing the winner from the BIP process to normalise relations and act with a unified technical view in public?
<kanzure> (why would anyone want to use a fork of bitcoin-core if the maintainers are incapable of distinguishing between repository forks and consensus hard-forks and multiple blockchains?)
<adam3us> gavinandresen: its not like you coudlnt back out if you though the process selection was supremely bad even…
temujin has joined #bitcoin-wizards
<helo> the 20MB patch probably won't become more popular in the near future than it is right now. so the window of opportunity to shove it through is closing.
<kanzure> gavinandresen: to make it clear, we're still trying to get you to admit that the threat should be revoked, and replaced with the previous procedures instead
<helo> "if we can just postpone its depoloyment long enough" vs "if we can just deploy it post-haste"
<kanzure> gavinandresen: i think many good reasons have been presented for this
<gavinandresen> adam3us: consensus is, ultimately, the code people choose to run. I'm happy to propose a BIP, would be even happier if there was only one BIP that everybody agreed was best.
nessence_ has joined #bitcoin-wizards
<nsh> so developer consensus is valueless :/
<adam3us> gavinandresen: proposing to fork it seems kind of pointless now that there are multiple public process, so why not just join the fray?
<kanzure> gavinandresen: do you think that asking companies to run your fork would be more or less likely to result in companies to run a hard-forking network, regardless of technical merits?
nessence has quit [Ping timeout: 256 seconds]
<adam3us> gavinandresen: it deescalates teh situation leads to better open public communication and should lead to a better technical result
<hearn> nsh: i would say it's rather, undefined
<gavinandresen> ... but I'm not going to propose a BIP until I've written code that implements it, because I think BIPs should be descriptive, not proscriptive.
<adam3us> gavinandresen: thats fine of course. i dont know if jgarzik started implementing but i presume people would expect that.
<nsh> and of course you can't lobby without code or a proposal anyway
<kanzure> nsh: on the contrary?
<nsh> because peopel would be silly to sign up to something that doesn't exist :)
<nsh> unfortunately, people are silly
<kanzure> nsh: that's what the claims have been, so far
<nsh> so try not to lobby :)
priidu has quit [Ping timeout: 272 seconds]
mjerr has quit [Ping timeout: 250 seconds]
<gavinandresen> I think that is a reasonable bar for BIPs : if you care enough to actually implement it, then your BIP deserves serious consideration. Otherwise the BIP process gets overwhelmed with half-thought-out proposals....
<nsh> it's just a matter of phrasing the solicitation that *is* required to draft a proposal such that it doesn't seem like a request for endorsement
<adam3us> gavinandresen: but again, sorry to keep badgering on this one topic, but its just sooo much more constructive and i rdo think will result in a better outcome if you would just agree to suspend the hard-fork threat for now. its not a big ask in the context that you even seemed to be ok with jgarziks proposal.
<nsh> and there, problem solved
<nsh> (i did market research. you don't end a survey with 'and will you buy the product we make with this feedback')
<nsh> (that would be prohibited, even)
<gavinandresen> adam3us: there will absolutely, positively be no hard fork before January. Is that sufficient?
<adam3us> gavinandresen: it will also save 100s of wasted bitcoin developer cycles lobbying companies CEOs and things like the bitcoin.org site that i'm sure you saw
nessence_ has quit [Ping timeout: 244 seconds]
<kanzure> gavinandresen: we're not talking about "any possible hard-fork", we're talking about the one you threatened....
<adam3us> gavinandresen: i'm not sure what you mean. is that the date code is rolled out. or rather when deployed hard-fork deployed in the next month that will trigger by 1st jan?
<helo> gavinandresen: so you're sticking with your contentious hard fork plan as-is?
<gavinandresen> adam3us: that's the trigger date. Obviously the code needs to be rolled out before then....
<nsh> great, now the nuke has a trigger
<gavinandresen> (well, that's the earliest-possible-trigger date)
<adam3us> gavinandresen: so then that wasnt really an answer i think.
* nsh can't wait for the launch codes
<nsh> :)
<JackH> nuke indeed
<Eliel> adam3us: in other words, you don't think gavin should be placing the issue of whether or not to fork to a public vote.
<hearn> the answer is "no", adam
<JackH> impressive the person that was handed the reigns from Satoshi is the person that is trying to destroy that very same project now
<kanzure> Eliel: that's not what he claimed he was doing
<kanzure> Eliel: he claimed he was getting companies to adopt the patch regardless of bip process, and that a hard-fork will occur anyway
<adam3us> gavinandresen: i'm trying to be constructive here. this is causing a lot of very productive coders working on bitcoin-dev a huge amount of stress. i'm not asking you to give much up if you're anyway basically agreeing with jgarzik's proposal or ones similar to it.
<Eliel> kanzure: I don't care what he claimed he's doing. That is what he's doing.
<kanzure> Eliel: public vote was never an option
<Taek> JackH: no personal attacks please.
<helo> JackH: less hyperbole ;)
<kanzure> cool
<gavinandresen> adam3us: how about: I commit to writing a BIP, and I will ask Mike to not rollout an XT release until that BIP and the code has had at least... ummm, three weeks of review.
<hearn> please be aware of something important. i'm starting to hear from people that investors both current and "thinking about it" are realising that Blockstream appears to be able to block a change that has extremely strong, widespread commercial support. and they are freaking out about it.
<JackH> Taek: not a personal attack, just witnessing the irony of it all
<kanzure> gavinandresen: how about more specifically, "I will not ask companies to run this hard-fork, and I will not ask them to join me on hard-forking the network."
* dgenr8 notes gavin broke is his self-imposed rule of only discussing alternative blocksize solutions that were implemented
<nsh> gavinandresen, can you submit a BIP about the three-week review hard-limit first?
<nsh> :)
<hearn> if you guys are really such strong supporters of decentralisation, you *must* accept that hard forks are a way to resolve problems when other paths have failed
<JackH> hearn: that is a lie, nobody is thinking anyone is blocking anything, people just think you are trying to destroy Bitcoin by forking it
<kanzure> hearn: that's good! companies can be threatened by the us government in general, even to accept bad or broken patches.
<nsh> hearn, we just don't believe in waving failure around as a bat
<hearn> otherwise what you are asking for is basically, a dictatorship of blockstream
<adam3us> gavinandresen: that seems good, but i was kind of assuming you would put the code for review anyway. the question is more about will you put your bip in parallel code review beside jgarziks and similar alternatives and let the technical reviews which include you and hearn agree on which is best.
<JackH> hearn: the only problem is XT
<hearn> and that's not really decentralisation, is it?
<dgenr8> has anybody other than gavin actually written any code around this?
<adam3us> gavinandresen: the proposals dont seem different enough to make an issue out of this. you already agreed to jgarziks
<kanzure> hearn: nice try, but that's not a good argument at all
<hearn> it's not an "argument". it's me repeating what i'm hearing other people conclude. and can you blame them?
<kanzure> yes, i can blame anyone i want
<kanzure> wtf?
<hearn> adam3us: you have failed to describe what this "BIP process" is, in anywhere near sufficient detail for anyone to agree to it.
<JackH> hearn: do you realize nobody in this very IRC chat right now seems to think what you are doing is a good idea? or does that not matter? XT 4 ever right?
<hearn> adam3us: what's the decision making algorithm, here?
<gavinandresen> adam3us: I have a bunch of technical nits with jgarzik's proposal, and I HATE the 32MB cap (just means we go through this again at some point), but sure, if that is consensus, then spiffy.
<kanzure> hearn: it really doesn't matter what delusions you inject into the conversation
<hearn> title: "Should the Bitcoin block size limit be raised within the next two years? - Poll Results"
<helo> gavinandresen: hearn: not deploying contentious hardforks > *
<hearn> results: 92% say yes
<kanzure> haha
<JackH> LMAO
<adam3us> gavinandresen: well the point of the review process is that you get to pick nits in jgarziks and others and vice versa. so thats good. jgarzik i believe already made several updates based on feedback. (which would have been better made in public)
<nsh> how much did the measure that defined pi to be 3 in some US state pass by?
b_lumenkraft has joined #bitcoin-wizards
<nsh> i bet it was a strong, godfearing majority
* hearn shrugs
<JackH> hearn: nice pool, odd it is closed and doesnt really prove anything.
<adam3us> gavinandresen: but it kind of makes a lie of the review process if one party is saying that they will overrule its outcome. i dont want to paint you wrongly as having said that. but clarification would really help just to clear the air and move forwards.
<helo> you obviously have the PR battle in pocket for your hard fork. but a lot of people that care about (and understand very well) bitcoin are in that 8%.
<kanzure> okay, so it sounds like gavinandresen is not going to answer adam3us at all
<hearn> ignore whatever evidence you like. i guess 10 minutes in #bitcoin-wizards is all the polling needed :)
<kanzure> hearn: yeah, because polling makes sooo much sense to decide the value of pi
<adam3us> hearn: no one is disputing that everyone wants to scale bitcoin.
<JackH> hearn: We have 20.000 clients right now for Bitcoin processing
Xh1pher has joined #bitcoin-wizards
<JackH> I can assure you one thing. NOT ONE of those will ever use XT
<hearn> the poll didn't ask about "scaling" in a general sense. it asked about raising the block size limit.
<JackH> you can poll whatever you want, we are all capable of seeing through this
<adam3us> hearn: including most saying they think the first step of which is a proposal to create extra throughput and time to work on a longer term solution.
<hearn> JackH: alright. just so i can keep track of things in my lists, which payment processor is yours?
<helo> so you can choose to leverage your (likely temporary) PR victory now and try to push through, or defer to the relevance of all of the people pleading with you to backpedal a bit.
<kanzure> .title
<yoleaux> NorthPayments, a leading payment processor in the UK, collaborate with BitcoinPayGate.com to introduce an alternative payment option for customers
<JackH> Go ahead and DDoS us now since we dont agree to bow to you
<dgenr8> gavinandresen: do you plan to submit the patch to both bitcoin and bitcoinxt?
* nsh doesn't claim any relevance, for the record :)
<hearn> ok, thanks
<hearn> um, no, i don't DDoS people who disagree with me
<kanzure> you can't prove that
<kanzure> nobody could
<nsh> JackH, please.. :)
<JackH> no you just try to remove Bitcoin from the equation ;)
<JackH> how much did you get paid?
<JackH> seriousy now?
<JackH> 7 figures?
<kanzure> uh...
<hearn> lol
<JackH> 50% now, 50% upon hard-fork?
davi has joined #bitcoin-wizards
<nsh> maybe it's time for a break :)
<gavinandresen> dgenr8: I've been told no patch for increasing the blocksize is acceptable for Core, Wladimir and Greg will just NACK no matter what.
<helo> by pushing forward based on popular polling, you are presenting the view that the opinions of the people disagreeing with you in here are not relevant
<nsh> gavinandresen, why is jgarzik proposing one then?
<kanzure> gavinandresen: i think it reflects poorly on everyone that we're leaving adam3us hanging
<nsh> is he naive?
<adam3us> gavinandresen: thats not accurate
<hearn> helo: hardly. look at how much we've written in response to every raised concern.
kyuupichan has quit [Remote host closed the connection]
<dgenr8> gavinandresen: so wha
<adam3us> gavinandresen: re-circling back to the discussion how about if you tell us what your conditions would be to participate in the bip review process and go with the winner of the process.
kyuupichan has joined #bitcoin-wizards
<gavinandresen> I'm happy to be wrong, and happy to submit a patch to Core
<helo> hearn: they've all read that stuff, and it has been inadequate (obviously)
<kanzure> we already knew you were planning a patch, but we were asking something else, gavinandresen
<adam3us> gavinandresen: i dont know who said that but they are wrong to the best of my knowledge
<dgenr8> gavinandresen: well it sends a message that you want it in core
<gavinandresen> adam3us: I'm happy to participate. I have no idea what "the winner of the process" means, though.
<kanzure> 07:09 < adam3us> gavinandresen: but it kind of makes a lie of the review process if one party is saying that they will overrule its outcome. i dont want to paint you wrongly as having said that. but clarification would really help just to clear the air and move forwards.
<kanzure> gavinandresen: you made a public threat, we're asking you for clarification still
<gavinandresen> public threat? I'm going to write some code and then make it available for people to run.
<gavinandresen> They can run it or not....
<hearn> this is a stupid channel
<kanzure> hahaha
<dgenr8> it's actually already available. some crazy person could run it right now
<adam3us> gavinandresen: i think you do. the same way as the other BIPs over the last years have been decided (with the exception of BIP16/17 which in hindsight didnt work out ideally though it is a marginal loss only)
<morcos> gavinandresen: a lot of very reasonable people think you are taking this too far. you want progress, progress has started. i'd even go so far to say as most people are resigned to accepting an increase in the blocksize before they think its actually appropriate in order to maintain consensus. but please let that process play out. waiting 3 weeks for review of your one implementation before you roll it out to people
<kanzure> gavinandresen: you specifically said you already have companies committed to it
<JackH> they are paid off
<kanzure> gavinandresen: that's a threat. to fork the network. do you see why?
<JackH> no reason to talk any longer
<nsh> kanzure, i'm sure you misread that anyone had committed to it
<nsh> as gavinandresen is being assiduous not to get endorsements of something that doesn't exist yet
<JackH> this is by far the easiest way to take out Bitcoin
<hearn> morcos: i'm planning on letting the patch bake for a bit publicly before we spin some binaries, no worries
<nsh> i can only assume
<nsh> i want to live in the world where i can assume that safely
<dgenr8> morcos: nobody would be paying any attention at all but for gavin's work and actions
* nsh nods
<nsh> there are no villains here
<morcos> if i go along with ACK'ing some proposal like jgarzik's at this point, i will feel coerced into doing it already at this point. but at least we'll all agree whether under pressure or not... if the momentum to do something dies down in a month or so, then no doubt you can pursue this path and not listen to entreaties to stop any more if you choose
<morcos> but i don't want to find out what happens when a substantial minority is left behind in a hard fork
<nsh> i do
<morcos> i think thats the danger of letting people pick which code to run
<nsh> i just want to find out without billions being lost
<dgenr8> morcos: with a flag day a year in the future, nothing is final upon release of some software product
<nsh> because simulating systems is tractable, undoing history isn't
<hearn> i don't think there's much chance of that. they'd have to choose to be left behind, or somehow be so disconnected from the bitcoin community and their own node logs AND -alertnotify etc, that they had no idea it was coming
<hearn> in which case their node is on autopilot anyway
<gavinandresen> Again, I think it is irresponsible not to plan for scaling up NOW. Reasonable people can disagree about that, but that's my strong feeling.
<kanzure> i think that in general you should assume the best in people, but in cases where safety is critical it is bad to assume the best, instead we should proceed with caution
<kanzure> gavinandresen: i think you should answer the exact question :-(
<gavinandresen> kanzure: what exact question?
<helo> when is the "upgrade to bitcoin XT!" alert going out?
<hearn> helo: i think Core already prints messages saying "Upgrade now" when it notices new block versions it doesn't know about
<kanzure> gavinandresen: are you going to campaign companies to run the hard fork even in the presence of nacks?
<hearn> helo: so that'd depend on miner adoption. at least that's my vague recollection of how the code works.
<kanzure> and even in the presence of limited miner adoption
<JackH> gavinandresen: you are not giving people a choice to upgrade . you are forcing them to upgrade by contacting them one by one and telling them what to do
<adam3us> gavinandresen: that is not what the vast majority of people are saying. it seems like most will support something in the ballpark of jgarik's with minor differences or something like it with those differences applied.
<gavinandresen> kanzure: yes, I will encourage companies to announce that they are "big block ready" by running code that will accept bigger blocks. If consensus emerges for some variant of how big / when / etc then I'll encourage them to run THAT code.
<helo> JackH: that still is a choice, as he's not in a position to fine them or anything
www has joined #bitcoin-wizards
<adam3us> gavinandresen: consider: if we proceed like this people will be working in haste, in a distressed state of mind, and it is more likely that a mistake will be made.
<JackH> helo: he is using his star status to do it. the choice is not: "select A or B"
<kanzure> welp there's our answer folks
<JackH> helo: he is telling them what the best choice according to himself is, that is a huge difference
<JackH> again, having seen all this chat today, I no longer believe Hearn nor Gavin are having any intention of keeping Bitcoin going. They are either paid off or something else is happening
<adam3us> gavinandresen: i gave you an example of that in PM why this affects people. some people do not react well to stress.
<helo> JackH: again, rise above the conspiracy theories
* nsh nods
<morcos> JackH: thats obviously not the case, but I think they place different priorities on what's most important for the health of bitcoin
<hearn> JackH: lol, you're hilarious. "you are forcing people by talking to them"
<kanzure> helo: at what size of the bitcoin network do you think it would be prudent to watch out for conspiracies?
<JackH> helo: and they should rise above the craziness or pushing 20x the amount of data through nodes
* dgenr8 plans to go mine a hard fork, just for enlightenment. i can finally experience the thrill of mining bitcoin-ish
<helo> what you mention is possible, but not meaningfully actionable to any extent because there is no evidence
<kanzure> hearn: pretending to be an authority can be very damaging
<kanzure> hearn: companies are used to the authority model. it makes sense to them.
<JackH> hearn: if you think people dont implicitly trust you more than some random dude, you dont understand stardom. People will naturally listen to "core-devs" more. It is maybe wrong to say forced, but its definitely coerced
<helo> "convinced"
<hearn> it's quite debateable whether i'm a "core dev" or not. i've never much liked that label. it's about as well defined as the term "developer consensus"
<nsh> consent i'm sure will be giving willingly; informed-consent cannot be given by all
<hearn> if people listen to me or gavin, it's only because they think what we say makes sense.
<hearn> it's not like we have some kind of mind control rays
<kanzure> that sounds pretty close to "the development model doesn't match other systems or networks, therefore it must be wrong"
<JackH> hearn: if you had the best intentions, you would give people a choice without contacting them personally. You did not, thus we can assume you have another agenda
<hearn> rest assured, we have not and cannot contact everyone personally
<kanzure> hearn: you really think that the only reason that people listen to gavinandresen is because he makes sense? really?
<kanzure> you don't think that anyone, will ever make the mistake of trusting gavinandresen for reasons other than sensemaking?
<nsh> hearn, you can't discount that people must, by definition, but some degree of blind trust in the recommendations of developers
<nsh> because no-one can understand all the code
<JackH> I must however give it to you. You are admirable in your struggle to get everyone to switch to XT. Most people would have given up by now.
zooko has joined #bitcoin-wizards
<JackH> We had this conversation for what, 2 months now, reddit, bitcointalk, here in multiple channels, on sourceforge etc
<helo> i prefer the anti-occam theory that their contentious hard fork announcement is what they thought was the best way to get everyone riled up and tackling the scalability problem in earnest
* nsh nods
<helo> because in any case, that is what it is doing
<nsh> but, as said, it could transition from useful to counter-productive as people's anxieties rises
<nsh> *rise
<nsh> and we are trying to avoid that by making it seem less of a threat than a way to spur a multilateral process
<nsh> and that doesn't seem like much of a rhetorical compromise to be honest
<wallet42> hear: can xt nodes be pruned while still supporting getutxos?
<helo> the process has kicked off now, so yes... now would be a perfect time to back down and see what the process comes up with
<nsh> or soften the phrasing
<nsh> diplomatic words go a long way and cost little
<helo> WOTD
<helo> Q
<kanzure> the alternative is an immune response of massive proportions i think
<kanzure> alternatives (like in the presence of no disarming) should be better considered
<sturles> JackH: What is the point of switching to XT, except for the HD wallet features? I haven't seen the discussions you refer to.
<kanzure> i believe adam3us mentioned an interesting strategy of soft-forking the network ahead of a contentious partial hard-fork
<JackH> strules: there is no point of switching to XT at all
nessence has joined #bitcoin-wizards
<JackH> XT is build to centralize Bitcoin in the hands of few people by killing off nodes
<sturles> Hmm, yes. It relays and highlights double spends. That's a feature.
cosmo has joined #bitcoin-wizards
<sturles> Huh? In which way does Bitcoin XT centralize anything?
damethos has quit [Remote host closed the connection]
<JackH> sturles: go ahead and download 20mb every 10 min. Let me know how it works for you relaying that at the same time
<kanzure> (also, communication is a form of mind control; it's how you control the perceptions of others and communicate or relay information. audio and vocal communication uses mechanical vibrations that are often emitted from other forms of rays.)
<kanzure> ((perhaps my favorite is ultrasound rays))
<sturles> JackH: You are talking in riddles. Bitcoin XT doesn't download 20 MB every minute.
zooko` has joined #bitcoin-wizards
<JackH> not yet
<JackH> it is supposed to
<adam3us> kanzure: i didnt put much thought into it but it might be possible yes.
<JackH> basically its a "patch" that is supposed to knock out nodes in the network
<JackH> it will then be cheap to ringfence the rest of the network with malicious nodes and serve crap data
<JackH> and then its bye bye Bitcoin
nessence has quit [Ping timeout: 250 seconds]
instagibbs has quit [Quit: Page closed]
<gavinandresen> JackH: I thought I just said the patch I was working on is 8MB.......
<sturles> JackH: Ah, you haven't grasped the basic concepts of bitcoin yet, it seems. Sure you didn't mean to be in #bitcoin-clueless?
<GAit> hearn: you and Gavin have been the most public media friendly developers around Bitcoin, people aren't following you because you are right but because you are more famous. gavinandresen, you should follow the consensus process with the BIP, not threaten to hard fork if things don't go your way oki doki
<JackH> gavinandresen: if that is the case then we are all the sudden aligned in what we want
zooko has quit [Ping timeout: 264 seconds]
<JackH> if you work on some of jgarzik proposals then I think it is a completely different situation
<JackH> if we get the chance to review the code, and not having it stuffed on us, and it sounds feasible in terms of increasing the block size, well then that is a completely different talk
<sturles> JackH: Bitcoin XT doesn't even support 20 MB blocks, and what you write now is the opposite of what the devopers wite here, so I don't get it. What is your _real_ problem with Bitcoin XT?
<JackH> and if its a BIP, that would be even better ;)
<kanzure> sturles: nobody cares that there is another patch set out there, really. nobody has ever brought that up as a problem.
<sturles> For a merchant the double spend detection feature is a good one.
<GAit> gavinandresen: I think is important to bring things back to collaborative state, no forced hard forking
<hearn> there will be a chance to review the code and comment on it before it's merged into XT, there will be a BIP and it's very likely that patch+bip will be for 8mb+stuff, which is, i think, what has been said all along.
<sturles> kanzure: What patch set?
<kanzure> sturles: xt is a patch set....
<GAit> hearn: the problem is your going ahead regardless of NACK
<kanzure> GAit: no, it's convincing companies regardless of NACKs
<adam3us> so here's a thought what if jgarzik and gavinandresen pooled BIPs.
justanotheruser has joined #bitcoin-wizards
<adam3us> they seem moderately similar and gavinandresen seemed reasonably ok with jgarzik's current parameters.
GAit has left #bitcoin-wizards [#bitcoin-wizards]
<adam3us> combined them.
GAit has joined #bitcoin-wizards
<adam3us> make BIP 102 out of 100+101
<JackH> Gavin and Hearn, I think you may also misunderstand people here. What we dont want is fragmentation and the possibility of the network effort to diminish in any way.
<GAit> adam3us: that would be great, collaboration between jeff and gavinandresen but is important gavinandresen calls off the contentious no matter what hard fork in XT, I am not sure Mike is prepared to support problems when they inevitably arise
darwin__ has quit [Read error: Connection reset by peer]
<GAit> fragmenting a blockchain is much worse than fragmenting an open source project
<JackH> And by network effort, I mean, risking miner amounts and node amounts
<helo> back in P2SH days, there was some dissent (luke). the majority of the devs discussed and decided on a particular approach, and the minority dissenting devs aquiesced.
<adam3us> helo: exactly.
<kanzure> GAit: unfortunately they have both demonstrated an inability to understand "forking an opne-source repository" and "forking a blockchain using a contentious hard-fork".
<helo> luke never went on a big PR campaign to convince the ignorant masses and force a change that most developers disagreed with, although he could have
darwin_ has joined #bitcoin-wizards
<kanzure> helo: i believe there were some differences there like limitations on the damage that could be caused or something, so the others were okay because of that reason
<kanzure> (not entirely sure i remember the details correctly?)
nwilcox has joined #bitcoin-wizards
<kanzure> GAit: whoops i mean that the two things i quoted are different topics
<GAit> kanzure: here's hoping that people can come to a more collaborative approach. gavinandresen is declaring "WAR" to bitcoin core if he goes ahead with his contentious hard fork
<kanzure> GAit: right; and it's not related to forking the open-source project. it's related to campaigning companies to run a contentious hard-fork.
<adam3us> kanzure: "forking an opne-source repository" and"forking a blockchain using a contentious hard-fork". no i think thats not accurate. gavin said in answer to this kind of question on panel discussion etc that in his view others would see the trend line and follow it.
<kanzure> adam3us: please continue/elaborate
zooko` is now known as zooko
<adam3us> the point is more that we should strive for minimum dissent as it is the fact that people are upset and feel overruled or that th ebest proposal might not win that they would go propose alternatiave and also lobbyg companies or make soft-forks to break the hard-fork in flight.
cosmo has quit [Remote host closed the connection]
<kanzure> for example, are you saying that he thinks that the companies he campaigns to are going to see the trend of the other companies following, therefore they will adopt the hard-fork and the rest of the network wont?
<adam3us> we minimise that if we get into a constructive mode of working in development
<kanzure> i agree that constructive mode minimizes that
<adam3us> (not to put words into gavinandresen mouth) but i understood from what was he thinks that game-theory wise its too much of a loss that everyone would get on the same page or risk armageddon.
<kanzure> right, that's what makes it a nuclear threat
<adam3us> which is why i characterised it as a game of chicken.
<kanzure> indeed.....
<hearn> a vote is not a "nuclear threat".
<kanzure> it's not a vote
<adam3us> kanzure: yes its a risk calculus something kind of like the risk of mutual assured destruction. some is expected to back down
<GAit> hearn: this is not a vote
<Eliel> GAit: I think it's unfair to call XT a "contentious no matter what hard fork". It's not "no matter what" since there's the 75% threshold that's required for an actual chain fork to happen.
<GAit> Eliel: what thereshold, the block version and some two weeks grace period? miners can game that all they want
<kanzure> Eliel: xt is not a contentious hard-fork. that's wrong.
<Mably> just wondering: aren't the miners the ones who decide at the end?
<kanzure> Eliel: xt is a fork of an open-source repository. it's unrelated to what we're talking about.
<kanzure> it is wrong to characterize forks of an open-source repository as causing a contentious hard-fork
<GAit> Eliel: the problem is that gavinandresen and hearn are threatening the security of the blockchain by going by hard forking without any technical consensus from the people most familiar with the details and with the people that contributed the most, is that not enough?
<kanzure> anyone can generate an unlimited quantity of open-source repository forks
<kanzure> without damaging the network
<GAit> running XT with 20MB patches is a contentious hard fork
<Eliel> kanzure: I'm quite aware of what the difference is in forking a repository and forking the blockchain. Thank you very much.
<kanzure> Eliel: alright
wallet42 has quit [Quit: Leaving.]
<Mably> Won't you have to convince more than 50% of the mining power to run XT for the hard fork to succeed?
<kanzure> what do you mean by "succeed"?
<Mably> longuest chain
<Eliel> Mably: over 75% is what the code will require before it even makes an attempt.
<Mably> Ah ok
<kanzure> there's ways around that, like hardcoded checkpoints (someone threatened this recently) (adam3us might remember who?)
<hearn> GAit: for what it's worth i have been around longer and written vastly more code than any of {adam,gregory,peter todd,etc}. that code included a reimplementation of bitcoin in another language. so, i rather think we are quite familiar with the details and are amongst those who are contributed the most.
<kanzure> what are you replying to
<kanzure> as far as i can tell that does not answer any question GAit has ever asked you
Quanttek has joined #bitcoin-wizards
SDCDev has quit [Ping timeout: 276 seconds]
<Mably> Eliel: could you explain your 75%?
<hearn> his message to eliel
<kanzure> looking
<GAit> hearn: writing an SPV library is quite different from core work, you are not the first nor only one
<GAit> hearn: but again, irrelevant to the current discussion, which is going ahead with nuclear threats
<kanzure> yeah, i don't think your response to GAit's message to Eliel makes any sense.
<adam3us> kanzure: must've been someone else i dont remember hardcoded checkpoint. i think. could be misunderstanding what you mean
<kanzure> okay, yeah nevermind
<kanzure> i'll drop it since i can't cite it
<hearn> GAit: bitcoinj also has code to do full verification in it
<hearn> GAit: but the SPV mode is the focus, indeed.
<hearn> GAit: regardless, i was the first actually
<helo> direct democracy on a global scale is probably one of the worst approaches to deciding anything
<hearn> GAit: so you have said several things now that just aren't correct. and by the way, i've done work on Core too. for instance i proposed and then implemented support for leveldb
<GAit> hearn: is this an ego problem? you are good enough but your proposal are scary and risky, we can work on them with consensus, why threatening the others?
<hearn> along with designing BIP70, proposing and working on the design for Bloom filtering, etc
<adam3us> kanzure: but it seems plausible that someone so minded could harden existing code to against in-flight hard-fork in various ways. i don thtink anyone put a lot of thought into it.
<hearn> anyway, my point is, your comment about "without consensus by those most familiar with the details and the people that contributed the most" is really not that accurate nor helpful
<helo> hearn: my grandma's vote on what codebase to run is absolutely worthless
<GAit> hearn: i didn't mean to minimize your contributions to non consensus code but this area you are touching now is dangerous (and there have been problems with the leveldb migration if im not mistaken)
<hearn> no
<helo> popular vote is a terrible way to decide policy
<gavinandresen> GAit: Mike wrote the first draft of the BIP that is the March 15 fork post-mortem....
<kanzure> it's not really even policy
<kanzure> it's wrong to misconstrue this as policy
<hearn> GAit: as a refresher, BDB had design problems in it that made it hopelessly unsuitable for consensus work. Satoshi did not know that, and nor did we until the network spontaneously forked.
<adam3us> GAit: i think its not correct to blame mike for the leveldb.. he checked it in but others changed much afterwards, no one saw it coming.
<hearn> GAit: specifically, BDB could get itself into a position where two nodes, given the same inputs, could arrive at different decisions about a block!
<kanzure> so are you trying to say that "because we have written bips in the past, companies should be safe listneing to us for all time in the future"?
<hearn> GAit: LevelDB is a vastly better codebase and did not suffer such problems. good thing i proposed we use it, no?
<GAit> adam3us: I don't think I blamed him, I am suggesting that consensus related changes are dangerous
<adam3us> GAit: fair enough. and this is a very relevant point right now.
<GAit> nowhere in my phrasing i suggested Mike is at fault for it
<gavinandresen> I'll say it: not all developers have experience scaling up systems. I listen much harder to those who do.
<hearn> GAit: as LevelDB improved consensus robustness quite dramatically. unfortunately, bdb exploded before the LevelDB rollout was complete
nessence has joined #bitcoin-wizards
<gwillen> kanzure: here's the message where mike threatened hardcoded checkpoints to fork off 50+% of chinese miners: http://sourceforge.net/p/bitcoin/mailman/message/34162353/
<GAit> gavinandresen: i doesn't seem like you are listening at all to the rest of the core team
<GAit> hearn: details, the point is that consensus changes are dangerous, stop thinking everyone is here to bite you or stop getting your *ego* in the way
<zooko> Hi, gwillen!
<gwillen> zooko: \o
<hearn> sigh. GAit, I am answering your concerns. you have said several times that gavinandresen and myself are ignoring experts who understand the details. when i told you about our own expertise, suddenly we're guilty of being all about ego.
<hearn> there is no way to satisfy you, i think
<zooko> hearn: In my opinion, you could just stop replying to GAit on this channel, at least for now, and nothing bad would happen.
<hearn> yeah, i'm getting rather tired of it myself.
SDCDev has joined #bitcoin-wizards
<zooko> No offense, GAit, but while I sympathize with your concerns, I don't think your current comments are helping.
<gavinandresen> GAit: so... some of the core team was pretty busy with their own projects, and there was no feedback to listen to. I am ALWAYS happy to listen. I reserve the right to disagree....
<kanzure> there was lots of feedback; look at the timestamps
<kanzure> they were doing sidechain last minute work plus also commenting everywhere
<kanzure> there were volumes of text written on reddit, for example
<GAit> forget one second about the block size increase, you are underestimating the dangers of hard forks without consensus, I don't get why we don't put that option away from the table
<temujin> just fork the network already so i can buy $70 coins again and profit off the recovery
<GAit> it's like having a guy with the gun pointed at you, it makes everything more stressful
nessence has quit [Ping timeout: 255 seconds]
<zooko> GAit: I'm sorry you're feeling high anxiety. That makes it hard to do good work.
<GAit> you were quite quick to attack my qualitative assessment of contributions to core but very slow [read never] to answer about putting down the nuclear option
<moa> i'd rather listen to the people who actually making commits and technical contributions than al the part-timers who use threats and drama
<Eliel> gwillen: it's unfair to characterize that message as a (personal) threat. It's a potential scenario that's not completely impossible, that might happen regardless of whether mike does anything to push things that way or not.
<adam3us> moa: i get the concern. but we should acknowledge that gavinandresen wrote a ton of the code (if you look at github stats) etc.
<helo> gavinandresen: disagree as much as you want, but you should do what excellent bitcoin developers in the past have done, and ultimately go along with developer consensus. please, can't you publicly withdraw your contentious hardfork threat?
<GAit> gavinandresen: i also ask to please withdraw the contentious hardfork threat
<helo> your view deserves its equal consideration, and will get it
<helo> your proposal does not deserve to overcome the others based on your own popularity
nessence has joined #bitcoin-wizards
moa has quit [Quit: Leaving.]
<helo> which is what a public vote (or patched bitcoin xt release) would be.
<zooko> FWIW, I think adam3us's email has unnecessarily alarmed you, and that you are not actually in dire danger and you do not actually need to urgently plead and persuade someone else to do something or not-do-something in order to save yourself.
<Eliel> GAit: even if gavin withdraws this so called "threat", people are still liable to jump ship to an altcoin that is able to scale if nothing happens in Bitcoin Core.
<GAit> Eliel: one would think that if the alt is scalable people would notice and update bitcoin long before the alt takes over
<kanzure> zooko: there was an actual threat email, you know. this was before adam3us' email.
<GAit> or if the alt is better and bitcoin can't be fixed, i say so be it
<Eliel> GAit: yep, and that situation is almost exactly the same. The only difference is the name of the altcoin.
<GAit> zooko: the danger is very real, people failing to see dangers in contentious hard fork != no danger
cosmo has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 265 seconds]
wallet42 has joined #bitcoin-wizards
zooko` has joined #bitcoin-wizards
<kanzure> zooko: specifically there was mention of campaigning to companies to run a hard-fork patchset that had received nacks.... this was sent before adam3us' email.
nessence has quit [Ping timeout: 264 seconds]
<Eliel> GAit: the point I'm making is that it'd only be a false sense of security that resulted if gavin withdrew his plan.
zooko has quit [Disconnected by services]
zooko` is now known as zooko
lnsybrd has joined #bitcoin-wizards
<Eliel> If gavin and hearn don't go through with Bitcoin XT plans, the most likely scenario is more fragmentation of the community than with it.
<zooko> kanzure: I am aware.
<Eliel> (assuming of course, that bitcoin core doesn't get anything done in regards to scaling implementation)
<kanzure> zooko: alright
<adam3us> back in a bit. getting hungry
jtimon has joined #bitcoin-wizards
<Eliel> From my point of view, Bitcoin XT hard fork is a necessary plan B. Plan A being that Bitcoin Core implements something that solves the issue.
<gavinandresen> helo: I already said I'm happy to go along with developer consensus, if such a consensus emerges. But I am not happy to sit on my hands and do nothing in case there is no clear consensus, doing that would, in my humble opinion, be irresponsible.
<gavinandresen> ... and now I'm going to go back to writing regression tests....
<helo> o/
<GAit> gavinandresen: are you taking responsability for any loss caused by the fork?
<kanzure> what
<GAit> saying if consensus emerges otherwise i will do X is akin to say that you don't consider a possibility where status quo + plan is consensus
instagibbs has joined #bitcoin-wizards
<gavinandresen> GAit: nope, if you are an idiot and refuse to upgrade when your software tells you it is time to upgrade then I have no sympathy.
<zooko> gavinandresen: Write good regression tests!
<GAit> what makes you think that core won't also upgrade the block version and cut off connectivity to XT?
<GAit> to even higher so that XT will tell you upgraden and you'd be an idiot not to
<gavinandresen> GAit: I think Wladimir would NACK that.
<GAit> in a situatuon where you need to protect the network and it requires a small change without soft or hard fork I'd say people may consider such things, node operators and miners could do such thing without asking Wlad
<GAit> it's quite simple to recognize XT with its getutxo, you'd have to make it look as much as possible to core
<GAit> it's a war
<GAit> which nobody wants
nessence has joined #bitcoin-wizards
<gavinandresen> gotta ignore everybody now and write some code.....
<GAit> which could cause a fork of XT miners earlier than real threshold
<Eliel> GAit: treating it like a war will only serve to make things worse.
<GAit> gavinandresen: you shouldn't ignore security concerns about contentious hard forks, i'm sorry, you are being unresonable
<GAit> Eliel: people won't sit waiting for Gavin to destroy things
priidu has joined #bitcoin-wizards
instagibbs has quit [Client Quit]
blackwraith has joined #bitcoin-wizards
<GAit> not that he wants to but it's one of the possible outcomes
blackwraith has quit [Client Quit]
eennaam has joined #bitcoin-wizards
<Eliel> GAit: things blowing up is a possible outcome even if gavin does nothing. More likely in that case I think.
<GAit> Eliel: consensus disagrees, but good attempt
nessence has quit [Ping timeout: 246 seconds]
jgarzik has quit [Quit: This computer has gone to sleep]
melvster1 has joined #bitcoin-wizards
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence_ has joined #bitcoin-wizards
nessence_ has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
badmofo has quit [Remote host closed the connection]
badmofo has joined #bitcoin-wizards
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
nessence has joined #bitcoin-wizards
jae has joined #bitcoin-wizards
jae is now known as Guest31906
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
<richardus> mr. gavin please be sure to use your key to advertise bitcoin xt
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
wallet42 has quit [Quit: Leaving.]
wallet42 has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 255 seconds]
<wallet42> gavinandresen, sorry one more question: will I be able to run a pruned XT node which supports getutxos?
badmofo has quit [Quit: Leaving]
Guest31906 has quit [Remote host closed the connection]
Quanttek has quit [Remote host closed the connection]
nessence has joined #bitcoin-wizards
badmofo has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence_ has joined #bitcoin-wizards
nessence_ has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nwilcox has quit [Ping timeout: 244 seconds]
nessence has quit [Ping timeout: 264 seconds]
eudoxia has quit [Ping timeout: 256 seconds]
nwilcox has joined #bitcoin-wizards
dc17523be3 has quit [Ping timeout: 265 seconds]
JackH has quit [Ping timeout: 250 seconds]
c0rw|away is now known as c0rw1n
dc17523be3 has joined #bitcoin-wizards
hearn has joined #bitcoin-wizards
_biO__ has joined #bitcoin-wizards
dc17523be3 has quit [Ping timeout: 246 seconds]
hearn_ has joined #bitcoin-wizards
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
hearn has quit [Ping timeout: 256 seconds]
hearn_ has quit [Read error: Connection reset by peer]
chmod755 has quit [Quit: Leaving]
hearn has joined #bitcoin-wizards
Mably has quit [Quit: Page closed]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
_biO_ has quit [Remote host closed the connection]
_biO__ is now known as _biO_
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nwilcox has quit [Ping timeout: 256 seconds]
nessence has joined #bitcoin-wizards
melvster1 has quit [Remote host closed the connection]
nwilcox has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
mjerr has joined #bitcoin-wizards
nessence has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence has joined #bitcoin-wizards
jtimon has quit [Ping timeout: 265 seconds]
nessence has quit [Read error: Connection reset by peer]
paveljanik has joined #bitcoin-wizards
nessence has joined #bitcoin-wizards
dc17523be3 has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
dc17523be3 has quit [Ping timeout: 256 seconds]
dc17523be3 has joined #bitcoin-wizards
hearn_ has joined #bitcoin-wizards
hearn has quit [Ping timeout: 252 seconds]
Quanttek has joined #bitcoin-wizards
Mably has joined #bitcoin-wizards
zooko` has joined #bitcoin-wizards
zooko has quit [Disconnected by services]
zooko` is now known as zooko
hearn_ has quit [Read error: Connection reset by peer]
antanst has joined #bitcoin-wizards
hearn has joined #bitcoin-wizards
Quanttek has quit [Remote host closed the connection]
Quanttek has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
c-cex-yuriy has joined #bitcoin-wizards
jgarzik has joined #bitcoin-wizards
zooko` has joined #bitcoin-wizards
zooko has quit [Ping timeout: 252 seconds]
zooko` is now known as zooko
Burrito has joined #bitcoin-wizards
hearn has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<hulkhogan_> that was quite a read...
<hulkhogan_> gmaxwell: earlier, were you speaking of a mixnet for bitcoin transactions? imo it would be easy to hack up in python with some hardcoded nodes, possibly with p2p/discovery to find other mixers ... simple design might be too simple, though
<gmaxwell> hulkhogan_: should be super easy.
<hulkhogan_> gmaxwell: awesome, appreciate that, i think i have time to fiddle on it a bit today actually... will update if something fruitful is produced.
<kanzure> wouldn't it need to be sybil resistant?
<hulkhogan_> kanzure: yea... this is one of the things i didn't think about wrt simple design, i think so /but/ there might be some encryption tricks that make snooping on relayed transactions harder
<hulkhogan_> i was planning on reading the mixmaster papers a bit to see how they figured that stuff out.
antanst has left #bitcoin-wizards [#bitcoin-wizards]
<gmaxwell> if it's hardcoded its inherently sybil resistant.
<kanzure> well i'm sure it's at minimum the usual tricks: increase the size and diversity of your anonymity set, increase your tolerance for ridiculously long delays, etc.
<gmaxwell> My recommendation would be to make the network itself only reachable over tor. Therefor the lower bound on privacy is that which is provided by tor.
<kanzure> (if using tor correctly)
<hulkhogan_> well, and this is off the deep end because i havent done any reading-- what if you encrypted the transactions up until the last hop/hardcoded node?
<hulkhogan_> that might preserve privacy, but the first daemon/server you pinged might also ID you, so yes tor support should be baked in
<gmaxwell> hulkhogan_: thats what a mixmaster like system would do, an unfortunate issue there is that you can't then use the validity of the transaction as your anti-dos token.
<kanzure> i agree that hardcoding is a nice solution, and it doesn't seem particularly dangerous here
<hulkhogan_> gmaxwell: you might have trusted entry nodes that validate + encrypt, but thats a pretty bad idea, wrt privacy
<gmaxwell> which isn't the end of the world or anything.
<kanzure> well, the privacy alternative is much worse actually
<gmaxwell> hulkhogan_: that kinda moots the encryption part, might as well have a one hop network then.
<kanzure> so trusting some random group of people is an additional option that is presently unavailable in other schemes
<kanzure> er, i'm sure there's a better way for me to word that
<hulkhogan_> let me think some more... very unbaked thoughts
<gmaxwell> and a one hop network wouldn't be a bad starting point. e.g. single server, you reach over tor. You send it 64KB every 5 minutes... either a real transaction, if you have one, or a randomly selected new mempool txn, or nothing. then according to parameters set with the transaction it randomly dequeues into the network.
<hulkhogan_> well, what if the last node was the node you encrypt to- that way you decrypt + verify at the last hop?
<hulkhogan_> hmm
<hulkhogan_> could you explain some of those params, 64KB, 5minutes, i'm not completely following there
arubi_ has joined #bitcoin-wizards
<hulkhogan_> also, is this something that needs to be set behind a hidden service? i feel there might be a simpler way to accomplish the goal ... the simple case, basically
<kanzure> 5 minutes is probably for the delay attribute
zooko` has joined #bitcoin-wizards
<kanzure> otherwise if you send everything as fast as possible there's timing attacks and correlations that are much easier
<hulkhogan_> yea, bulk sends etc
<hulkhogan_> right, if possible i'd like to keep tor support as a feature for later
<hulkhogan_> (lots of gotchas)
www has quit [Ping timeout: 250 seconds]
zooko has quit [Ping timeout: 246 seconds]
<hulkhogan_> here's the easy case: run a daemon that accepts tx's from other daemons, that eventually forwards it to a hardcoded node that sends it on the network
Emcy has quit [Ping timeout: 256 seconds]
<hulkhogan_> so p2p-bitcoin-tx-submission-as-a-p2p-service... privacy guarantees are hard to say with the scheme, but tor support would be a plus
<hulkhogan_> heh, thanks kanzure, i'll cache those for later reading :)
zooko` is now known as zooko
nessence has joined #bitcoin-wizards
<hulkhogan_> also, wrt sybil: you can just create arbitrary entry critera (like uptime, pow) to limit that
<hulkhogan_> think uptime is used for tor guard nodes, so something along those lines
nessence has quit [Ping timeout: 244 seconds]
<gmaxwell> hulkhogan_: tor has a centeralized trust model, makes many thing easier!
<hulkhogan_> yeah, and for this project it makes sense to keep the trust within a few known params (hardcoded) (at least, initally, to get started..)
<hulkhogan_> but i think its a good effort, having a p2p-like system to submit txes is useful.. some block explorers expose this... indeed it can be useful for masking the originating node/IP (if you use a VPN) and a more robust/accessible soln would be useful..
JackH has joined #bitcoin-wizards
droark has joined #bitcoin-wizards
CoinMuncher has quit [Quit: Leaving.]
SubCreative has joined #bitcoin-wizards
SubCreative has joined #bitcoin-wizards
droark has quit [Quit: Later.]
nessence has joined #bitcoin-wizards
priidu has quit [Ping timeout: 255 seconds]
<nickler> is the purpose of this network to hide the origin of a transaction from the network peers?
nwilcox has quit [Ping timeout: 276 seconds]
<gmaxwell> nickler: correct.
nwilcox has joined #bitcoin-wizards
<gmaxwell> nickler: there is existing functionality in bitcoin core (0.11+) to not relay transactions created by the local wallet, which allows some rpc-speaking daemon to go handle it for you 'somehow'.
<kanzure> does it continue to not relay beyond a restart?
ThomasV has quit [Ping timeout: 256 seconds]
<gmaxwell> yes. until you switch the option back, unless there is some bug.
<nickler> I just want to remark that according to my calculations, 'trickling' does a surprisingly good job. Assume an attacker is connected to all peers of node A and we assume a reasonably small prior probability that the tx originated from A.
<nickler> So if an attacker first gets the transaction from A the posterior is still negligible.
<nickler> Trickling doesn't help of course when the attacker is connected to all nodes, as this University of Luxemburg paper showed
gill3s has joined #bitcoin-wizards
<nickler> The paper 'Deanonymisation of clients in Bitcoin P2P network' by biryukov et al.
darwin_ has quit []
<gmaxwell> nickler: yes, but it creates incentives to sybil attack the network, which we've seen commercial entities doing. :(
<gmaxwell> nickler: the trickling also loses its effectiveness fairly quickly when transactions are repeated.
rubensayshi has quit [Remote host closed the connection]
<nickler> ok, just wanted to learn the purpose of the mixnet
<gmaxwell> ::nods::
<nickler> you mean repeated broadcasting
<nickler> ?
Xh1pher has quit [Read error: Connection reset by peer]
<gmaxwell> nickler: actually no, I meant when a single party transacts many times (with linkable transactions). But it also applies to rebroadcast if the transaction doesn't confirm.
<nickler> yeah linkable transactions would really degrade trickling
<gmaxwell> nickler: right, and people will make small payments to old addresses to increase linkability.
<nickler> speaking of that, are there already ideas how to get unlinkability onto a sidechain? :D
AaronvanW has quit [Remote host closed the connection]
<zooko> speaking of that, here's a new blog post, fresh from the oven:
<gmaxwell> nickler: what kind of unliability? (like do you mean make the transaction to the sidechain unlinkable? or unlinkable transactions on the sidechain?)
<nickler> gmaxwell: the latter
<gmaxwell> nickler: step 1. take your particular scheme, step 2. put in sidechain? :P dunno if you saw, elements/alpha has a kind of privacy scheme. By itself it doesn't create transaction unlinkability, but it can be combined with coinjoin and/or coinswap. It's certantly not the only way to do improved privacy/fungibility, see zooko's link. :)
Emcy has joined #bitcoin-wizards
<nickler> gmaxwell: could something like monero style ringsigs be reasonably implemented in bitcoin?
<gmaxwell> Sure, though I think CT+CJ is strictly superior.
<gmaxwell> (to the bytecoin/monero approach)
<gmaxwell> though there are a number of ways to improve that approach, e.g. the combination with OWAS is really nice. I haven't come up with a way to combine CT with it though; adam has tried some without success.
<gmaxwell> (I mean to do so while staying in the realm of boring cryptography, ZC is strictly superior from a privacy perspective)
<nickler> gmaxwell: ah thanks a lot. Last remark for today: you seemed to be very ambitious to make your confidential tx writeup understandable for the layman. I personally drop out at (In1 + In2 + In3 + plaintext_input_amount*H...) - (Out1 + Out2 + Out3 + ... fees*H) == 0.
<nickler> Would have rather expected to find a xG somewhere and (In1 + In2 + In3 + plaintext_input_amount)*H
davi has quit [Ping timeout: 265 seconds]
<gmaxwell> nickler: ah. well the values themselves are In1 = blind G + value H hm. not sure how to make that clear, perhaps expand it out.
<nickler> ok that would make sense :D
<fluffypony> zooko: Table 1 is incorrect - Monero (and I think CryptoNote coins) mask the amount, unless you have a magic way of telling which outputs are change outputs
<zooko> fluffypony: Hm... :-/
<gmaxwell> fluffypony: I don't think that change uncertant really is enough to qualify there.
<gmaxwell> (I'd missed that the table mentioned cryptonote)
<fluffypony> fair enough
<nickler> what's OWAS?
<kanzure> one-way aggregate signatures
<nickler> thx
<gmaxwell> nickler: one way aggreatble signatures. Clever trick using aggregate signatures to get you something that works like a whole block level coinjoin which is non-interactive.
<kanzure> i was thinking of aggregate signatures for a multisig or coinjoin style payment channel approach, but didn't hash out the details yet
<kanzure> (where i could possibly use those funky history-free aggregate signatures to remove intermediate history)
<nickler> is there a bitcointalk thread about that?
<gmaxwell> for a while, for the privacy feature for elements/alpha I'd wanted to do monero RS + OWAS, but then the prospect of reduced sized range proofs started looking pretty attractive instead.
<nickler> ah perfect
<kanzure> i think you could remove intermediate history if you could communicate with the original transaction signer to sign a different transaction instead
cluckj has joined #bitcoin-wizards
<gmaxwell> kanzure: well that sounds like the coinswap transform.
<kanzure> i want something like "bob sends 10,000 transactions to 10k hapless users, then each user sends 1k transactions to 1k other hapless users, and then bob's software rewrites his transactions so that the 1k transactions at the end are the only ones that get committed to the blockchain"
<kanzure> (or whatever the numbers work out to)
<nsh> loss of information is sufficient [just harder to guarantee]. equivocal histories requires more interaction
<gmaxwell> coinswap works by applying a general transformation to an atomic cross chain swap. The general transformation makes any two party contract indistinguishable from a 2 of 2 multisig (assuming the players cooperate).
<gmaxwell> (and where schnorr signatures are available, 2 of 2 easily looks just like 1 of 1)
DougieBot5000 has joined #bitcoin-wizards
<nsh> 'The notion of compressing all the signatures in a block into a constant size output is very attractive, even if it retains a linear validation cost. The improvement of anonymity could be viewed as a side benefit.' # how is this done in the OWAS proposal?
<nsh> (the pdf link is 404)
<gmaxwell> nsh: the BLS signatures just have this property where you can aggregate them.
<nsh> (A Survey of Two Signature Aggregation Techniques, Boneh, et al.)
<nsh> oh, i see
<gmaxwell> Boneh tells me there is a way to do an efficient batch verification but I didn't see how to make it work with the aggregation (haven't tried to hard). One of the bigger costs in that system (beyond needing the bilinear strong assumption) is that it needs two pairing operations per transaction to verify. If those could be batched out it would be nice.
* nsh nods
paveljanik has quit [Read error: No route to host]
pavel_ has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
<nsh> i guess it's not easily possible to use sequential aggregation (weaker / more accepted assumptions) and delegate the strict ordering to miners
<nsh> nope
<kanzure> not sure why 2-of-2 multisig is the goal there?
<kanzure> oh, you were just describing coinswap's mechanism
<gmaxwell> kanzure: hides the contract. network never sees the script, which in an atomic swap breaks privacy.
* nsh wonders if it's believed that all GDH groups are bilinear maps
<nsh> or those are just the ones we've found
www has joined #bitcoin-wizards
<fluffypony> .title
<yoleaux> Using Machine Learning to predict the outcome of a zzuf fuzzing campaign
darwin_ has joined #bitcoin-wizards
<nsh> (no, 'Consequently, if a group G is a bilinear group then G is also a GDH group. (The converse is probably not true.)')
pavel_ has quit [Quit: Leaving]
<gmaxwell> nsh: yea, I expected that. since it's easy to see how you get the DDH test from bilinearity, but I could certatly imagine DDH being possible without bilinearity.
* nsh nods
www has quit [Read error: Connection reset by peer]
www1 has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
<nsh> is it possible to find/contrive curves of arbitrary bilinear security parameter? or is there some tradeoff between the useful size of the subgroup and the difficulty of the transport
wallet42 has joined #bitcoin-wizards
* nsh curses pdfs with unreadable-in-linux fonts :/
<nsh> also is the security parameter (alpha) equivalent to the embedding degree, or is that another thing? (latter is used here: http://theory.stanford.edu/~dfreeman/papers/ants-embedding.pdf )
justanotheruser has quit [Quit: Reconnecting]
justanot1eruser has joined #bitcoin-wizards
<gmaxwell> nsh: going a little deep into the blackbox for me; there are several different known famlies for getting pairing friendly groups.
* nsh nods
<nsh> oh, this says there is a construction for arbitrary degree, but it seems ~6-8 is commensurate with 2^160 bit ECC security
<nsh> so it may be academic
<gmaxwell> nsh: for security you want the CDH to be hard on both sides, so if your smaller group is size x then you need some k such that x*k is as strong a size for integer discrete log as x is.
<nsh> right
<gmaxwell> since e(G,P) = e(G,xG) = e(G,G)^x if you can solve the discrete log in the transfer....
<gmaxwell> (should have said and if you can...)
* nsh nods
<gmaxwell> lots of handwave thoug that the special structure doesn't make things easier than expected.
darwin_ has quit []
lnsybrd has quit [Quit: lnsybrd]
<nsh> right
<nsh> i am apprehensive when i see the phrase "infinite family of [such] curves"
<nsh> because that's a lot of potential pathology
<hulkhogan_> quick q, if, when sending messages to a mix, the mix encrypts and sends to either A)another mix or B)the final destination are there any vulnerabilities that are easy to spot in this config?
<hulkhogan_> need to note, if passing through to another mix, its not re-encrypted
<hulkhogan_> the encryption is to the final destination's public key
zooko has quit [Ping timeout: 264 seconds]
www1 has quit [Ping timeout: 276 seconds]
<hulkhogan_> verification happens at the final destination, and since messages are batched, ddos shouldn't be an issue
<gmaxwell> hulkhogan_: hm? whats the 'mix encrypts' for? do you just mean transport level encryption?
<gmaxwell> the normal constructions for mixnets are with nested messages where each inner layer is encrypted to the next hop.
<gmaxwell> keep in mind that if the goal is to thwart traffic analysis (it is!) it may be important to make all messages constant size.
<hulkhogan_> yea i think so... in this case thats basically the use, and so the inner mixes dont receive any information about the transactions being passed through
<hulkhogan_> thats a good point...
<hulkhogan_> yeah, well the thinking is - expose a webservice to take in new transactions (Accessible via tor for privacy), those get handed to either another mix or the final node, we dont want to leak information if we are going over 1-hop, so we encrypt until the final dest
<hulkhogan_> you can think of it as three webservices, one to handle relay/broadcast, one that sits infront of the node for handling encryption/other necessary things, and perhaps a status webservice to get information on avaible mixes..
<hulkhogan_> i havent thought it all the way through, there may not be a need to have additional mixes, for example
<gmaxwell> it really should be tor reachable only, otherwise some idiots will reach it over the plain web (even if just accidentally) and then there will be big incentives to monitor the entry. :)
<gmaxwell> well a single hop doesn't provide any privacy (beyond the use of tor to reach it) from the operator of it.
<hulkhogan_> well, what if you're at a coffeeshop and want to submit with privacy? i think ip masquing tricks (vpn, coffeeshop) allow for some level of privacy, we shouldn't throw away those users, is my pov here
damethos has joined #bitcoin-wizards
<hulkhogan_> ack, perhaps i need to do more reading..
<yoleaux> On the Cryptographic Hardness of Finding a Nash Equilibrium - YouTube
<gmaxwell> hulkhogan_: hm, tor should work from the coffeeshop. :)
<hulkhogan_> yea very true
<hulkhogan_> well it sounds like this should be set up as a hidden service, possibly
<nsh> (it's debatable whether anything should be set up as anything other than hidden service)
<hulkhogan_> well, originally i was thinking it was ok to expose a service/webpage accessible over tor, for IP masquing reasons
ThomasV has joined #bitcoin-wizards
<hulkhogan_> so visiting the site over tor would not allow the service to id you via IP
<gmaxwell> yea, I wouldn't have done anything other than a hidden service, otherwise it's just too interesting to attack. Some idiot would start using it without tor and then getting traffic data from the site is suddenly very interesting.
<hulkhogan_> there are a lot of other ID leaks if you use a browser, so perhaps hidden service is best..
* nsh nods
<nsh> "if your laptop can't find it, then neither can the market"
davi has joined #bitcoin-wizards
<nsh> (would be nice to have the converse of this unlearned from a few people)
davi has joined #bitcoin-wizards
davi has quit [Changing host]
<hulkhogan_> heh, privacy is tough /goes to think more
<hulkhogan_> i think having a check on the user-agent to ensure you use tor-browser would be important
<hulkhogan_> so then you get the assurance of tor + tor-browser to eliminate fingerprinting
<gmaxwell> using a plain socket and a uniform client is far far far less attack surface than even tor browser.
priidu has joined #bitcoin-wizards
<hulkhogan_> although i dont know how to answer this, 'what makes this scheme better than starting tor and submitting transactions over socks to various block explorers that support pushing txs'
<kanzure> which ones support that
<kanzure> other than bci?
<hulkhogan_> a few, blockr?, coinbelly?
<gmaxwell> hulkhogan_: because the server would protect the user from traffic analysis.
<gmaxwell> by making private the amount of data sent and the timing.
<gmaxwell> (perhaps go read up on what mixmaster does!)
<kanzure> .wik mixmaster
<yoleaux> kanzure: Sorry, that command (.wik) crashed.
<kanzure> gah
<nsh> (bah)
<nsh> .wik Mixmaster anonymous remailer
<yoleaux> nsh: Sorry, that command (.wik) crashed.
<kanzure> perhaps this is related to their https rollout
<nsh> "Mixmaster is a Type II anonymous remailer which sends messages in fixed-size packets and reorders them, preventing anyone watching the messages go in and out of remailers from tracing them." - https://en.wikipedia.org/wiki/Mixmaster_anonymous_remailer
<hulkhogan_> yea i have one of the comparsion papers kanzure posted ready to be read... it was helping, i should finish that first probably
zooko has joined #bitcoin-wizards
shen_noe has joined #bitcoin-wizards
gill3s has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
wallet42 has quit [Quit: Leaving.]
chmod755 has joined #bitcoin-wizards
sparetire_ has joined #bitcoin-wizards
nessence has quit [Read error: Connection reset by peer]
nessence_ has joined #bitcoin-wizards
Crowley2k has joined #bitcoin-wizards
b_lumenkraft has quit [Quit: b_lumenkraft]
darwin_ has joined #bitcoin-wizards
rusty has joined #bitcoin-wizards
nwilcox has quit [Ping timeout: 252 seconds]
darwin_ has quit []
dc17523be3 has quit [Read error: Connection reset by peer]
melvster has quit [Ping timeout: 252 seconds]
SDCDev has quit [Ping timeout: 255 seconds]
dc17523be3 has joined #bitcoin-wizards
melvster has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
nwilcox has joined #bitcoin-wizards
ThomasV has quit [Ping timeout: 252 seconds]
jmcn_ has joined #bitcoin-wizards
jmcn has quit [Ping timeout: 276 seconds]
SDCDev has joined #bitcoin-wizards
<isis> a vpn will give you privacy, which isn't at all like anonymity. however, a vpn will also fail open, along with other various disaster modes within the design, making it an excellent footshotgun if you actually care about privacy or anonymity
<isis> gmaxwell is correct that a single hop of encryption for the tx isn't going to do anything w.r.t. privacy/anonymity. you actually do need a bare minimum of three, otherwise there are way too many attacks upon the mix network which become excessively easy… like path bias attacks with only two hops in between the client and the destination would be brutal.
<hulkhogan_> the designs changed a bit since then... using a hidden service protects against snooping the client/dest, the rest of the components would sit behind that in another network
Quanttek has quit [Ping timeout: 264 seconds]
_biO_ has quit [Read error: Connection reset by peer]
<hulkhogan_> i think originally i had pseudoanonymity as the goal, reading more, i have tweaked the model towards anonymity a bit more
Tebbo` has joined #bitcoin-wizards
<gmaxwell> the whole thougth there was that tor gets you many advantages (including a bigger anonymity set) but not traffic analysis resistance, something riding inside tor can give traffic analysis resistance.
<hulkhogan_> i was just too concerned with accessibilty not considering the endgoal in mind
<isis> pseudonymity == anonymity, i.e. how can you have multiple (unlinked) identities without being able to have unlinked identities?
nwilcox has quit [Ping timeout: 264 seconds]
<isis> they are not exactly the same, but for purposes of designing a mixnet, they do go hand in hand, since an attack on one is usually an attack on the other
<hulkhogan_> isis: can you cite a reference? i'd be interested to read more
Tebbo has quit [Ping timeout: 256 seconds]
<isis> oh god, if i have a paper for that, it's going to be so old… but i'll look
mjerr has quit [Ping timeout: 240 seconds]
<hulkhogan_> np
<hulkhogan_> but i think keeping things off clearnet, only hosting over hidden services eliminate 90% of the concerns earlier
<hulkhogan_> other concerns like sybil/ddos mostly something the software needs to handle using pow or uptime schemes, not sure
SDCDev has quit [Ping timeout: 256 seconds]
SDCDev has joined #bitcoin-wizards
<nsh> .title
<yoleaux> How to use Bitcoin to Enhance Secure Computation - YouTube
<nsh> How to Use Bitcoin to Incentivize Correct Computations -- http://people.csail.mit.edu/ranjit/papers/incentives.pdf
<nsh> How to Use Bitcoin to Design Fair Protocols -- https://eprint.iacr.org/2014/129.pdf
<isis> the lagginess of hidden services might be viewed in a more glass-half-full manner as providing builtin (D)DoS resistance :)
<isis> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt describes the upcoming changes to hidden services, for those interested in building future systems on top of them
<gmaxwell> isis: did it ever gain some hashcash like DOS mitigation (not sure if you're aware but there is a proposal for TLS to support doing that)
jtimon has joined #bitcoin-wizards
<isis> we haven't added overt DOS mitigation yet… there have been a few rather fragile bugs which are fixed in the new design which should provide what you could call increased DOS mitigation/rate limiting, but other than that, no.
shen_noe has quit [Quit: quitquitquit]
davi has quit [Ping timeout: 265 seconds]
<isis> gmaxwell: the hashcash DOS mitigation, that means just the actual proof-of-work system, correct? or did hashcash have an additional mechanism?
go1111111 has quit [Ping timeout: 252 seconds]
rht__ has quit [Quit: Connection closed for inactivity]
nwilcox has joined #bitcoin-wizards
Crowley2k has quit [Ping timeout: 252 seconds]
damethos has quit [Ping timeout: 276 seconds]
go1111111 has joined #bitcoin-wizards
<gmaxwell> thats all
jtimon has quit [Ping timeout: 272 seconds]
<hulkhogan_> isis: thanks for sharing that terminology piece, its very helpful in decoding some of the stuff i was reading earlier
<Luke-Jr> gavinandresen: BIP16 vs 17 was a different situation IMO: both proposals were reasonable, and everyone agreed we needed one of them
darwin_ has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
<Giszmo> sudo npm install -g cordova
<Giszmo> (oops. wrong chat :/ )
moa has joined #bitcoin-wizards
prodatalab_ has quit [Ping timeout: 256 seconds]
nwilcox has quit [Ping timeout: 264 seconds]
StephenM347 has quit []
nwilcox has joined #bitcoin-wizards
JackH has quit [Ping timeout: 256 seconds]
zooko has quit [Ping timeout: 265 seconds]
darwin_ has quit [Remote host closed the connection]
darwin_ has joined #bitcoin-wizards
<waxwing> andytoshi: i got my py script to verify a sig out of the tests.c :)
<nsh> \o/
temujin has quit [Ping timeout: 246 seconds]
nwilcox has quit [Ping timeout: 246 seconds]
rustyn has quit []
rusty has quit [Ping timeout: 256 seconds]
nwilcox has joined #bitcoin-wizards
devrandom has quit [Ping timeout: 265 seconds]
belcher has quit [Quit: Leaving]
robogoat has quit [Ping timeout: 264 seconds]
belcher has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
Mably has quit [Ping timeout: 245 seconds]
justanotheruser has joined #bitcoin-wizards
justanot1eruser has quit [Quit: Reconnecting]
adam3us has quit [Quit: Leaving.]
justanotheruser has quit [Remote host closed the connection]
justanotheruser has joined #bitcoin-wizards
nessence_ has quit [Read error: Connection reset by peer]
Guyver2 has quit [Remote host closed the connection]
nessence has joined #bitcoin-wizards
adam3us has joined #bitcoin-wizards
blahblah has joined #bitcoin-wizards
nubbins` has joined #bitcoin-wizards
Burrito has quit [Quit: Leaving]
blahblah has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
eennaam has left #bitcoin-wizards [#bitcoin-wizards]
someguy has joined #bitcoin-wizards
alephbet has joined #bitcoin-wizards
devrandom has joined #bitcoin-wizards
AaronvanW has quit [Ping timeout: 246 seconds]
<yoleaux> nsh: Sorry, I don't know a timezone by that name.
<nsh> .title
<yoleaux> Provably Secure Blockchain Protocols and Applications to Secure Computation - YouTube
dEBRUYNE has quit [Read error: Connection reset by peer]
nubbins` has quit [Quit: Quit]
<nsh> --
<nsh> We overview recent and ongoing work investigating blockchain protocols from a provable security perspective. We discuss properties such as common prefix and chain quality and introduce proof techniques for establishing such properties in a synchronous anonymous communication model assuming bounded access to a random oracle. We discuss the consensus problem in this setting and its relation to robust transaction ledgers. We also introduce a new model and
<nsh> a construction for secure computation with fairness and output delivery guarantees that are conditional on a global transaction ledger.
<nsh> --
nessence has quit [Remote host closed the connection]
<kanzure> was this the yahoo group
adam3us1 has joined #bitcoin-wizards
adam3us has quit [Ping timeout: 264 seconds]
nwilcox has quit [Ping timeout: 264 seconds]
nwilcox has joined #bitcoin-wizards
<nsh> (Aggelos Kiayias, University of Athens)