#bitcoin-wizards

/

      • Taek
        if I understand the scheme fully, it encourages the miners to prefer taking all fees oob, but it encourages users to pay all fees on-chain using the mechanism that could get them a discount
      • and if a miner is unable to take certain fees oob, then they have to sacrifice all potential revenue from users that are using on-chain fees
      • I guess you could end up with an equilibrium where X% of blocks are fully oob, and then the rest are on-chain fees
      • but then if you are paying oob, you know you can only get into blocks X% of the time
      • well, same with on-chain too. If oob is >>50%, then it's probably something that would perpetuate
      • pro joined the channel
      • techguy305 joined the channel
      • techguy305
        hey
      • techguy305 has left the channel
      • punindented has quit
      • pro has quit
      • Belkaar has quit
      • Belkaar joined the channel
      • Belkaar has quit
      • Belkaar joined the channel
      • BashCo has quit
      • jb55 has quit
      • jb55 joined the channel
      • luke-jr joined the channel
      • priidu has quit
      • BashCo joined the channel
      • maaku
        gmaxwell: I'm not sure why you're not seeing the all-or-nothing as an advantage, not a weakness. that's the argument from the other side -- it discourages out of band fees existing alongside regular fees
      • you build a block containing either one or the other -- regular fees or out-of-band-payments. not both. not some of each.
      • and in that model, it's the user incentive not to do out of band fees, because that only works if everyone does it, and if everyone does it it is strictly worse (because no rebates) than if everyone used regular fees
      • Ylbam has quit
      • _whitelogger joined the channel
      • jb55 has quit
      • dnaleor has quit
      • BashCo_ joined the channel
      • CryptAxe joined the channel
      • Emcy_ joined the channel
      • BashCo_ has quit
      • jb55 joined the channel
      • jb55 has quit
      • legogris has quit
      • legogris joined the channel
      • _whitelogger joined the channel
      • TheSeven joined the channel
      • jb55 joined the channel
      • jb55 has quit
      • TheSeven joined the channel
      • Letze has quit
      • Letze joined the channel
      • jb55 joined the channel
      • CheckDavid joined the channel
      • onabreak joined the channel
      • c0rw1n_ has quit
      • luke-jr
        maaku: updated the BIP draft & code with your suggestions BTW
      • _whitelogger joined the channel
      • _whitelogger joined the channel
      • deusexbeer has quit
      • deusexbeer joined the channel
      • dnaleor joined the channel
      • Chris_Stewart_5 joined the channel
      • Ylbam joined the channel
      • d9b4bef9 has quit
      • d9b4bef9 joined the channel
      • Guyver2 joined the channel
      • CheckDavid joined the channel
      • Chris_Stewart_5 has quit
      • luke-jr joined the channel
      • Chris_Stewart_5 joined the channel
      • rusty joined the channel
      • jb55 has quit
      • BashCo joined the channel
      • Chris_Stewart_5 has quit
      • jtimon joined the channel
      • Chris_Stewart_5 joined the channel
      • Chris_Stewart_5 has quit
      • BashCo_ joined the channel
      • BashCo has quit
      • dnaleor has quit
      • BashCo_ has quit
      • meshcollider joined the channel
      • BashCo joined the channel
      • dnaleor joined the channel
      • laurentmt joined the channel
      • eck joined the channel
      • c0rw1n_ joined the channel
      • daszorz joined the channel
      • BashCo_ joined the channel
      • BashCo has quit
      • dnaleor has quit
      • daszorz has quit
      • Emcy_ has quit
      • Emcy joined the channel
      • laurentmt joined the channel
      • dnaleor joined the channel
      • Noldorin joined the channel
      • laurentmt joined the channel
      • laurentmt has quit
      • dnaleor has quit
      • meshcollider has quit
      • dnaleor joined the channel
      • laurentmt joined the channel
      • Chris_Stewart_5 joined the channel
      • jtimon joined the channel
      • arowser has quit
      • arowser joined the channel
      • Chris_Stewart_5 has quit
      • Chris_Stewart_5 joined the channel
      • laurentmt joined the channel
      • PaulCapestany joined the channel
      • priidu joined the channel
      • laurentmt joined the channel
      • Chris_Stewart_5 has quit
      • AaronvanW joined the channel
      • Chris_Stewart_5 joined the channel
      • laurentmt joined the channel
      • maaku
        luke-jr: I was going to suggest moving the 520 push limitation too, but unfortunately that's enforced for all witness types :(
      • It's only there because of implementation issues that could fully be resolved in script, and I don't know why it would exist for non-script witness types
      • dnaleor has quit
      • Aranjedeath joined the channel
      • Chris_Stewart_5 joined the channel
      • dnaleor joined the channel
      • luke-jr
        maaku: eh, no it isn't?
      • dnaleor has quit
      • adiabat has quit
      • sipa
        maaku: no, it's not
      • Aaronvan_ joined the channel
      • AaronvanW has quit
      • Aaronvan_ has quit
      • AaronvanW joined the channel
      • maaku
        sipa: explain?
      • there's no opcodes that modify large stack operations. DUP could have reference counting semantics
      • *large stack items
      • MaxSan joined the channel
      • sipa
        maaku: ?
      • daszorz joined the channel
      • the 520 byte limit only applies to witness v0
      • and not to the p2wsh program, only to its initial stack
      • maaku
        outside of DUP bombs, which are solved by reference counting instead of duplicating, I don't know of any way a single 520kB push is any worse than 1,000 520b pushes, other than filling the script with repeated dup/hash, which can be trivially prevented with hash limits based on witness size
      • BashCo joined the channel
      • sipa: Ah, you're right. I misread VerifyWitnessProgram when I looked into this earlier.
      • sipa
        the main reason for the limit is that there is no use for large data elements - for now
      • BashCo_ has quit
      • dnaleor joined the channel
      • and with the program itself no longer falling under that limit, even more so
      • maaku
        It's possible tail-call scripts might want larger than 520 byte subscripts. Possible; I don't know of any examples. MAST itself reduces the maximum subscript size needed considerably.
      • But a stronger justification is Merkle branch proofs, for which 520 bytes is quite limiting
      • intcat joined the channel
      • sipa
        i realized yesterday that if you have a sufficiently large merkle tree, an rsa accumulator would be more efficient instead, to produce set inclusion
      • maaku
        any idea what that cutoff woul be?
      • sipa
        in size, probably at 24 levels
      • maaku
        *would be; and can you compactly prove multiple elements?
      • sipa
        yes!
      • constant size
      • it's also much more cpu intensive to verify...
      • if you use 3072-bit arithmetic (~128 bit security), i think the proof would be 768 bytes
      • luke-jr
        do we need new opcodes still?