#bitcoin-wizards

/

      • leakypat joined the channel
      • 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?
      • kanzure
      • bsm1175321
        Oh yeah that one. I read it a while ago...I'll look again.
      • 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.
      • 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/bitc...
      • CubicEar_ joined the channel
      • hashtag joined the channel
      • pozitron joined the channel
      • 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
      • 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 joined the channel
      • 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 joined the channel
      • 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
      • is there a credible article by any chance that details what is going to happen to btc in the near future? (1-3 years)
      • 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
      • you should try #bitcoin, #bitcoin-mining, or ##bitcoin (i'm not kidding!)
      • davec joined the channel
      • 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
      • 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
      • where do I go to ask about that / get some kind of comment?
      • adlai
        merlincorey: /dev/null
      • 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
      • 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
      • adam3us
        merlincorey: kind of OT for here but related reddit thread https://www.reddit.com/r/Bitcoin/comments/3yqe7...
      • merlincorey
        thanks adam3us pointers to more was all I was hoping for
      • there's a lot of noise and very little signal with a lot of bitcoin things
      • 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 joined the channel
      • 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
      • adlai: that I am
      • anyway thanks again for the pointer and sorry for the added noise
      • jcorgan
        i give up
      • merlincorey goes back to lurking
      • jcorgan has left the channel
      • 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
      • kanzure: but again thanks for the pointer :P
      • merlincorey furiously reads on the train
      • 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...
      • ;;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 joined the channel
      • frankenmint joined the channel
      • 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
      • cheetah2 has quit
      • leviathaan has quit
      • GAit has quit
      • tulip joined the channel
      • tulip
        > < adlai> NOPs are a scarce resource
      • cheetah2 joined the channel
      • 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
      • 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
      • 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 joined the channel
      • 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
      • 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"
      • 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 joined the channel
      • adlai
        cross-chain swaps involve more programming than most "hello world" examples
      • cheetah2 has quit
      • tulip
        Bitcoin Script is still the wrong way to do most things.
      • Cory joined the channel
      • adlai goes eat, but would love to see examples
      • go1111111 has quit
      • 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
      • melvster1 joined the channel
      • go1111111 joined the channel
      • 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 joined the channel
      • CubicEarth joined the channel
      • CubicEarth has quit
      • CubicEarth joined the channel
      • bonus points, explain why OP_VER is disabled.
      • cheetah2 joined the channel
      • wallet42 has quit
      • alpalp
        OP_VER will just push the version on the stack, OP_VERIF will compare the verison to a value.
      • trippysalmon has quit
      • 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 joined the channel
      • cheetah2 has quit
      • 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.
      • gielbier has quit
      • tulip has quit
      • NewLiberty has quit
      • bramc
        Bitcoin never really has 'rough consensus' more like 'clear majority of actual developers'
      • tulip joined the channel
      • 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/... )
      • 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
      • 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 joined the channel
      • cheetah2 has quit
      • 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.