|c0rw1n is now known as c0rw|sleep
|grubles is now known as Guest21092
|Is there a mitigation to the risk of a node advertising itself as a version different from what it truly is?
|not paying attention to the self-reported version strings
|Intentional misrepresentation, say if there were a hostile reaction to a hard fork
|* Adlai is half-serious... nodes should treat all data as potentially hostile
|Sure, but orthogonal. If a node is running on a different fork (because different version) but masquerading as the opposite fork in order to disrupt it
|If I were putting together a realtime blackhole list of nodes that are not on my fork using version, and they are masquerading, the list is bad
|zooko`` has left #bitcoin-wizards
|* Adlai shrugs, this also sounds more for #bitcoin-dev or even #bitcoin
|* NewLiberty thanks you for your patience
|NewLiberty: the version is software, not network. if you need to "blackhole" nodes on a different network, you're already dead.
|Thanks for responding, but you've misunderstood the risk.
|there is no risk, when it comes to reported software version. *shrug*
|Adlai answered already. Don't trust it.
|judge peers based on behavior, which incidentally is what the current software already dose
|Right. just will need the distinguishing behaivor (which can't exist yet anyway)
|Luke-Jr consider if you are looking for nodes validating vs 20mb blocks and some trouble maker sets up many nodes that pretend to do so by reporting new version, but are running old version on 1mb chain instead.
|if one chain has higher total work than the other, and both are valid by your own node's consensus rules, should you care about anything else?
|partitioning your own node to intentionally use a less secure fork will only make it easier to perform attacks involving reorganizations against your node
|Of course not, in such case there isn't an issue. but that state would be temporary, and likely brief.
|These would be chaff nodes, just to get in the way of the fork they would want to fail
|So it is sort of thier goal to make it iasier to perform such attacks
|maybe you can explain what "such attacks" entail? afaik the relevant "attack" in this situation is an economic one, that of incentivizing a majority of hashrate to mine your preferred fork; and this is because the fork with the majority hashrate wins, no matter what the "chaff nodes" say
|Hashrate will follow investment
|do you have a specific attack in mind, one at the level of the wire protocol?
|Not at the wire...
|If all the TX on one fork aren't getting to miners
|"wire" in the sense of protocol messages sent between nodes, maybe that's the wrong word
|With no TX that fork isn't going anywhere, and then divergence in pricing between two forks occurs, miners might be switch to the other more lucerative fork.
|Anyhow, you answered what I sought in your first line, so TY
|np. also check out https://en.bitcoin.it/wiki/Freenet
|(in case you're worried about getting partitioned in the clearnet p2p network)
|I'm not worried for myself, just looking at some attack vectors that might be used to leverage an economic attacks by disrupting during a rare event. Corner case risks.
|* NewLiberty tumbles down the freenetproject rabbithole anyway
|topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
|Users on #bitcoin-wizards: andy-logbot gielbier p15x Mably felipelalli blackwraith xenog hktud0 gill3s antanst o84wb76g b_lumenkraft hashtag_ kompreni s3gfault RoboTeddy  wizkid057 Guest21092 [d__d] optimator_ cluckj Dr-G2 NewLiberty GGuyZ fanquake1 veox shesek d1ggy_ DougieBot5000 mkarrer MoALTz hashtag airbreather koshii moa metamarc PRab LeMiner dc17523be3 Emcy justanotheruser prodatalab sparetire_ Madars bsm117532 mr_burdell Eliel azariah isis NeatBasis kyuupichan
|Users on #bitcoin-wizards: gnusha amiller kanzure harrow xabbix HM iddo michagogo harrigan mariorz epscy vonzipper catcow a5m0_ smooth dignork ttttemp_ pollux-bts runeks coryfields CryptoGoon Sqt poggy jbenet cfields platinuum adams__ livegnik K1773R Alanius nsh tromp petertodd brand0 yorick ir2ivps5 OneFixt richardus luny null_radix PaulCapestany nephyrin phedny so davout phantomcircuit afdudley cdecker jonasschnelli pigeons Luke-Jr SwedFTP BananaLotus guruvan Meeh
|Users on #bitcoin-wizards: bliljerk101 lnovy ajweiss wiz nanotube dardasaba__ forrestv artifexd mappum yrashk mikolalysenko Muis lmatteis warren gmaxwell weex_ Xzibit17 GreenIsMyPepper sdaftuar eric roasbeef s1w CryptOprah huseby dasource mm_1 Taek morcos crescendo nickler EasyAt Iriez wumpus merlincorey [ace] sturles berndj comboy jaromil Apocalyptic cryptowest_ Graet indolering Keefe larraboj ryan-c jessepollak gribble d9b4bef9 starsoccer kumavis otoburb midnightmagic
|Users on #bitcoin-wizards: BlueMatt TD-Linux Anduck luigi1111 gavinandresen AdrianG espes__ warptangent STRML sl01 kinlo gwillen Oizopower @ChanServ BrainOverfl0w scoria sipa Cory theymos deego rustyn dgenr8 se3000 binaryatrocity dansmith_btc Jaamg yoleaux Fistful_of_Coins _whitelogger uumdbmd fluffypony bedeho btcdrak bosma andytoshi maaku face elastoma Logicwax SubCreative sadoshi sparetire Tiraspol hulkhogan_ jmcn_ ebfull lmacken c0rw|sleep tromp_ crowleyman heath
|Users on #bitcoin-wizards: CodeShark melvster1 Adlai sneak copumpkin helo Starduster_ KuDeTa roconnor mengine catlasshrugged throughnothing_ Krellan_ stonecoldpat spinza leakypat
|Adlai said ``miners might be switch to the other more lucerative fork.'' I have thought about this often. What if a majority of miners worked together to create a fork that was profitable while not necessarily nefarious. For instance, I often think about ``lost coins'', or coins where the private key is no longer accessible for whatever reason. Since there will only ever be 21e6 coins, expiring lost coins should only increase
|value of the remaining coins.
|kompreni: miners don't get to decide hardforks.
|It seems at least in theory it would be possible for miners to expire these coins. Suppose we have some block height X and some number of blocks Y. Starting from blockheight X-Y, people could prove control over private keys by creating a transaction to themselves. At block X, all tx inputs for new transactions must come from tx outputs from blocks with height greater than X-Y.
|kompreni: if i understand right, the miners would take control of the expired bitcoins - if they have not been used for 'y' blocks?
|if that was the case, then miners have the incentive to censor high-valued transactions - and then just claim them when 'y' happens, assuming their greedy
|how does expiry work with cold wallets?
|stonecoldpat: Not necessarily take control — that would be a more nefarious scheme. I was thinking something more honest, like ``these coins have not been used in however long, so we will reject them if they are not proven usable by a certain time’’
|Luke-Jr: the transaction would get rejected by the network if the source address is not proven spendable within the timeframe
|kompreni: there is no such thing as a source address in bitcoin
|and killing cold wallets would be annoying
|Luke-Jr: sorry, I meant utxos
|kompreni: would that not just encourage more broadcasting on the network? and if they become invalid - do the coins become recycled in the coinbase? or lost forever?
|I see no benefit to such expiry. Just downsides.
|Luke-Jr That would be annoying, but to quote gmaxwell: ``My perspective is that absolute soundness is best (rules which cannot be broken at all), followed by cryptographic soundness (rules that breaking requires P=NP, theft of a secret, or insane luck), followed by economic soundness (rules that cannot be profitably broken), followed by honesty soundness (rules that hold when the participants follow the rules and aren't fault
|What if it was economically sound to do so?
|kompreni: if they are recycled, then the miners would take control and we're back to censoring transactions
|I’m wasn’t considering them recycled… I was thinking lost forever.
|if i cant 'spend' the utxo / prove ownership of it - then no one is entitled to those coins
|The value of everyone else's bitcoin would increase, provided they could prove spendability
|I don't see how you think that quote is relevant.
|if they are lost forever then all we do is reduce the utxo set, i dont think the data saved in ram would be enough
|Luke-Jr: I think it’s relevant because this exploit would be at the fault of the bottom two rungs of soundness - that is economic soundness and honesty soundness.
|The miners need not be honest to the core devs
|And it also might be more profitable for miners to run nodes that requires provable spendability
|i can see that what you suggest would be to explicitly show people that there are less coins, but this is already done implicitly if coins have not been used for a long time (zombie coins) - i cant comment to say if the explicit is worthwhile, it could be counter-productive as people lose large stocks of coins and then leave the eco-system
|i think the fact we already have a hard-limit of 21m is already worrying people of the future, never mind being explicit that we have less than 21m
|there should never be expiry on coins, unless its dust.
|People at risk of losing large quantities of coins could be buffered with ample block time (say, a year).
|i think most people would be alright with giving UTXO's under 0.0001BTC to miners if they're not moved in say, 4-5 years
|i bet that sort of code could be merged in without much objection... it would really need to be dust though... 1000 satoshis or less and not moved for 4 years
|s3gfault: i can see right now that would work yeah, in 40 years time if dust is standard usage (so 0.0010 represnts $20, with $1 transaction fees) then it may not be
|thats why it needs to be sweeped within 4 years , not 4 years. so people losing their dust can't complain
|'not 40 years'
|Also, and I may be getting myself neck deep here, but I think it’s tough to institutionalize an asset like Bitcoin when people don’t know how many coins are actually usable. For instance, consider Satoshi’s mined blocks. All together, he contains several percentages of the total supply of Bitcoin. Is it not of significant investor interest to determine if such high quantities are actually usable?
|fees will be adjusted... any UTXO worth less then 1 cent USD should be given to miners if not spent after X blocks
|i just mean if the code was merged and we had this cycle of sweeping for a long time - in the future it will probably need removed if small coins become valuable
|why should the dust be sweeped?
|kompreni: thats a bit like saying - nobody knows who owns this gold so lets melt it and blast it into space, so we are certain it can no longer be counted
|what if i, say, just printed a big pile of 1 and 10 μBTC notes and dug them in the ground
|to be dug out after 15 years
|kompreni: people may very well find their private key again, satoshi may even return (or his grandkids) to cash-out and buy a super-yhoat to escape the press
|stonecoldpat I was actually thinking of it as a one-time expiry, not a periodic occurrence necessarily. I think the idea of some mystery figures owning large stakes of Bitcoin is causing big players who want to be involved, to not take the risk. I have no facts to back this up though (lol)
|who should decide when this one-time expiry happens?
|So I guess my argument is from multiple perspectives. To recap: it would increase the value of spendable Bitcoins, since those not proven so would become worthless. And, it would remove some of the confusion around the true market cap, shareholding, etc of Bitcoin
|and what expires
|Jaamg the Mining network collectively would decide to run nodes that hardfork to reject txs composed of utxos dating back from a block height less than a (network agreed upon) block-height-threshold, so to speak.
|kompreni: i think it would pretty hard for them to find consensus on this
|Certainly not NP Hard, though ;)
|id be worried though - if miners collectively started to censor these transactions, this further opens the gate to censorship
|kompreni: maybe not, but i don't think there is anything that can be done to it
|or is there?
|while miners do have that power - i dont think its a miners role to dictate what transaction gets in/out as some type of gate-keeper, they should be accepting all valid transactions
|of course if theres a backlog, there is a priority attached to transactions, but that should be well-defined
|I would not doubt the power of group of people to effectively ``unionize''
|The people in this case being miners
|I think it is foolish to think the Core Devs will be able to maintain a grapple on the entire network out of good faith. Because that is ultimately what it comes down to — good faith. If enough support is garnered from running some custom hardfork node in the biggest pools, the entire ecosystem could be easily hijacked
|And by ``entire'' I mean 51%
|What is stopping them?
|as you said earlier, the economic factors, that type of censorship could kill the value of bitcoin, (we dont know if it would or not) - but its an unknown that is stopping them
|I agree it could kill it. But I could also see it being part of a process to supplant that radical, free (awesome!) value with institutional value, i.e. the consensus algorithm becomes entangled with special interest groups, lobbying, etc.
|I mean hey, look at how being ``free'' in America has changed over time — we live in a constant state of surveillance. Granted, that consensus algorithm (the constitution) has evolved pretty slowly, but technology evolves fast. And I think (economic) security can be seen as a driving factor in both cases. I think we should give credence to patterns in history and prepare as best as we can :)
|LeMiner is now known as LeMiner
|does anyone know if spv wallets today support building a merkle-tree to prove that an utxo they can spend has been accepted to the blockchain?
|stonecoldpat: this seems to be the definition of spv
|i mean, is there a wallet today that would generate that information for me, that I could then give to someone in a seperate communication channel
|generate the merkle branch, or the whole tree?
|just the branch
|spv wallets don't build such proofs, they request them and verify them
|to build them, you need to have the block
|and bitcoin core has recently a patch merged to create such a proof
|electrum requests the merkle branch from an electrum server; you could use that
|sipa: so it will be available with bitcoin-cli?
|ah that is cool ill check out that patch and the electrum server is a good idea thanks thomas - i wasnt sure if an spv client would keep the merkle tree locally once it hears about the new transaction or not (that could then be regurigated).
|stonecoldpat: added that for you: https://github.com/spesmilo/electrum/commit/5fa2a48343be7253497bb96ad70d091011ef4389
|c0rw|sleep is now known as c0rw1n
|ThomasV: thanks! :)
|LeMiner2 is now known as LeMiner
|so -prune=1000 keeps blockchain files around ~1Gbyte now right?
|Recommended reading: proposal for a memory-hard function for mining http://eprint.iacr.org/2015/430.pdf
|sausage_factory is now known as priidu
|Guest21092 is now known as grubles
|an old essay linked recently https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign on amateur crypto
|seems relevant in this space too... especially #1,2,4 of the take-aways
|ofc #3 as well. 5/6 seems pretty standard these days
|tromp has left #bitcoin-wizards
|Guest24344 is now known as amiller_
|amiller_ is now known as amiller
|re: bitcoin-development@ ... it's been a while since someone propoposed DHTs, I was getting nostalgic the other day.
|gmaxwell: the latest coolness is CHT's
|fluffypony: Centralized Hash Tables
|centralisation is all the rage these days
|fluffypony: I'm not even going to ask why you know about Cycloheptatriene...
|* Tiraspol slaps petertodd around a bit with a large trout
|Tiraspol: I'm not going to say on a public forum whether or not I'm into that...
|everyone knows you are
|grubles is now known as Guest45787
|maaku is now known as Guest18989
|Guest45787 is now known as elgrubles
|dEBRUYNE_ is now known as dEBRUYNE
|im announcing my coinscope project today
|project page and paper: http://cs.umd.edu/projects/coinscope/
|amiller: the image resource isn't showing, fyi
|ive been quiet about it mostly because i wanted a chance to collect some of the data before the technique is widely known
|StephenM347, uh, i think i just fixed it try again :(
|amiller: yeah, works now
|one of the main ideas is to use 'addrman' finger printing to figure out which nodes in the public network are connected to each other
|amiller: hah, did you know about the technique beforehand, or did you learn about it from nickler?
|i.e., whats the topology of the reachable network? is it actually random or is it skewed towards well connected nodes or is it vulnerable to partitions
|sipa, i've been using it since jan 2013 or so.
|ive shown preprints of my paper to gmaxwell and a few others earlier btw to cover my ass and have a better chance of not inadvertently breaking the network
|also tested it on local networks and partially tested it in my shadow simulator
|(i'm actually very anxious / self concious about doing anything 'bad' to the network especially after chainalysis etc. so im trying to stay on the non-evil side here)
|i'm mostly talking about not trying to get it fixed for so long :)
|well, like i said i mentioned the technique discreetly, so it could have been stopped quicker if it seemed urgent
|im of the opinion that this kind of measurement / fingerprinting is more of a positive thing than a negative thing so im a bit sad newer versions make it harder for that reason
|"It is therefore possible to block a node from hearing about a transaction for two minutes by sending an INV message and then ignoring the resultant GETDATA." - I don't think that's a good thing :p
|it depends on how it will be used, analysis has its place but a network map of all p2p nodes , if its a effective technique would probably be used to analyze a part of the topology before attempting a sybil (so its useful in that regard, i suppose)
|I'm not so much talking about the use cases but about the fact it's possible to do this
|" Assuming honest pools broadcast using the standard protocol, and the selfish pool selectively creates low latency connections to the influential set, the latter can gain huge broadcast advantage."
|^^interesting, is this well known>?
|"Prior work has shown that a selfish mining pool can gain advantage if it initially withholds blocks it finds, but then releases them as soon as a competing block is found." (Prior work, i guess so, nm)
|ah yeah so besides the topology mapping, the mining pool decloaking stuff is entirely new and i havent talked about it at all yet
|i am by no common measure, a wizard of any type,but amiller am i right in thinking that a carefully constructed DOS attack to that "2%" IP address would cause havock?
|sorry, 2% list of IP addresses..*
|i guess if you can knock 3/4 of the hashing power out, even only for a few hours, that could be a very profitable little adventure.
|KuDeTa, i think its possible. i think its likely (but my evidence is not totally conclusive) that there are several mining entities with a single publicly reachable frontend, so those could be dosed. i *speculate* that what is happening is that other pools including the largest pools have outgoing-connection-only frontends and so that would be harder to dos
|also just because i found a bunch of nodes with high affinity for one pool or another, it oculd be they are just the lowest latency connections, and if those were taken out there are lots of other connections too just marginally higher latency, so they dont win races
|hmm, yeah, i figure the big pools have thought about this and taken counter measures (i think i remember some pools being dos'd in the early days) - still, i wonder if your work leads to ways of constructing attacks that could do harm? Have you thought about it much?
|"i figure the big pools have thought about this and taken counter measures" - famous last words :p
|would sure be interesting to watch if someone tried to do it..
|even assuming equal propagation chances, the selfish miner attack still only requires 1/3 of the network
|we like to live dangerously, though ;)
|is there anything that could be done about services like cryptograffiti.info bloating up the utxo set ?
|sending small amounts of thousands of addresses in an effort to store data
|* chmod755 adds cryptograffiti.info btc addresses to his blacklist
|wtf, people putting torrent URLs in there
|chmod755 how do you know what they are in advance?
|copumpkin also whole images
|might be easier to live with if it was with op_return
|but this junk is unprunable
|chmod755 also what blacklist? i assume your miner..
|you can detect them by checking if the address hex is all ascii characters
|if only there were some way to limit the amount of data the network carried! or perhaps a way to neutrally allocate capacity between more and less valuable uses, without passing a personal judgement over each one? Too bad no one has any idea how to accomplish that!
|belcher: that test has a pretty poor false positive rate, sadly. :(
|c0rw1n is now known as c0rw|zZz
|belcher, it looks like they are reusing some addresses
|hm. higher than I thought, so "contains a non-printable character" looks like about one in 250 million. unless I'm math failing.
|In anycase; going and blocking particular things is a not great route.
|yep, that would reduce confidence in bitcoin
|chmod755: I dunno about that one; but many of those things required their users pay to some static service address; so a generic high reuse deprioritizer catches them; but thats easily changed.
|chmod755 they might be reusing addresses because common messages are repeated
|belcher: the more generic the less concerning; but really the system has mecneisms to deal with it more fundimentally; limits and a market for the limit.
|the utxo set is a common good if im not mistaken, the market for fees is only for blockchain space
|perhaps some kind of outreach ? convince developers to use op_return instead of utxos
|belcher: can't add to the UTXO without using blockchain space.
|the whole motivation is to externalize cost for people, using an encoding that helps people not store your data doesn't sound like a great pitch. :)
|regarding fees, the market doesnt operate on utxos, spending 100 utxos to create one isnt cheaper than spending 1 to create 100, the calculation the miner does is presumably related to propagation time not utxo size
|belcher: it actually is, in the current bitcoin core calculation
|i understand the blockchain will always need to be stored somewhere, to bootstrap new nodes and all, so op_return will still fulfill their desire for permanent storage
|sipa i didnt know that, thats nice of the miners
|i guess they're full nodes and store the utxo set too
|more like "thats nice of them to not pay any attention to the changes gmaxwell made"
|i wont tell anyone :)
|but that behavior is only to change the calculation for 'free' transactions; -- I figured more would cause action.
|since changing the priority of w/ fee would arguably reduce income.
|In any case; there are lots of people proposing that nodes don't bother with history and just hotstart from some trusted database.
|I'm not personally fond of it; but it seems likely to happen to varrious degrees. Reachability of OP_RETURN data isn't necessarily so good, and even if a node has it-- that doesn't mean it'll serve it to you.