[bitcoin-dev] Bitcoin Knots 0.20.1.knots20200815 released
Bitcoin Knots version 0.20.1.knots20200815 is now available from: https://bitcoinknots.org/files/0.20.x/0.20.1.knots20200815/ This release includes new features, various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: https://github.com/bitcoinknots/bitcoin/issues To receive security and update notifications, please subscribe to: https://bitcoinknots.org/list/announcements/join/ For the full release notes and change log, see: https://github.com/bitcoinknots/bitcoin/blob/v0.20.1.knots20200815/doc/release-notes.md signature.asc Description: This is a digitally signed message part. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] reviving op_difficulty
Good morning Thomas, > Tier, AJ, ZmnSCPxj, thanks! > > > On Aug 17, 2020, at 1:04 AM, ZmnSCPxj via bitcoin-dev > > wrote: > > > > Taproot MAST to the rescue. > > OK. So, using the tick scheme described by Tier a difficulty futures > instrument is possible with current script + op_diff; and with taproot + > op_diff (ZmnSCPxj) it may even be economical. (I will set aside covenants for > now.) > > To do it all on-chain, we need a mechanism for selling such an instrument in > a trustless way. > > That is to say (using ZmnSCPxj's construction), we have now a future where > Bob pays Alice a pico-difficulty at next adjustment. > > But how does Alice pay Bob his 17.4 sat? > > I am trying to figure out a way to do this naively using the base layer. (I > really want this with lightning, and eventually hft, but first things first.) > > My thinking so far is, Alice and Bob collaborate to create partial versions of > > ** the difficulty future funded by Bob, spendable by Alice in 1000 blocks > ** and a 17.4 sat payment from Alice to Bob, spendable by Bob immediately > > When Bob completes and broadcasts the payment from Alice, it should enable > Alice to complete and broadcast the difficulty future funded by Bob. > > I am thinking a hash lock on the payment, with a preimage secret generated by > Bob, could be used to accomplish this. When Bob unlocks and broadcasts the > payment, this reveals the preimage, and with the preimage Alice can unlock > and broadcast the difficulty future funded by Bob. > > Am I correct in thinking something like this could work? Bitcoin transactions on the blockchain layer are atomic, so it would be far simpler to make the purchase output and the options output in the same transaction, in a sort of PayJoin-like cooperatively-signed transaction. That said, the construction you are imagining is indeed going to work. The only requirement is that the hash-branch needs two signatures in order to ensure that it pays out to a transaction with a very specific contract. Xref. how Lightning *really* creates its HTLCs. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] reviving op_difficulty
On Mon, Aug 17, 2020 at 6:04 AM ZmnSCPxj wrote: > Taproot MAST to the rescue. > Another option would be a binary payout You pay 64 + 32 + 16 + 8 + 4 + 2 + 1 as outputs. The outputs are enabled/disabled based on the diff value. This would require division and also binary operators. D = (int) ((100 * diff) / (1 trillion)) Output 0: 1.28: If (D & 128) then pay Alice otherwise Bob Output 0: 0.64: If (D & 64) then pay Alice otherwise Bob Output 0: 0.32: If (D & 32) then pay Alice otherwise Bob Output 0: 0.16: If (D & 16) then pay Alice otherwise Bob Output 0: 0.8: If (D & 8) then pay Alice otherwise Bob Output 0: 0.4: If (D & 4) then pay Alice otherwise Bob Output 0: 0.4: If (D & 4) then pay Alice otherwise Bob Output 0: 0.4: If (D & 4) then pay Alice otherwise Bob This has log performance in terms of the number of ticks like the MAST solution. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup
Hi Suhas, It seems to me that your first two paragraphs contradict each other, so I’m not sure we have understanding. As you say in the first paragraph, a peer would never get messages that it does not understand, so there is no chance that missing a protocol change would matter. In case it’s not understood, version negotiation provides each peer with the maximum supported protocol version of the other. Once complete both have negotiated to the highest common version. No message not supported at that version may be sent by either. If the protocol was to accept *any* message traffic then it will cease to be a protocol. People will drop in their changes without obtaining broad support, and peers will evolve to the point of no longer being peers. They won’t speak the same language and the “network” will be little more than a broadcast transport, broadcasting all traffic to all peers, whether it’s for them or not. People need to either build support or build a distinct network. That’s the actual coordination issue, which is inherent to protocol development. Best, e > On Aug 17, 2020, at 13:40, Suhas Daftuar wrote: > > Hi Eric, > > Thanks for your response. If I understand correctly, you're suggesting that > in the future we do the same as what was done in BIP 339, of accompanying new > messages (which are optional) with a protocol version bump, so that network > clients are never reading unknown messages from a peer (and can be free to > disconnect a peer for sending an unknown message)? > > I think that works fine, so if indeed there will be software that will expect > things to operate this way then I can withdraw the suggestion I've made in > this thread. However I wanted to clarify that this is what you suggest, > because there is another downside to this approach (beyond the sequential > nature of sequence numbers that you mention) -- if a software implementation > misses a proposed new protocol upgrade, and thus fails to parse (and ignore) > some proposed new message, the result can be a network split down the road as > incompatible clients get slowly upgraded over time. > > I think this coordination cost is something to be concerned about -- for > instance, the lack of response to my wtxid-relay proposal made me wonder if > other software would be implementing something to account for the new message > that proposal introduces (for clients with version >= 70016). It's > reasonable for people to be busy and miss things like this, and I think it's > worth considering whether there's a safer way for us to deploy changes. > > That said, I don't think this coordination cost is unbearable, so as long as > we have a process for making p2p protocol improvements I'm not too worried > about what mechanism we use. So if this concern over coordination of changes > doesn't sway you, I think we can continue to just bump protocol version at > the same time as deploying new messages, as we have been doing, and hope that > we don't run into problems down the road. > > If I have misunderstood how you think we should be making future protocol > changes, please let me know. > > Thanks, > Suhas > > > >> On Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil wrote: >> A requirement to ignore unknown (invalid) messages is not only a protocol >> breaking change but poor protocol design. The purpose of version negotiation >> is to determine the set of valid messages. Changes to version negotiation >> itself are very problematic. >> >> The only limitation presented by versioning is that the system is >> sequential. As such, clients that do not wish to implement (or operators who >> do not wish to enable) them are faced with a problem when wanting to support >> later features. This is resolvable by making such features optional at the >> new protocol level. This allows each client to limit its communication to >> the negotiated protocol, and allows ignoring of known but >> unsupported/disabled features. >> >> Sorry I missed your earlier post. Been distracted for a while. >> >> e >> >> On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev wrote: >>> >>> Hi, >>> >>> Back in February I posted a proposal for WTXID-based transaction relay[1] >>> (now known as BIP 339), which included a proposal for feature negotiation >>> to take place prior to the VERACK message being received by each side. In >>> my email to this list, I had asked for feedback as to whether that proposal >>> was problematic, and didn't receive any responses. >>> >>> Since then, the implementation of BIP 339 has been merged into Bitcoin >>> Core, though it has not yet been released. >>> >>> In thinking about the mechanism used there, I thought it would be helpful >>> to codify in a BIP the idea that Bitcoin network clients should ignore >>> unknown messages received before a VERACK. A draft of my proposal is >>> available here[2]. >>> >>> I presume that software
Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup
Hi Eric, Thanks for your response. If I understand correctly, you're suggesting that in the future we do the same as what was done in BIP 339, of accompanying new messages (which are optional) with a protocol version bump, so that network clients are never reading unknown messages from a peer (and can be free to disconnect a peer for sending an unknown message)? I think that works fine, so if indeed there will be software that will expect things to operate this way then I can withdraw the suggestion I've made in this thread. However I wanted to clarify that this is what you suggest, because there is another downside to this approach (beyond the sequential nature of sequence numbers that you mention) -- if a software implementation misses a proposed new protocol upgrade, and thus fails to parse (and ignore) some proposed new message, the result can be a network split down the road as incompatible clients get slowly upgraded over time. I think this coordination cost is something to be concerned about -- for instance, the lack of response to my wtxid-relay proposal made me wonder if other software would be implementing something to account for the new message that proposal introduces (for clients with version >= 70016). It's reasonable for people to be busy and miss things like this, and I think it's worth considering whether there's a safer way for us to deploy changes. That said, I don't think this coordination cost is unbearable, so as long as we have a process for making p2p protocol improvements I'm not too worried about what mechanism we use. So if this concern over coordination of changes doesn't sway you, I think we can continue to just bump protocol version at the same time as deploying new messages, as we have been doing, and hope that we don't run into problems down the road. If I have misunderstood how you think we should be making future protocol changes, please let me know. Thanks, Suhas On Sun, Aug 16, 2020 at 3:06 PM Eric Voskuil wrote: > A requirement to ignore unknown (invalid) messages is not only a protocol > breaking change but poor protocol design. The purpose of version > negotiation is to determine the set of valid messages. Changes to version > negotiation itself are very problematic. > > The only limitation presented by versioning is that the system is > sequential. As such, clients that do not wish to implement (or operators > who do not wish to enable) them are faced with a problem when wanting to > support later features. This is resolvable by making such features optional > at the new protocol level. This allows each client to limit its > communication to the negotiated protocol, and allows ignoring of known but > unsupported/disabled features. > > Sorry I missed your earlier post. Been distracted for a while. > > e > > > On Aug 14, 2020, at 12:28, Suhas Daftuar via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Hi, > > Back in February I posted a proposal for WTXID-based transaction relay[1] > (now known as BIP 339), which included a proposal for feature negotiation > to take place prior to the VERACK message being received by each side. In > my email to this list, I had asked for feedback as to whether that proposal > was problematic, and didn't receive any responses. > > Since then, the implementation of BIP 339 has been merged into Bitcoin > Core, though it has not yet been released. > > In thinking about the mechanism used there, I thought it would be helpful > to codify in a BIP the idea that Bitcoin network clients should ignore > unknown messages received before a VERACK. A draft of my proposal is > available here[2]. > > I presume that software upgrading past protocol version 70016 was already > planning to either implement BIP 339, or ignore the wtxidrelay message > proposed in BIP 339 (if not, then this would create network split concerns > in the future -- so I hope that someone would speak up if this were a > problem). When we propose future protocol upgrades that would benefit from > feature negotiation at the time of connection, I think it would be nice to > be able to use the same method as proposed in BIP 339, without even needing > to bump the protocol version. So having an understanding that this is the > standard of how other network clients operate would be helpful. > > If, on the other hand, this is problematic for some reason, I look forward > to hearing that as well, so that we can be careful about how we deploy > future p2p changes to avoid disruption. > > Thanks, > Suhas Daftuar > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017648.html > > [2] > https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
Re: [bitcoin-dev] reviving op_difficulty
Tier, AJ, ZmnSCPxj, thanks! > On Aug 17, 2020, at 1:04 AM, ZmnSCPxj via bitcoin-dev > wrote: > > Taproot MAST to the rescue. OK. So, using the tick scheme described by Tier a difficulty futures instrument is possible with current script + op_diff; and with taproot + op_diff (ZmnSCPxj) it may even be economical. (I will set aside covenants for now.) To do it all on-chain, we need a mechanism for selling such an instrument in a trustless way. That is to say (using ZmnSCPxj's construction), we have now a future where Bob pays Alice a pico-difficulty at next adjustment. But how does Alice pay Bob his 17.4 sat? I am trying to figure out a way to do this naively using the base layer. (I really want this with lightning, and eventually hft, but first things first.) My thinking so far is, Alice and Bob collaborate to create partial versions of ** the difficulty future funded by Bob, spendable by Alice in 1000 blocks ** and a 17.4 sat payment from Alice to Bob, spendable by Bob immediately When Bob completes and broadcasts the payment from Alice, it should enable Alice to complete and broadcast the difficulty future funded by Bob. I am thinking a hash lock on the payment, with a preimage secret generated by Bob, could be used to accomplish this. When Bob unlocks and broadcasts the payment, this reveals the preimage, and with the preimage Alice can unlock and broadcast the difficulty future funded by Bob. Am I correct in thinking something like this could work? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
