sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
leakypat has joined #bitcoin-wizards
<bsm1175321> So back on topic. I just had a maybe interesting idea about sharding.
<kanzure> did you happen to read vitalik's sharding paper thingy?
<bsm1175321> kanzure: no... link?
<bsm1175321> Oh yeah that one. I read it a while ago...I'll look again.
<bsm1175321> Imagine many mined coins, in a geographic region (defined by low ping time), where the miners are located in this geographic region. By virtue of the low ping time, the block time can be very fast, or equivalently, convergence/confirmation very fast. With atomic transfers (Lightning Network), one can create links between geographic regions that are essentially instantaneous.
<bsm1175321> It's a hub-and-spoke model where the hubs are mined coins and the spokes are LN.
<kanzure> i mentioned a small point about multi-chain atomic transfer stuff here http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html
CubicEar_ has joined #bitcoin-wizards
hashtag has joined #bitcoin-wizards
pozitron has joined #bitcoin-wizards
<kanzure> but yes, cut-through payment channel stuff might go through different chunks of totally unrelated state space, to get to the destination that you prefer, and presumably the intermediate route doesn't matter that much.
CubicEarth has quit [Ping timeout: 255 seconds]
<bsm1175321> I think this would be a much faster network, since one doesn't need global convergence. Transaction time would be cut to local convergence time + ping time (LN).
GAit has joined #bitcoin-wizards
<bsm1175321> The other idea I'm toying with is trying to devise a ZKP that indicates a UTXO is unspent at a specific blockheight. (Where each node is only holding a fraction of the UTXO space and tx's are collaboratively verified before mining by passing ZKP's)
leviathaan has joined #bitcoin-wizards
davec has quit [Read error: Connection reset by peer]
<leviathaan> is it any worth investing in mining anymore?
<adlai> no, and you'll hear that in #bitcoin-mining too
<leviathaan> but if people will shut down their hardware due to difficulty then it will stop working
<leviathaan> is there a credible article by any chance that details what is going to happen to btc in the near future? (1-3 years)
<leviathaan> sorry for the noob question, i know you guys get this a lot
<adlai> noob questions are fine, the problem is relevance; this is not the right place for these questions
<adlai> you should try #bitcoin, #bitcoin-mining, or ##bitcoin (i'm not kidding!)
davec has joined #bitcoin-wizards
<adlai> but to answer your question, my guess is that during the next 1-3 years, bitcoin will keep working, but probably reduce the block subsidy to 12.5
frankenmint has quit [Remote host closed the connection]
<merlincorey> I read a little of the backlog and realize that you guys decided it was off topic, but Guest1234 may have been this guy on HN that was saying that 11/12 core bitcoin developers are de facto employees of blockstream and that the reason the block size limit is being kept down is to further blockstream's business plans
<merlincorey> where do I go to ask about that / get some kind of comment?
<merlincorey> https://news.ycombinator.com/item?id=10819217 << part of his rant
<adlai> merlincorey: /dev/null
<adlai> or maybe #blockstream, but they'll probably ignore you because it's a nonissue
<merlincorey> adlai: that's at least more productive than engaging #bitcoin or /r/bitcoin in the matter
<merlincorey> so basically the answer is "nothing to see here"?
<adlai> "core bitcoin developers" is a funny concept. yes, they write the software most people run; no, it does not matter if they want to break bitcoin, because they literally can't.
<adam3us> judging by the username that'd be jtoomim :) in a more conspiracy theory moment
<adlai> they could try, and it would be suicide (professional, if not literal, depending how deranged btc hodlers get)
<merlincorey> adam3us: fair enough :)
<jcorgan> sigh
<merlincorey> thanks adam3us pointers to more was all I was hoping for
<merlincorey> there's a lot of noise and very little signal with a lot of bitcoin things
<merlincorey> as I am sure you are familiar
<jcorgan> this isn't helping
<adlai> adam3us: maybe a "What Blockstream could do to break Bitcoin" post on its blog could help show people that it actually can't
<merlincorey> jcorgan: it's helping me -- Guest1234 above and jtoomim's HN rant linked present a bit of a conspiracy theory with regards to bitcoin core developers... having some kind of response and related thread is helpful in at least confirming it in that light
<adam3us> adlai: there's a bunch of stuff scattered around reddit over the last year. sigh. people should write more FAQs, blog explainers, less getting stuck on reddit FAQ reanswering.
<merlincorey> i.e. it seemed pretty conspiracy theory to me and I am here for technical insight and understanding to the future of bitcoin and blockchain technology
zookolaptop has joined #bitcoin-wizards
<adlai> merlincorey: are you familiar with game theory? Bitcoin's security derives more from that than plain old crypto
<merlincorey> but I;d be less interested in that if it was true there was an evil corporate cabal trying to drive things in their favor
<merlincorey> adlai: that I am
<merlincorey> anyway thanks again for the pointer and sorry for the added noise
<jcorgan> i give up
* merlincorey goes back to lurking
jcorgan has left #bitcoin-wizards [#bitcoin-wizards]
<kanzure> merlincorey: i have already replied on that Hn thread. read the comments dude.
<merlincorey> kanzure: I am on the train heading home from work, I read 5 hours ago at lunch
* adlai wishes fewer people would give up in the face of noise and disinformation
* merlincorey apologizes for not reading every second of every minute
<merlincorey> kanzure: but again thanks for the pointer :P
* merlincorey furiously reads on the train
<merlincorey> adlai: also agreed
<adlai> .later tell jcorgan next time please kick me, or whomever else is making the most noise. bitcoin needs dedication, not surrender...
<adlai> ;;later tell jcorgan next time please kick me, or whomever else is making the most noise. bitcoin needs dedication, not surrender...
<gribble> The operation succeeded.
gielbier has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
<merlincorey> kanzure: thank you for your response on HN, it is a mostly well reasoned counter point
<kanzure> there's more than one.
<merlincorey> I only saw that one - maybe will go back and read more
zookolaptop has quit [Ping timeout: 245 seconds]
cheetah2 has quit [Remote host closed the connection]
Guyver2 has quit [Quit: :)]
leviathaan has quit []
GAit has quit [Quit: Leaving.]
tulip has joined #bitcoin-wizards
<tulip> > < adlai> NOPs are a scarce resource
cheetah2 has joined #bitcoin-wizards
<adlai> so are highlights. happy Year of the Difficulty Adjustment Period, tulip !
<tulip> the nice thing is that given one NOP, you can soft fork in more NOPs. it wasn't actually done this way, but this could have been used in the extension to Bitcoin script where the creator added NOP1-NOP10 for soft forks.
cheetah2 has quit [Remote host closed the connection]
<adlai> the general approach of "the existing rules never change, but anything is possible if you dance just right between the canyon walls" is highly underappreciated and underemphasized in CS101
<tulip> OP_NOP becomes OP_NOP_EXTENSION, which gives you 256 more NOP.
<adlai> but what if #42 is OP_NOP_MORE_EXTENSIONS?
<alpalp> tulip sounds like unicode
<alpalp> or multibyte text
<tulip> Bitcoin originally supported multi-byte opcodes so it's not that outlandish.
<adlai> really, bitcoin can do anything the miners allow, provided they don't break consensus.
* adlai is talking about the capital-c Consensus, about system rules, not state consensus... we need some new words!
cheetah2 has joined #bitcoin-wizards
<jl2012> With segwit, we could escape from the original script system and the number of NOP it's not a problem at all
<tulip> I've often wondered how realistic it would be to actually remove Bitcoin script entirely.
<adlai> what'd you replace it with?
cheetah2 has quit [Remote host closed the connection]
<tulip> the number of scriptPubKey which aren't standard P2PKH / P2PK / encapsulated multisig is astonishingly low. if desired it could just be removed completely and the standard formats hardcoded in.
<adlai> well, you do want to leave some programmability, or else "programmable money" is no more than "decentralized pseudonimous cash"...
<tulip> you would then have segwit types and the complexity of Bitcoin script is gone.
<adlai> it seems that hardcode-coin would not support "BIP4x"
<adlai> so while it would "exist", you wouldn't be able to enter nor exit the system without invoking trust
<tulip> calling Bitcoin Script programmable money is pretty misleading, it's just a language which lets you play with signatures for the most part.
<adlai> it's programmable enough... most people wouldn't know a turing machine if it fell on their foot
<tulip> people think of "programmable money" as things like coin covenants, which Bitcoin is very much unable to do. it's just an astonishing complex way of defining signatures, multisig, and timelock restrictions.
cheetah2 has joined #bitcoin-wizards
<adlai> cross-chain swaps involve more programming than most "hello world" examples
gentoognuhurd has quit [Ping timeout: 260 seconds]
cheetah2 has quit [Remote host closed the connection]
melvster1 has quit [Ping timeout: 240 seconds]
<tulip> Bitcoin Script is still the wrong way to do most things.
Cory has joined #bitcoin-wizards
* adlai goes eat, but would love to see examples
go1111111 has quit [Ping timeout: 276 seconds]
<tulip> adlai: with soft forks there's no real need for it to exist. if you have outputs with [sigtype] [sig] and your node doesn't understand how to valid [sigtype] you ignore it, if you do know how to validate it you do so. versioned transaction scripts were part of Bitcoin originally as well, but were the victim of poor implementation.
CubicEar_ has quit [Remote host closed the connection]
melvster1 has joined #bitcoin-wizards
go1111111 has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
Cory has quit [Ping timeout: 255 seconds]
<tulip> I basically posit that the amount of complexity doesn't justify its existence. in the spirit of versioned transaction elements here's a Bitcoin Script challenge (open to anybody in the channel). attempt to explain the marked behaviour, you should attempt to describe the difference between the definition of OP_VER and OP_VERIF. https://i.imgur.com/ia6D40y.png
Cory has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
CubicEarth has joined #bitcoin-wizards
<tulip> bonus points, explain why OP_VER is disabled.
cheetah2 has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
<alpalp> OP_VER will just push the version on the stack, OP_VERIF will compare the verison to a value.
trippysalmon has quit [Ping timeout: 250 seconds]
<tulip> yes, so OP_VER could have forked the network every time it was used.
<alpalp> transaction is valid under one version, but not in another?
<tulip> yes. the value pushed to the stack is that of the client version validating the transaction.
<alpalp> but satoshi was all knowing and perfect and conceived without sin
laurentmt has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
<tulip> you correctly described what the opcodes used to do, what they do today is interesting in its own right. you can use OP_VER in a non-transversed conditional branch with no ill-effect, but OP_VERIF will instantly kill the script regardless of if it is executed or not.
laurentmt has quit [Client Quit]
gielbier has quit [Ping timeout: 250 seconds]
Monthrect is now known as Piper-Off
tulip has quit [Ping timeout: 260 seconds]
NewLiberty has quit [Ping timeout: 256 seconds]
<bramc> Bitcoin never really has 'rough consensus' more like 'clear majority of actual developers'
tulip has joined #bitcoin-wizards
<alpalp> rough consensus of those who actually understand what they are talking about?
<adlai> bramc: please don't strengthen the misconception that [un]clear majority of any group of talking heads means anything.
<bramc> adlai, Enhancements are getting accepted somehow
<tulip> (the answer for how OP_VERIF is handled in script execution https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L292 )
<adlai> bramc: there's a difference between one group of people convincing another group of people to stop producing one kind of valid data, and one tiny superminory if Bitcoin convincing the entirety of Bitcoin to start accepting batshit invalidity
<adlai> in the utterly useless "fork" terminology: the former is "soft", the latter, hard.
<tulip> what do you find wrong with the terminology?
<bramc> adlai, Even for soft forks, there rarely is 'rough consensus', too many contrarians who argue against everything.
<adlai> tulip: too similar to "software fork", and too unrelated to what they really are, which is a narrowing or expansion of consensus space
<tulip> adlai: make a new term and get it into common usage then.
cheetah2 has joined #bitcoin-wizards
cheetah2 has quit [Ping timeout: 265 seconds]
<kanzure> in a hard-fork scenario, if there is hashrate that was scheduled by a miner to come online just after the hard-fork, it seems like this makes a hard-fork decision somewhat more risky for colluding miners because they wont know whether the new hashrate is going to mine the previous rules. right?
<tulip> it seems unlikely anybody would seriously attempt that.
<tulip> the amount of chaos involved with working out what services are running what software version unfathomably huge.
throughnothing has joined #bitcoin-wizards
<alpalp> or rent hashpower to trigger a hard fork, then rent it back to orphan
<tulip> the nethash is pretty irrelevant for a hard fork (sorry adlai).
raedah has joined #bitcoin-wizards
Cory has quit [Ping timeout: 265 seconds]
Cory has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
tromp__ has joined #bitcoin-wizards
tulip has quit [Quit: Textual IRC Client: www.textualapp.com]
tromp_ has quit [Ping timeout: 245 seconds]
neilf has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
CubicEarth has joined #bitcoin-wizards
cheetah2 has quit [Ping timeout: 260 seconds]
c-cex-yuriy has quit [Quit: Connection closed for inactivity]
GGuyZ has quit [Quit: GGuyZ]
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #bitcoin-wizards
cheetah2 has joined #bitcoin-wizards
dEBRUYNE_ has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
dEBRUYNE has quit [Ping timeout: 256 seconds]
cheetah2 has joined #bitcoin-wizards
oneeman has quit [Quit: Leaving]
dEBRUYNE_ has quit [Ping timeout: 256 seconds]
<bramc> And now I've finished the is_included() functions. All that's left are add() and remove(), and those are only two functions, right?
<kanzure> although his "classes within functions" is somewhat non-pythonic
<kanzure> which also does the same thing anyway -_-
<bramc> Doing is_included() first was a good idea, it made me realize that both add() and remove() on balanced blocks (branch blocks) should jump to the end and then work their way backwards to avoid memory lookups
<bramc> kanzure, I'm fairly confident that I have a good API
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
<bramc> That can result in less performance in a set which used to be much larger and has now shrunk, but I think I'll punt on it. The 'right' way to fix it is to add a heuristic for changing branch blocks to leaf blocks when they have a small enough amount of stuff in them but that, uh, has some issues.
gentoognuhurd has joined #bitcoin-wizards
Burrito has quit [Quit: Leaving]
wallet42 has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
moa has joined #bitcoin-wizards
cheetah2 has joined #bitcoin-wizards
maaku has quit [Remote host closed the connection]
maaku has joined #bitcoin-wizards
maaku is now known as Guest8396
Guest8396 is now known as maaku
shesek has quit [Ping timeout: 260 seconds]
jannes has joined #bitcoin-wizards
Emcy_ has joined #bitcoin-wizards
Jeremy_Rand_2 has quit [Remote host closed the connection]
Emcy has quit [Ping timeout: 246 seconds]
melvster1 has quit [Ping timeout: 240 seconds]
bitcoin-wizards9 has joined #bitcoin-wizards
throughnothing has quit [Quit: Leaving...]
bramc has quit [Quit: This computer has gone to sleep]
bitcoin-wizards9 has quit [Ping timeout: 252 seconds]
wallet42 has quit [Read error: Connection reset by peer]
wallet42 has joined #bitcoin-wizards
melvster1 has joined #bitcoin-wizards
sparetire_ has quit [Quit: sparetire_]
Giszmo has quit [Quit: Leaving.]
Emcy has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 255 seconds]
Emcy_ has joined #bitcoin-wizards
Emcy has quit [Ping timeout: 255 seconds]
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 260 seconds]
cheetah2 has quit [Remote host closed the connection]
Emcy_ has joined #bitcoin-wizards
Emcy_ has quit [Changing host]
Emcy_ has joined #bitcoin-wizards
jannes has quit [Ping timeout: 260 seconds]
Emcy has quit [Ping timeout: 250 seconds]
Emcy has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 264 seconds]
pozitron has quit [Ping timeout: 260 seconds]
Emcy_ has joined #bitcoin-wizards
Emcy_ has joined #bitcoin-wizards
Emcy has quit [Ping timeout: 264 seconds]
moli has quit [Excess Flood]
Ylbam has joined #bitcoin-wizards
moli has joined #bitcoin-wizards
moli has quit [Excess Flood]
moli has joined #bitcoin-wizards
moli has quit [Excess Flood]
moli has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
moli has quit [Excess Flood]
moli has joined #bitcoin-wizards
moli has quit [Excess Flood]
moli has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 260 seconds]
cheetah2 has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
Emcy_ has joined #bitcoin-wizards
Emcy_ has joined #bitcoin-wizards
nuke1989 has quit [Remote host closed the connection]
Emcy has quit [Ping timeout: 260 seconds]
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
Emcy has joined #bitcoin-wizards
Guyver2 has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 246 seconds]
smk has quit [Ping timeout: 252 seconds]
Emcy_ has joined #bitcoin-wizards
Emcy_ has quit [Changing host]
Emcy_ has joined #bitcoin-wizards
Emcy has quit [Ping timeout: 246 seconds]
c0rw|zZz is now known as c0rw1n
Emcy_ has quit [Read error: Connection reset by peer]
Emcy_ has joined #bitcoin-wizards
Emcy_ has quit [Changing host]
Emcy_ has joined #bitcoin-wizards
CubicEarth has quit [Remote host closed the connection]
bitbyt has joined #bitcoin-wizards
bitbyt has left #bitcoin-wizards [#bitcoin-wizards]
bitbyt has joined #bitcoin-wizards
moa has quit [Quit: Leaving.]
bitbyt has quit [Remote host closed the connection]
Guyver2 has quit [Read error: Connection reset by peer]
cheetah2 has joined #bitcoin-wizards
Emcy has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
Emcy_ has quit [Ping timeout: 256 seconds]
Emcy_ has joined #bitcoin-wizards
midnightmagic is now known as midnighitmagic
midnighitmagic is now known as midnightmagic
arubi has joined #bitcoin-wizards
Emcy has quit [Ping timeout: 245 seconds]
Emcy has joined #bitcoin-wizards
Emcy has quit [Changing host]
Emcy has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 260 seconds]
Cory has quit [Ping timeout: 265 seconds]
gielbier has joined #bitcoin-wizards
trippysalmon has joined #bitcoin-wizards
gielbier has quit [Read error: Connection reset by peer]
GAit has joined #bitcoin-wizards
supasonic has quit [Ping timeout: 260 seconds]
Emcy_ has joined #bitcoin-wizards
Emcy has quit [Ping timeout: 240 seconds]
Emcy has joined #bitcoin-wizards
Emcy_ has quit [Ping timeout: 245 seconds]
JackH has joined #bitcoin-wizards
frankenmint has quit [Remote host closed the connection]
leakypat has quit [Quit: Leaving]
ratbanebo has quit [Read error: Connection reset by peer]
ratbanebo has joined #bitcoin-wizards
wallet42 has quit [Quit: Leaving.]
dEBRUYNE_ has joined #bitcoin-wizards
wallet42 has joined #bitcoin-wizards
dEBRUYNE_ has quit [Ping timeout: 250 seconds]
JackH has quit [Ping timeout: 255 seconds]
Cory has joined #bitcoin-wizards
MrHodl has quit [Ping timeout: 250 seconds]
mkarrer has quit [Ping timeout: 264 seconds]
Piper-Off is now known as Monthrect
dEBRUYNE_ has joined #bitcoin-wizards
mkarrer has joined #bitcoin-wizards
oneeman has joined #bitcoin-wizards
eudoxia has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
JackH has joined #bitcoin-wizards
mkarrer has quit [Read error: Connection reset by peer]
mkarrer has joined #bitcoin-wizards
dEBRUYNE_ has quit [Ping timeout: 276 seconds]
dEBRUYNE_ has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
shesek has joined #bitcoin-wizards
Cory has quit [Ping timeout: 246 seconds]
Cory has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
mkarrer_ has joined #bitcoin-wizards
mkarrer__ has joined #bitcoin-wizards
mkarrer_ has quit [Ping timeout: 240 seconds]
smk has joined #bitcoin-wizards
smk has quit [Ping timeout: 252 seconds]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
smk has joined #bitcoin-wizards
amiller has quit [Ping timeout: 255 seconds]
smk has quit [Ping timeout: 252 seconds]
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
Cory has quit [Ping timeout: 240 seconds]
Guest97248 has joined #bitcoin-wizards
Cory has joined #bitcoin-wizards
eudoxia has quit [Quit: Leaving]
smk has joined #bitcoin-wizards
e4xit has joined #bitcoin-wizards
Guest97248 has quit [Ping timeout: 255 seconds]
e4xit has quit [Client Quit]
shesek has quit [Ping timeout: 240 seconds]
molz has joined #bitcoin-wizards
asyncsrc has joined #bitcoin-wizards
ozanyurt has quit [Quit: Textual IRC Client: www.textualapp.com]
moli has quit [Ping timeout: 276 seconds]
oneeman has quit [Quit: Leaving]
hashtag_ has joined #bitcoin-wizards
asyncsrc has quit [Ping timeout: 272 seconds]
katu has quit [Ping timeout: 240 seconds]
Cory has quit [Ping timeout: 264 seconds]
asyncsrc has joined #bitcoin-wizards
Pasha has joined #bitcoin-wizards
asyncsrc has quit [Ping timeout: 245 seconds]
Pasha has quit [Ping timeout: 265 seconds]
Cory has joined #bitcoin-wizards
c-cex-finch has joined #bitcoin-wizards
Burrito has joined #bitcoin-wizards
ratbaneb_ has joined #bitcoin-wizards
Guest93922 has joined #bitcoin-wizards
ratbanebo has quit [Ping timeout: 240 seconds]
ratbanebo has joined #bitcoin-wizards
ratbaneb_ has quit [Ping timeout: 245 seconds]
LeMiner has quit [Read error: Connection reset by peer]
smak has joined #bitcoin-wizards
LeMiner has joined #bitcoin-wizards
smak has quit [Changing host]
smak has joined #bitcoin-wizards
smak has joined #bitcoin-wizards
smk has quit [Ping timeout: 252 seconds]
smak is now known as smk
oneeman has joined #bitcoin-wizards
Cory has quit [Ping timeout: 245 seconds]
Cory has joined #bitcoin-wizards
dEBRUYNE_ is now known as dEBRUYNE
molz is now known as moli
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
Guest93922 has quit [Ping timeout: 255 seconds]
PRab has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.1/20151216175450]]
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
brianhof_ has joined #bitcoin-wizards
brianhoffman has quit [Ping timeout: 265 seconds]
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
belcher has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
supasonic has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
PaulCapestany has quit [Quit: .]
cheetah2 has joined #bitcoin-wizards
PaulCapestany has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
belcher has quit [Ping timeout: 260 seconds]
cheetah2 has quit [Ping timeout: 245 seconds]
GAit has quit [Quit: Leaving.]
smk has quit [Ping timeout: 252 seconds]
smk has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
sparetire_ has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
frankenmint has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
nickler has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
gentoognuhurd has quit [Ping timeout: 255 seconds]
nickler has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
GAit has joined #bitcoin-wizards
nickler has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
dEBRUYNE has quit [Ping timeout: 276 seconds]
nickler has joined #bitcoin-wizards
GAit has quit [Read error: Connection reset by peer]
GAit has joined #bitcoin-wizards
dEBRUYNE has joined #bitcoin-wizards
yosso has joined #bitcoin-wizards
nickler has quit [Remote host closed the connection]
<yosso> Is being soft-forked the same as SPV security?
nickler has joined #bitcoin-wizards
<oneeman> yosso: no, not related
<alpalp> yosso: it's providing a bit more security but same idea- you see a block that looks valid but the rest of the network will see as invalid.
<yosso> So that is very similar to how a miner attacks SPV nodes
<yosso> Why a bit more then?
CubicEarth has joined #bitcoin-wizards
<alpalp> yosso: an unupgraded node will only miss blocks that break the new rule, where spv nodes could miss any rule.
<yosso> I see, so in adversarial conditions its practiclly the same
<alpalp> yosso: its easier to fool an SPV node
<yosso> alpalp: you mean easier hash-rate wise or techniclly?
<yosso> I picked up an idea on reddit suggesting hard-forks and a mechanism to detect forks and switch to SPV mode. Was that discussed before?
asyncsrc has joined #bitcoin-wizards
asyncsrc has quit [Max SendQ exceeded]
<alpalp> technically. There are more ways to full an SPV node.
asyncsrc has joined #bitcoin-wizards
<aj> alpalp: full=fool
Yoghur114_2 has joined #bitcoin-wizards
<yosso> Any thoughts on the idea above? It seem to allow cleaner and more flexable changes while keeping a similar security model
GAit has quit [Quit: Leaving.]
RedEmerald has quit [Ping timeout: 265 seconds]
GAit has joined #bitcoin-wizards
damethos has joined #bitcoin-wizards
RedEmerald has joined #bitcoin-wizards
dEBRUYNE has quit [Ping timeout: 250 seconds]
c-cex-yuriy has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
frankenmint has quit [Ping timeout: 246 seconds]
frankenmint has joined #bitcoin-wizards
melvster1 has quit [Ping timeout: 260 seconds]
damethos has quit [Ping timeout: 260 seconds]
brg444 has quit [Ping timeout: 252 seconds]
GGuyZ has quit [Quit: GGuyZ]
melvster1 has joined #bitcoin-wizards
bramc has joined #bitcoin-wizards
yosso has quit [Read error: Connection reset by peer]
<alpalp> yes sorry fool
dEBRUYNE has joined #bitcoin-wizards
<alpalp> yosso: can you show the actual idea?
cheetah2 has joined #bitcoin-wizards
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
tulip has joined #bitcoin-wizards
<tulip> yosso: no, they are not the same. a node which has missed a soft fork update is secure except in the condition where the opcode which has been soft-forked in is intentionally misused. they validate fees, UTXO spending, and subsidiary amounts safely. a SPV validating wallet like BIP37 essentially does no validation of any rule ever.
<tulip> right they left, that's an irritating misunderstanding.
cheetah2 has quit [Remote host closed the connection]
cheetah2 has joined #bitcoin-wizards
yosso has joined #bitcoin-wizards
<yosso> tulip: but iḿ talking about adversarial conditions, so it is intentionally misused
<tulip> yosso: SPV security is pretty scary, learning some of the properties of it is useful. with a single block you can defraud a basically unlimited number of users by showing them different parts of a single merkle tree of fraudulent transactions. they have no concept of "maximum transactions in a block", so you can make this pay 100BTC to every address ever used in the Bitcoin block chain.
<alpalp> why would you ever want to drop to SPV if a hard fork is detected? the author of that post has had some serious misconceptions in the past, and its posted on a forum full of misconceptions, so its hard to take seriously.
<tulip> yosso: those comments are basically incorrect. a system where nodes validate blocks, and when they see invalid data they just stop validating completely!?
GGuyZ has joined #bitcoin-wizards
<alpalp> tulip: you *could* do that, it just would be stupid, might as well aways run in SPV mode.
<tulip> alpalp: it's worse than that, it's running software which is able to detect adversarial conditions on the network, and then disabling the detection of these conditions if a fault is ever found.
<yosso> well, yes, the hardfork is activated after reaching a theshold of course. so in both cases the unupgraded once have similar security, but the change was not limited by competability issues
<alpalp> yosso: there is no such thing as a hard fork "reaching a threshold".
<bramc> In the case where both an add and a remove are in the batch update call, I'm changing the behavior to always be no change, because it's (a) what you want in bitcoin for performance reasons, and (b) fairly reasonable behavior.
<tulip> yosso: that is not correct. a soft fork *does not* reduce a node to SPV security.
CubicEarth has quit [Remote host closed the connection]
<yosso> tulip: in the sense that you see valid block that won be included, it is
<yosso> blocks
<tulip> "won"?
<yosso> alpalp: isnt bip 101 a hard fork "reaching a threshold"
<yosso> tulip: won´t
<alpalp> yosso: its a meaningless metric.
<kanzure> /win 487
<tulip> kanzure: close some tabs.
<tulip> yosso: hashrate is not a measure of anything in a hard fork.
<kanzure> tulip: never
dEBRUYNE has quit [Ping timeout: 276 seconds]
<alpalp> I highly suggest not getting information from such poor sources as /r/btc, it's almost always ill-informed and incorrect.
<tulip> yosso: with a hard fork change all participants who wish to continue using the network (other than people not doing full validation, SPV) *must* upgrade their software or be left behind. the amount of hashrate signalling with a version number is unrelated to this, miners are free to create blocks which are invalid in any way they choose- it's a security property of the network that they are not accepted.
yossso has joined #bitcoin-wizards
<yossso> tulip: yes. I understand this suggestion as changing ¨left behind¨ to ¨activate spv mode¨
yosso has quit [Ping timeout: 240 seconds]
<alpalp> yossso: what is the point of validating if you ignore chains that break the rules?
<tulip> yossso: "left behind" is the consensus system acting as designed in adversarial conditions. nodes *must reject invalid data* as defined by your local software, if you see incoming data which breaks the consensus rules you don't just disable validation.
<alpalp> suggestions like these break any security assumptions full nodes have and put Bitcoin to trusting miners blindly.
<yossso> but once you are soft-forked you can validate all you want, still as the blodks you see might not get included
<kanzure> that is why you have to wait for confirmations
<kanzure> (there are many other reasons)
<yossso> thats the same answer for SPV right?
<tulip> post soft-fork validation is not the same as SPV validation.
<yossso> (wait for more confirmations)
<alpalp> yossso: blocks that get included in a bad chain (even if it has a lot of hashpower) are something you *want* to check against.
Guyver2 has joined #bitcoin-wizards
Yoghur114_2 has quit [Remote host closed the connection]
Guyver2 has quit [Client Quit]
Guyver2 has joined #bitcoin-wizards
GGuyZ has quit [Quit: GGuyZ]
GGuyZ has joined #bitcoin-wizards
<yossso> tulip: iḿ not saying its the same. but in both cases a miner can make you see a block that will be soon rejected. I thought thatś the main issue with SPV security. I guess there are other issues.
<yossso> alpalp: i did not understand
<tulip> yossso: rejected by who?
<alpalp> yossso: if you start detecting blocks you would reject when verifying, why would you want to suddenly start accepting them?
<yossso> tulip: in the case of SPV - by the whole network (assuming for example an invalid tx) in the case of soft-fork, by anyone that upgraded
<yossso> alpalp: because (maybe) i see they are ahead version wise
GGuyZ has quit [Quit: GGuyZ]
AaronvanW has joined #bitcoin-wizards
<alpalp> yossso: so why are you ever bothering to validate? If you just assume if you see a long chain it must be valid, there is no point in validating.
GGuyZ has joined #bitcoin-wizards
<tulip> if there's an invalid block which defrauds you and you accept it, it really doesn't matter what happens after that. you've already lost your money.
flyonwall has joined #bitcoin-wizards
<flyonwall> Yossso you are right. It is more important to track consensus than adhere to rules like block size limit that don't matter.
<alpalp> Tracking hashpower is not the same as tracking consensus.
<alpalp> block size limit is a consensus rule just like verifying signatures.
<flyonwall> If hash power tries to do something you don't like--like double-spend--then you wouldn't track
<flyonwall> And chain would be orphaned
<flyonwall> If it is something you approve--like bigger blocks--then you should follow hash power
<alpalp> flyonwall: then the blocks follow your rules and you don't need to go to SPV mode.
<tulip> following proof of work blindly basically breaks the system entirely. the reason that Bitcoin is a distributed consensus is that all nodes have exactly the same validation rules.
<flyonwall> alpalp: right you care about hash power breaking *your* rules
<instagibbs> Chris has some pretty bizarre views on wallet security. I spent a decent amount of time trying to convince him what I thought were obvious things.
<flyonwall> If your rules don't include constraint on block size, then you should support hash power
<instagibbs> He says pre-CLTV full node is worse than bitcoinj...
<alpalp> unless hashpower decides to mint more coins per block
<flyonwall> right--if hash power tried to mint more coins--I would not follow them.
<flyonwall> Hopefully most other would do the same in order to orphan that blocks
<alpalp> flyonwall: what yossso is saying is you revert to SPV mode if you detected a long chain that minted more coins
<alpalp> which is silly
<flyonwall> I thought he was talking about block size limit.
dEBRUYNE has joined #bitcoin-wizards
<flyonwall> But I agree that I would not follow hash power if they tried to make more coins than agreed
GGuyZ has quit [Quit: GGuyZ]
<tulip> the system can not operate if participants randomly decide which rules to enforce.
<tulip> that's an exploitable condition, even.
<flyonwall> There is strong incentive to track consensus.
<flyonwall> Besides some node already have different rule sets
<tulip> you can't know what rules other people are validating.
smk has quit [Ping timeout: 252 seconds]
<alpalp> there is no mechanism to "track consensus" that is reliable.
<flyonwall> tulip: agreed. you can't know for sure
<tulip> you can't know at all.
<phantomcircuit> flyonwall, please describe a system for obtaining global consensus on which rules are "correct" that is not vulnerable to a sybil attack
<flyonwall> Nakamoto consensus
<tulip> the behaviour you just described, following whatever rules you want, violates that system.
<phantomcircuit> flyonwall, lol try again, that's a system in which the rules are fixed
<flyonwall> From BU website: "Consensus is therefore an emergent property, objectively represented by the longest proof-of-work chain."
<alpalp> was waiting until we got proof this was a bitcoin unlimited crank
tulip has left #bitcoin-wizards ["Textual IRC Client: www.textualapp.com"]
<kanzure> flyonwall: are you aware of the refutations of that work?
<phantomcircuit> flyonwall, an appeal to authority is lame, especially when that authority is a joke
<alpalp> phantomcircuit: appeal to unauthority
<kanzure> appeal to neutral authority
<flyonwall> Is bitcoin controlled by the code people freely choose to run or not?
<alpalp> you are free to run whatever altcoin you want.
<kanzure> you are also free to not use bitcoin
<flyonwall> Agreed
<flyonwall> So if people freely decide to permit larger blocks, and if hash power produces larger blocks, then we get larger blocks
<kanzure> not in bitcoin
<flyonwall> Semantics
<kanzure> what?
<flyonwall> Bitcoin has no block size limit
<phantomcircuit> flyonwall, yes it does, if you want to create altcoin without a limit literally nobody will care
<phantomcircuit> just dont call it bitcoin
<flyonwall> You create an alt coin by enforcing a limit--that changes the economic model that bitcoin has operated under since inception
<alpalp> now hes just trolling
<kanzure> have you read the source code?
<flyonwall> Yes
<kanzure> are you sure
<flyonwall> The source code is not bitocin
<flyonwall> There is no evidence that bitcoin can actually even enforce a block size limit
tulip has joined #bitcoin-wizards
<kanzure> bitcoin core does not seek-and-destroy altcoins. it also doesn't claim to do that.
<kanzure> so i'm not sure why you are bringing that up
<flyonwall> Bitcoin is more than just code. It requires the right economic incentives for people to choose to adhere to the whatever rules are implied by the code
<kanzure> although, i think it bans peers when the peers continue to send it bad data
<yossso> So if i understnd correctly, the idea of swithing to SPV mode once youŕe hardfored is the same as following haspower no matter what
<kanzure> but someone who has worked with the peer protocol will have to correct me on that detail
<tulip> yossso: that's correct.
<tulip> kanzure: that's correct.
<yossso> tulip: ok, got it now :)
<adam3us> did anyone figure out what BU is proposing? peter__r's previous paper seemed to be not usable in practice, not leading to practically usable observations, because he made a starting assumption which was well established & known to be invalid about game theory.
<flyonwall> yosso: yes if you do it blindy. no if you do it only for rules that you don't care about
kanzure was banned on #bitcoin-wizards by phantomcircuit [*!*@*unaffiliated/kanzure]
<phantomcircuit> er
<phantomcircuit> god damn it
<fluffypony> lol
<alpalp> adam3us: it seems very half baked. Nodes accept anything and follow hashpower but somehow signal to miners what they "prefer". miners can ignore or not and do whatever they want.
<alpalp> lol
flyonwall was banned on #bitcoin-wizards by phantomcircuit [*!*@*.69.50.179.106]
* fluffypony gives kanzure a hug
c-cex-finch has quit [Quit: Connection closed for inactivity]
<fluffypony> just in case
<kanzure> adam3us: his invalid assumptions were not about game theory iirc, but rather that mining centralization was impossible or something
<kanzure> more specifically http://pastebin.com/jFgkk8M3
<adam3us> kanzure: if I recall he had assumed that there is no work around to orphans arising block transfer latency while we know multiple ways that is an invalid assumption: SPV mining, delegating validation to more centralised pools.
<phantomcircuit> adam3us, simply delaying selecting a transaction for inclusion by 60 seconds would massively reduce that effect as well
cheetah2 has quit []
<adam3us> phantomcircuit: when paired with IBLT or weak-blocks you mean?
<phantomcircuit> adam3us, the relay network is enough
<adam3us> phantomcircuit: true.
rustyn has quit [Read error: Connection reset by peer]
rustyn has joined #bitcoin-wizards
paveljanik has quit [Quit: Leaving]
tulip has left #bitcoin-wizards ["Textual IRC Client: www.textualapp.com"]
GAit has quit [Quit: Leaving.]
flyonwall has quit [Quit: Page closed]
yossso has quit [Read error: Connection reset by peer]
<adam3us> ok so BU seems to have the weak-blocks & IBLT copied from bitcoin core scaling roadmap.
moa has joined #bitcoin-wizards
<kanzure> adam3us: he was using weak blocks to support his false fee market unlimited block size conclusions.
<phantomcircuit> adam3us, it's pretty hilarious to watch him argue in a circle
<phantomcircuit> "orphan risk will limit block size" -> "orphans are bad we need weak-blocks & IBLT" -> "wait what was that about orphans?"
<kanzure> adam3us: all of the misunderstandings originate from prior to his weak block paper (where he butchered the proposal that greg informed him about)
<instagibbs> managed to squeeze in a hate-citation though
<instagibbs> limited room in the biblio i guess
<phantomcircuit> i really want to know who he's paying to do those animations though
<phantomcircuit> they're really good
<kanzure> you mean the one where he conflates block size and transaction capacity and market price and adoption?
<kanzure> btw, trivial to make lots of fancy animations these days with d3 and other javascript libraries
<phantomcircuit> kanzure, i mean the ones in the forum post adam3us just linked to
<kanzure> if they ask for "pdf proof" one more time i think i'll just write down a single sentence about the relay network and pipe that into latex :|
<adam3us> phantomcircuit: i found it because someone had a link and said if Peter__R leaves Bitcoin he'd have a career as a GIF animator
<instagibbs> woah those are great
<adam3us> kanzure: I was thinking the same. iddo wrote up a 2 page research note to capture publishing first to an improved fair coin toss. something like that'd do the trick. but this one could be far shorter. a sentence and QED.
<adam3us> kanzure: maybe you could submit it to the ledger journal :)
<kanzure> we can throw 30 or something coauthors on it
<kanzure> would be amusing
<adam3us> kanzure: apparently there are papers from CERN that have multipage author sheets :)
Guest25__ has joined #bitcoin-wizards
<kanzure> i wonder where i can find the latex template for that
amiller has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
<adam3us> one author would be enough i suspect.
dEBRUYNE has quit [Ping timeout: 250 seconds]
<adam3us> uh there are downloads on bitcoin-unlimited. what does it do?
<Eliel_> I guess it's a fork of Bitcoin without a block size limit.
GGuyZ has quit [Quit: GGuyZ]
Emcy has quit [Ping timeout: 264 seconds]
yossso has joined #bitcoin-wizards
amiller has quit [Ping timeout: 256 seconds]
<alpalp> from what I understand in its current state it basically is command line options to set the block limit independently.
<alpalp> Gavin did some very basic code review of it and basically said in the nicest manner that it was garbage code
<alpalp> but its a lot of hand-wavy "the market will decide" stuff
JackH has quit [Ping timeout: 276 seconds]
JackH has joined #bitcoin-wizards
<bramc> When I first started digging into bitcoin one of my central questions was 'what is there to stop someone from doing a DoS by creating lots of transactions?' The answer, of course, is the block size limit, which is ugly, functional, and completely necessary
<dgenr8> BU currently has no features, other than what alpalp describes. the idea seems to be to create an organization, which then creates software as a side-effect. old school.
<alpalp> in the end, miners will end up limiting blocksize to maximize revenue - right now doesnt matter
<phantomcircuit> alpalp, i doubt it
<alpalp> phantomcircuit: very long term when subsidy is low - cartel behavior will dictate a restriction of supply to increase price
<phantomcircuit> alpalp, that only works if there's pretty extreme centralization in mining
<alpalp> im not sure thats true if they can signal and soft fork to punish cheaters
dEBRUYNE has joined #bitcoin-wizards
<alpalp> the problem with cartels is a lack of enforcement against cheaters
<bramc> alpalp, miners have trouble restricting the supply of transactions because their incentives are very strongly to cheat
yossso has quit [Read error: Connection reset by peer]
<alpalp> bramc: I believe you are referring to restricting through a soft limit rather than an orphaning strategy
<alpalp> with that I agree 100%
<alpalp> of course much of this depends on the elasticity of price demand
<bramc> alpalp, In the very long term either transaction fees will go up or bitcoin will fall into obscurity
<alpalp> bramc: aggregate fees?
Guyver2 has quit [Quit: :)]
<bramc> alpalp, Don't know what you're asking
<alpalp> the total transaction fees collected vs. price.
belcher has joined #bitcoin-wizards
<alpalp> it may be the case that the fee paid today remains constant, # of transactions go up. Or fee goes up, #transactions constant, or something between. All would be economically feasible
<dgenr8> replacing the cheapest tx in a block with a higher fee gives miner benefit = newfee - oldfee. allowing the extra tx instead gives benefit = oldfee
<bramc> dgenr8, Let's do a long term permanent reduction in bitcoin's security by a factor of 2! That will fix everything!
<alpalp> the point is miners can quite easily set an artificial supply limit as a cartel and punish anyone who disobeys through orphaning, so long as they had reason to believe the majority would go along.
<alpalp> dgner8: except its not isolated that much. An artificial restriction in space allows for those to pay closer to what they value the transaction being included at, rather than the cost to produce.
<phantomcircuit> alpalp, as bramc said the incentive to cheat even with a soft fork is very very strong
<dgenr8> bramc: that assumes facts not in evidence regarding security as a function of blocksize
<bramc> dgenr8, He's proposing making half of all fees go into the bitbucket, and long term security is directly based off the value of fees
<alpalp> phantomcircuit: i disagree but there is not much to do other than speculate. risk of disobeying is high, benefit of including a few extra transactions is on the lower side. But game theory will dictate it. If miners can have a high level of confidence in a large amount of agreement (say 75% even), then the orphan risk is significant.
<alpalp> but game theory in these situations are complex and hard to predict perfectly, i will certainly admit that
<bramc> dgenr8, I have no idea why he think that would help as an anti-spam measure. In the current system there's a hack in place where the number of active transactions can't be greater than the number of utxos and the priority of each transaction is age * size, which works well enough for now but is a strictly temporary hack
<dgenr8> bramc: I agree raystonn's solution is not attractive. i was just highlighting that fees are a general spam deterrent. De-incentivizing unconfirmed chains somehow is a better way to address miner spam
<bramc> dgenr8, I've been most public about bluntly stating that mining fees are the one true way of deterring transaction spam, so no need to convince me of that. Not sure what you mean about unconfirmed chains. Of course mining old chains gets you orphaned immediately these days.
yossso has joined #bitcoin-wizards
<alpalp> bramc: unconfirmed chains of transactions. Z spends Y which spends X which spends W which spends ... A
Burrito has quit [Ping timeout: 260 seconds]
<alpalp> adds a lot to the mempool of nodes
ratbanebo has quit []
<bramc> alpalp, The fix is for mempools to have a fixed size and drop things whose fee/byte is too low. Child pays does complicate that logic a lot.
<raedah> bramc, when I think of spam I dont think if too many active transactions. I think of low value transactions that are bloating the size of the blockchain and using the collective storage resource.
<bramc> raedah, That's what I'm referring to as well. Whether the transactions are created out of malice or inconsideration is besides the point.
<dgenr8> bramc: bingo. also i like child-alone-pays-for-all-parents. that would really favor not building chains, while still allowing it with higher fees or waiting for parents to confirm
<phantomcircuit> alpalp, it depends entirely on how large the reduction is of course
<bramc> phantomcircuit, That's an interesting question: If x% of the network decided to orphan blocks which weren't at least y% small, how big would x have to be for a given y? And once it was globally enforced, could you repeat the pattern again?
<alpalp> bramc: you still need to get that data at some point to compare, which can be a ddos.
<bramc> alpalp, What data? I don't know what you're trying to say.
<raedah> There are two justifications for the blocksize limit, neither of which make sense to me. One, to prevent DoS, but no one has shown what this attack is or why a blocksize limit would prevent it rather then some other measure. Second, to create a fee market, to which I say, why dont miners just create smaller blocks and devs can provide miners with better transaction inclusion algos.
<alpalp> the transactions to compare to the mempool to see if they have enough fees
<bramc> phantomcircuit, I'm not going to work out the details though, because evil people don't need any more help.
<alpalp> phantomcircuit: It depends a lot on the demand curve and elasticity and how long term they are thinking.
<dgenr8> alpalp: You switched away from the miner perspective. My point is, to maximize total fees, a miner should prefer 1 more tx, rather than a higher fee on the last tx. Given the choice.
<bramc> raedah, Better transaction including algorithms, and related ecosystem things like replace by fee, are very much an active area of work.
<bramc> dgenr8, I haven't thought through all the edge cases of child pays. It sounds migraine inducing.
trippysalmon has quit [Ping timeout: 250 seconds]
<alpalp> dgenr8: that's incorrect though. miners have marginal costs and if you can increase the fee everyone pays, that adds up * # of transactions.
<alpalp> this is econ 101 stuff tho
<alpalp> peter r might even be competent at that
<dgenr8> alpalp: econ 101 says you cannot increase the fees everyone pays. only what is paid at the margin.
<dgenr8> peter r goes the next step, and asks what stops this logic from implying an infinite blocksize
<raedah> dgenr8, block transfer time obviously
yossso has quit [Ping timeout: 240 seconds]
<adam3us> raedah no. if miners mine on a pool there is no block-transfer time to themselves
dEBRUYNE_ has joined #bitcoin-wizards
<adam3us> raedah: similar if they use SPV mining, which the 4th jul fork showed over 50% were doing
<raedah> adam3us, the miner would never finish creating the infinite sized block, and would never transfer it to the rest of the bitcoin network.
<adam3us> raedah: similar for relay network which does network compression and is used by big portion of hashrate today.
STRML has quit [Read error: Connection reset by peer]
<raedah> adam3us, SPV mining, or not validating blocks, is itself a security problem.
<adam3us> raedah: think somewhere between 1MB and infinite. say 1GB. i dont have to validate blocks i create - i created them.
<adam3us> raedah: right one with no known solution that unlimited blocks makes catastrophic
<raedah> adam3us, doesnt matter if the creator doesnt validate. If the rest of the network doesnt accept the block, its irrelevant.
STRML has joined #bitcoin-wizards
<instagibbs> raedah, why would you not accept the block? everyone else is accepting it. Probably. Maybe phone a friend?
dEBRUYNE has quit [Ping timeout: 265 seconds]
<adam3us> raedah: there are two thresholds: tolerable transfer for orphan risk; and tolerable transfer for data center hosted full nodes. the latter can receive the block in 10mins. the former wants it in < 5 seconds.
<phantomcircuit> instagibbs, lol
<raedah> instagibbs, yes, thats the directoin I was thinking. Sync up with economic peers on valid chain.
<instagibbs> I bet bc.i will tell me what the leading block is
<adam3us> raedah: SPV nodes do not validate blocks. this trend pushes most users to SPV
<instagibbs> raedah, i was kidding. It kind of devolves into phone-a-friend which is a completely different security model.
<raedah> adam3us, i thought it was already determined that spv was bad practice for any important node. obivous bad to accept invalid transactions.
<raedah> instagibbs, the existing protocol already requires peers. just strangers, not friends.
<adam3us> raedah: the security fo the network depends on a reasonable proportion of economically dependent full nodes validating
<instagibbs> raedah, except I have to guess out of band if other people are following a block due to block size/validation vost, versus now.
<raedah> instagibbs, actually you can define ip connections, but you cant prioritize agreement with their values.
<adam3us> raedah: evidently > 50% of the network at times is SPV mining. they can do that at any block-size below that which causes even transfer to backup across 10mins.
<instagibbs> #bitcoin level stuff tbh
oneeman has quit [Quit: Leaving]
oneeman has joined #bitcoin-wizards
GGuyZ has joined #bitcoin-wizards
dEBRUYNE__ has joined #bitcoin-wizards
<kanzure> a46d0242496012179297ec6276865dcb609cfeef5164db95030b76c40cd75cd7
dEBRUYNE_ has quit [Ping timeout: 256 seconds]
<bramc> kanzure, No private keys in the channel please
<kanzure> nah it's just a hash of an email i sent to george church
DougieBot5000_ has joined #bitcoin-wizards
hashtagg_ has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
DougieBot5000 has quit [Killed (holmes.freenode.net (Nickname regained by services))]
DougieBot5000_ is now known as DougieBot5000
hashtag_ has quit [Ping timeout: 250 seconds]
argh_ has joined #bitcoin-wizards
ggreer has quit [Ping timeout: 250 seconds]
BlueMatt_ has joined #bitcoin-wizards
luke-jr_ has joined #bitcoin-wizards
kisspunch_ has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 250 seconds]
ggreer has joined #bitcoin-wizards
jlyndon_ has joined #bitcoin-wizards
lomax___ has joined #bitcoin-wizards
mhanne_ has joined #bitcoin-wizards
s1w has joined #bitcoin-wizards
<brg444> Happy new year to the wizards! Thank you for all the hard work and resilience you've shown throughout last year. I'm hopeful 2016 will prove to everyone how right and just you were in hindsight. Keep cooking the good stuff! Cheers
s1w is now known as Guest5401
bitkarma_ has joined #bitcoin-wizards