Thomas Hartman [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-08-16 to 2023-05-01
💬 Posted a total of 10 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:21:13

- reply

📅 Original date posted:2023-05-01
🗒️ Summary of this message: A new paper presents a formalization of the Powswap protocol, called Blockrate Binaries, which are off-chain contracts for peer-to-peer binary contracts on the future rates of block discovery between two users on the Bitcoin mainnet. The paper describes the protocol steps in detail, including the threat model, and discusses issues around contention at the most basic level, leaving advanced mining-related game theory for future research. The paper also discusses the infrastructure required for counterparty discovery and selection, and the potential for Blockrate Binary Options to operate on top of Lightning payment channels.
📝 Original message:Greetings!
We are presenting a paper: “Blockrate Binaries on Bitcoin mainnet.”
This is a formalization of the previously known Powswap[1] protocol.
These hashrate derivatives are off-chain contracts to make
peer-to-peer binary contracts on the future rates of block discovery
between two users.
Link: https://github.com/blockrate-binaries/paper/blob/master/blockrate-binaries-paper.pdf
(also attached here)
Sha256 of current version of paper:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
We describe protocol steps in detail and the threat model, which
largely overlaps with other protocols (e.g., eclipse, pinning, miner
bribe). A unique characteristic of this protocol is contentions -- ie
transaction confirmation racing -- in edge cases. We discuss issues
around contention at the most basic level, leaving advanced
mining-related game theory for future research.
Deploying these contracts at scale would require novel infrastructure
for counterparty discovery and selection, which we describe in the
paper. Part of this infrastructure could be shared with Discreet Log
Contracts or other protocols.
Blockrate Binary Options could operate on top of Lightning payment
channels, although the exact construction requires further protocol
design, especially for the routed version. We briefly discuss this, as
well as other potential advancements for these contracts.
It is yet to be established whether Blockrate Binary options are
useful financial tools for Bitcoin users. We believe that they may be
useful to miners for hedging their operations; and to all Bitcoin
users by making Bitcoin a more salable asset through bridging it to
real-world energy flows and providing a decentralized price indicator
and a means of derivative trading.
We welcome protocol researchers to help us solve the remaining
blockers. Most important are contention and lightning compatibility.
We also invite experienced core and lightning software developers who
can work out a beta implementation to start trying this out
"recklessly" in the not too distant future.
If there is interest, we will set up infrastructure for community
forums and contributions soon.
Thanks Gleb Naumenko and Antoine Riard for so much careful thought and
work. And thanks to Nadav Kohen for review before publication.
Private inquiries can be directed to myself at this email.
1 Powswap was originally introduced by Jeremy Rubin. See powswap.com
and Advent Day 24.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blockrate-binaries-paper.pdf
Type: application/pdf
Size: 482931 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230501/6d45ee2c/attachment-0001.pdf>

2023-06-07 18:30:21

- reply

📅 Original date posted:2021-03-14
📝 Original message:MY LORD HIS EXCELLENCY:
It is indeed a contest between free markets and central planning.
Governments can in effect say, you are permitted to buy energy to
smelt aluminum, but not to mine bitcoin, even if bitcoin is more
profitable.
To the extent that free markets in energy are suppressed, as you
pointed out in china, bitcoin can indeed be suppressed.
The solution is not to make bitcoin a centrally managed currency,
but to fight hard for free speech, free markets, and in particular
free markets in energy.
That being said, bitcoin is designed to thrive even if driven underground.
Your humble subject etc.
On Sun, Mar 14, 2021 at 9:41 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good Afternoon,
>
> It is obvious that something needs to be done to curtail the current cost of mining in kWh per block. I understand proposals are rejected because it is considered censorship and Bitcoin has a consensus to allow anyone to mine but, since mining requires specific hardware and energy requirements it is already a form of censorship where most on the planet except for the top 6% I am guessing here, cannot afford to mine. Without affecting the current algorithm, I have previously begun to explore the process by which mining can be turned into a lottery with only authorized payto addresses able to mine valid blocks, since transaction fees and block rewards exist to pay the miner. It would be better even if the algorithms are improved if there are some ways that only a subset of miners can produce valid blocks for any given period, say for 12 months with four groups starting three months apart to transition, and maybe limit mining to 50 people per continent to produce valid blocks at any one time. Possibly this requires a consortium to oversee the lottery but it is something Bitcoin can handle themselves, and would do better to handle than to wait for government intervention as we have seen previously in China where power was too cheap Bitcoin was banned entirely.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> and other projects
>
> earn.com/willtech
> linkedin.com/in/damianwilliamson
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email if misdelivered.
> ________________________________
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Lonero Foundation via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Saturday, 6 March 2021 3:16 AM
> To: Devrandom <c1.devrandom at niftybox.net>
> Cc: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining
>
> Also in regards to my other email, I forgot to iterate that my cryptography proposal helps behind the efficiency category but also tackles problems such as NP-Completeness or Halting which is something the BTC network could be vulnerable to in the future. For sake of simplicity, I do want to do this BIP because it tackles lots of the issues in regards to this manner and can provide useful insight to the community. If things such as bigger block height have been proposed as hard forks, I feel at the very least an upgrade regarding the hashing algorithm and cryptography does at least warrant some discussion. Anyways I hope I can send you my BIP, just let me know on the preferred format?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <loneroassociation at gmail.com> wrote:
>
> Hi, this isn't about the energy efficient argument in regards to renewables or mining devices but a better cryptography layer to get the most out of your hashing for validation. I do understand the arbitrariness of it, but do want to still propose a document. Do I use the Media Wiki format on GitHub and just attach it as my proposal?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom at niftybox.net> wrote:
>
> Hi Ryan and Andrew,
>
> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> https://www.truthcoin.info/blog/pow-cheapest/
> "Nothing is Cheaper than Proof of Work"
> on | 04 Aug 2015
>
>
> Just to belabor this a bit, the paper demonstrates that the mining market will tend to expend resources equivalent to miner reward. It does not prove that mining work has to expend *energy* as a primary cost.
>
> Some might argue that energy expenditure has negative externalities and that we should move to other resources. I would argue that the negative externalities will go away soon because of the move to renewables, so the point is likely moot.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:29:36

- reply

📅 Original date posted:2021-03-03
📝 Original message:“all transactions should be open to the scrutiny of an honest government”
I agree with this. However, scrutiny does not imply dragnet surveillance.
Bitcoin returns us, or at least aspires to return, to the days of a gold standard.[0] You will be familiar with this, from your time in Her Majesty’s empire.
In these days, scrutiny implied detectives asking questions. Perhaps they would ask questions of multiple parties and see if certain numbers matched. There was no dragnet surveillance, and this as god intended.
We return to these days soon.
I agree with your point about consensus as well. You are free to run a node supporting a dragnet surveillance fork, and sell your coins that support gold-like privacy to accumulate more dragnet surveillance coins. I wish you success with that.
[0]: https://taaalk.co/t/bitcoin-maxima-other-crypto-things
> On Mar 2, 2021, at 9:54 PM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good Afternoon,
>
> All people are entitled to privacy in their purse, and all transactions should be open to the scrutiny of an honest government. You can debate whether any government is honest. Mixing does not remove the record from the public ledger, where it is possible to see that any Bitcoin has transferred from an UTXO to some Pay-To address even with some amount of transaction in between them. The value proposition is the samehttps://www.youtube.com/watch?v=l9jOJk30eQs <https://www.youtube.com/watch?v=l9jOJk30eQs> - because people will trust the system; people trust the existing consensus.
>
> Let us dispense with the screen and deal with the issue only. If it is not necessary to maintain consensus then what is consensus?
>
> The intrinsic value of Bitcoin is because of the existing consensus. Even if any proposal gains consensus there is no objective way to show it improves the intrinsic value without trialing and the possibility of failure and so protecting the existing consensus should be the highest value. This understanding is the reason BCH exists in addition to BTC Bitcoin.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>
> Willtech
> www.willtech.com.au <x-msg://6/www.willtech.com.au>
> www.go-overt.com <x-msg://6/www.go-overt.com>
> and other projects
>
> earn.com/willtech <http://earn.com/willtech>
> linkedin.com/in/damianwilliamson <http://linkedin.com/in/damianwilliamson>
>
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email if misdelivered.
> From: Eric Voskuil <eric at voskuil.org>
> Sent: Tuesday, 2 March 2021 9:37 AM
> To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Cc: Ariel Lorenzo-Luaces <arielluaces at gmail.com>
> Subject: Re: [bitcoin-dev] Taproot NACK
>
> To be clear, is this a NACK because Taproot reduces “transparency” (increases privacy) on the chain (“maintaining consensus” is obviously an argument against any protocol change, so that’s a red herring)?
>
> And is it your theory that only an “honest” (statute abiding) person should have privacy, and not against the state, and/or that mixers are sufficient privacy?
>
> Personally, I’m not moved by such an argument. What do you think is the value proposition of Bitcoin?
>
> e
>
>> On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> Good Afternoon,
>>
>> I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.
>>
>> My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.
>>
>> The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.
>>
>> My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.
>> <ip.bitcointalk.org.png>
>>
>> [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
>> https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw <https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw>
>> from this thread https://bitcointalk.org/index.php?topic=5267588 <https://bitcointalk.org/index.php?topic=5267588>
>>
>>
>> The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,
>> https://github.com/jambler-io/bitcoin-mixer <https://github.com/jambler-io/bitcoin-mixer>
>>
>> The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.
>> https://jambler.io/become-partner.php <https://jambler.io/become-partner.php>
>>
>> I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.
>>
>> If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au
>> www.go-overt.com
>> and other projects
>>
>> earn.com/willtech
>> linkedin.com/in/damianwilliamson
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this email if misdelivered.
>> From: Ariel Lorenzo-Luaces <arielluaces at gmail.com>
>> Sent: Monday, 1 March 2021 12:07 AM
>> To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Taproot NACK
>>
>> Hello LORD HIS EXCELLENCY JAMES HRMH
>>
>> I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com <http://www.go-overt.com/>
>>
>> At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.
>>
>> Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.
>>
>> Cheers
>> Ariel Lorenzo-Luaces
>> On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> Good Evening,
>>
>> Thank-you for your advice @JeremyRubin <https://twitter.com/JeremyRubin> on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.
>>
>> Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.
>>
>> The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au <applewebdata://11E32DCD-CD1E-4591-8DD3-704BCD700ABC>
>> www.go-overt.com <applewebdata://11E32DCD-CD1E-4591-8DD3-704BCD700ABC>
>> and other projects
>>
>> earn.com/willtech
>> linkedin.com/in/damianwilliamson
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this email if misdelivered.
>> From: Jeremy <jlrubin at mit.edu>
>> Sent: Sunday, 28 February 2021 3:14 AM
>> To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Taproot NACK
>>
>> I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.
>>
>> Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.
>>
>> Do you have a source on your reporting?
>>
>> You may wish to rescind your nack.
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin>
>>
>> On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> Good Afternoon,
>>
>> It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.
>>
>> If that is the case I offer a full NACK and let me explain.
>>
>> A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.
>>
>> I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au <http://www.willtech.com.au/>
>> www.go-overt.com <http://www.go-overt.com/>
>> and other projects
>>
>> earn.com/willtech <http://earn.com/willtech>
>> linkedin.com/in/damianwilliamson <http://linkedin.com/in/damianwilliamson>
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this email if misdelivered.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>>
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> <ip.bitcointalk.org.png>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210303/1d806698/attachment-0001.html>

2023-06-07 18:27:17

- reply

📅 Original date posted:2020-10-04
📝 Original message:"big to-network channel"
nit: should this be "big from-network channel" ?
thanks for this explanation.
On Sat, Oct 3, 2020 at 11:45 PM ZmnSCPxj via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good Morning Mr. Lee,
>
> > I cannot front up funds of my own to give
> > them inbound balance because it would consume all of my treasury to lock
> > up funds.
>
> This is not a reasonable assumption!
>
> Suppose you have a new hire that you have agreed to pay 0.042BTC every 2 weeks.
>
> On the *first* payday of the new hire, you *have* to have *at least* 0.042BTC in your treasury, somehow.
>
> If not, you are unable to pay the new hire, full stop, and you are doomed to bankruptcy and your problems will disappear soon once your cut-throat new hire cuts your throat for not paying her or him.
>
> If you *do* have at least 0.042BTC in your treasury, you *can* make the channel with the new hire and pay the salary via the new channel.
>
> At *every* payday, you need to have at least the salary of your entire employee base available, otherwise you would be unable to pay at least some of your employees and you will quickly find yourself with your throat cut.
>
>
>
>
> Now, let us talk about *topology*.
>
> Let us reduce this to a pointless topology that is the *worst possible topology* for Lightning usage, and show that by golly, Lightning will still work.
>
> Suppose your company only has this one big channel with the network.
> Let us reduce your company to only having this single new hire throat-cutter (we will show later that without loss of generality this will still work even if you have thousands of throat-cutters internationally).
>
> Now, as mentioned, on the first payday of your throat-cutter, you *have* to have at least the 0.042 salary you promised.
> If you have been receiving payments for your throat-cutting business on the big channel, that means the 0.042 BTC is in that single big channel.
>
> You can then use an offchain-to-onchain swap service like Boltz or Loop and put the money onchain.
> Then you can create the new channel to your new hire and pay the promised salary to the throat-cutter.
>
> Now, you have no more funds in either of your channels, the to-network big channel, and the to-employee channel.
> So you are not locking up any of *your* funds, only the funds of your employee.
>
> Now, as your business operates, you will receive money in your to-network big channel.
> The rate at which you receive money for services rendered *has to* be larger than 0.042/2weeks on average, *otherwise* you are not earning enough to pay your throat-cutter by the time of the *next* payday (much less your other operating expenses, such as knife-sharpening, corpse disposal, dealing with the families of the deceased, etc.).
> If you are not earning at a high enough rate to pay your employee by the next payday, your employee will not be paid and will solve your problems by cutting your throat.
>
> But what that means is that the employee salary of the *previous* payday is not locked, either!
> Because you are receiving funds on your big to-network channel continuously, the employee can now spend the funds "locked" in the to-employee channel, sending out to the rest of the network.
> This uses up the money you have been earning and moving the funds to the to-employee channel, but if you are running a lucrative business, that is perfectly fine, since you should, by the next payday, have earned enough, and then some, to pay the employee on the next payday.
>
> Of course there will be times when business is a little slow and you get less than 0.042/2weeks.
> In that case, a wise business manager will reserve some funds for a rainy day when business is a little slow, meaning you will still have some funds you can put into your to-network big channel for other expenses, even as your employee uses capacity there to actually spend their salary.
>
> It all balances out.
> You only need to keep enough in your channels to cover your continuous operational expenses, and employee salaries *are* operational expenses.
>
>
> Suppose you now want to hire *another* throat-cutter.
> You would only do that if business is booming, or in other words, if you have accumulated enough money in your treasury to justify hiring yet another employee.
>
> By induction, this will work regardless if you have 1 employee, or 1 million.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:26:40

- reply

📅 Original date posted:2020-09-02
📝 Original message:Replying to myself:
IIUC, Powswap seems to only create contracts from current time to future time.
But, you can create synthetic hashrate binaries for time span in the
future time A to time B, using powswap, by subtracting
(current time to B) - (current time to A)
IE, buy first, sell second.
On Tue, Sep 1, 2020 at 4:07 PM Thomas Hartman <thomashartman1 at gmail.com> wrote:
>
> This is in reply to David harding’s message at
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018129.html
>
> (For some reason didn’t arrive in my inbox, so I was late noticing it, and I am replying in this way. Sorry if it screws up threading.)
>
> Powswap sounds great! And it doesn’t require any protocol changes! Very cool.
>
> One potential problem I see with powswap is iiuc you need something like watchtowers, or the loser of the bet can sweep the funds if the winner is napping. Related, I’d also like to have trades happening in lightning channels, and I’m not sure how this race affects the security assumptions there.
>
> Further question about powswap.
>
> It’s currently block 64632 with retarget in 808 blocks. I’d like to bet that
>
> * the first 6 blocks after the retarget are found in under an hour
> * AND the new difficulty exceeds some threshold. Is such a bet currently possible with powswap?
>
> I see how pow swap lets you bet on hashrate (ie block times) from current time till some future time. But I would like to also bet on hashrate of slices of time in the future. Possible?
>
>

2023-06-07 18:26:39

- reply

📅 Original date posted:2020-09-01
📝 Original message:This is in reply to David harding’s message at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018129.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018129.html>
(For some reason didn’t arrive in my inbox, so I was late noticing it, and I am replying in this way. Sorry if it screws up threading.)
Powswap sounds great! And it doesn’t require any protocol changes! Very cool.
One potential problem I see with powswap is iiuc you need something like watchtowers, or the loser of the bet can sweep the funds if the winner is napping. Related, I’d also like to have trades happening in lightning channels, and I’m not sure how this race affects the security assumptions there.
Further question about powswap.
It’s currently block 64632 with retarget in 808 blocks. I’d like to bet that
* the first 6 blocks after the retarget are found in under an hour
* AND the new difficulty exceeds some threshold. Is such a bet currently possible with powswap?
I see how pow swap lets you bet on hashrate (ie block times) from current time till some future time. But I would like to also bet on hashrate of slices of time in the future. Possible?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200901/a447e8f1/attachment.html>

2023-06-07 18:26:35

- reply

📅 Original date posted:2020-08-19
📝 Original message:> On Aug 16, 2020, at 2:59 PM, Tier Nolan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Output 0: Pay Alice if diff < 1.00 trillion else Bob
What is included in blocks is a packed representation of the difficulty target, not the difficulty per se as typically reported on blockchain explorer.
https://en.bitcoin.it/wiki/Difficulty <https://en.bitcoin.it/wiki/Difficulty>
Perhaps what is best for speculation contracts is not the difficulty per se, but the ratio between some unknown future difficulty and the current difficulty. That is easily obtained from the packed representations already included in blocks. IE
Current difficulty / last difficulty = 1 / ( current target / last target )
To give a worked example, current difficulty is 16.94T, and last difficulty was 16.84T.
Current packed target is 0x17109bac, last packed target is 0x1710b4f8
16.94 / 16.84 is same as 1 / ( 0x109ba / 0x10b4f8 ) (the 17 is an exponent in both cases so leaving it out for clarity).
So perhaps the way op_diff should work is take 2 packed targets, 1 known and 1 unknown at time of contract, and return the ratio.
The contract could then work as previously described, except using the ratio for ticks instead of the difficulty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200819/4a4b1a9f/attachment.html>

2023-06-07 18:26:35

- reply

📅 Original date posted:2020-08-19
📝 Original message:>
> So perhaps the way op_diff should work is take 2 packed targets, 1 known and 1 unknown at time of contract, and return the ratio.
On second thought, I don’t think this is a good idea. The 32-bit packed difficulty target is equivalent to difficulty, and this is probably what should get pushed onto the stack. No division is needed, just the arithmetic less than operator, which is already live in script, using the tick strategy described by Tier. So it seems to me these contracts could truly be done with the addition of the single op_diff opcode. It’s probably less human readable to be using difficulty target instead of difficulty, but no one reads script anyway.
It was also bothering me that difficulty was a floating point number (I have floating point phobia), so it is great not to have to think about floats anymore!

2023-06-07 18:26:34

- reply

📅 Original date posted:2020-08-17
📝 Original message:Tier, AJ, ZmnSCPxj, thanks!
> On Aug 17, 2020, at 1:04 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200817/444a999a/attachment.html>

2023-06-07 18:26:33

- reply

📅 Original date posted:2020-08-16
📝 Original message:First, I would like to pay respects to tamas blummer, RIP.
https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer
Tamas proposed an additional opcode for enabling bitcoin difficulty
futures, on this list at
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg07991.html
I really like this idea.
1) Trusted third parties are security holes
https://nakamotoinstitute.org/trusted-third-parties/
and oracles (eg discreet log contracts) are really just trusted third
parties in a blockchain's clothing. So truly ttp-free oracle-free on
chain contracts are good.
2) Difficulty is a proxy for energy, which is a proxy for usd, which
is what everyone currently cares about, which is bad. Energy is real.
Bitcoin traders should care about future difficulty, not future usd
price.
So in sum I think this is a very good idea, and I would like to
continue this work. Ideally I would like to see to completion the BIP
that Tamas was unable to produce.
Some initial thoughts on the technical merits.
My understanding is that adding a single op_difficulty operation as
proposed would enable not true difficulty futures but binary options
on difficulty.
https://en.wikipedia.org/wiki/Binary_option
As the wikipedia article notes, "While binary options may be used in
theoretical asset pricing, they are prone to fraud in their
applications and hence banned by regulators in many jurisdictions as a
form of gambling." The trouble is that because of the all or nothing
nature binary options are more of a gamble than a hedge. They are
popular with scammers, and even licensed binary options exchanges such
as nadex are under constant scrutiny by regulators.
Because any form of trusted third party-free / oracle free speculation
would encourage economic use of blockchain space and support the
transaction fee market, perhaps an economic case can be made for naive
op_difficulty as above even it has more of a flavor of gambling than
hedging. I think at a psychological level it would be good for a
ttp-free difficulty speculation tool to capture mindshare.
That being said, true difficulty futures -- real hedging and not just
gambling -- would be far healthier for bitcoin than binary options. I
am trying to wrangle what additional opcodes and protocol changes
would be required beyond just op_difficulty, to get true difficulty
futures on chain.
I envision something like this. To give some context: Current
difficulty is 16.9 Trillion. We're a week in to the current difficulty
regime so there's aboout 1000 blocks to retarget, and predicted next
difficuly is 18.5 Trillion. So let's pretend we sell a difficulty
future that pays out in sats, of the next difficulty divided by a
trillion. A reasonable price for this would be, say, 17.4 sats.
So in our op_difficulty utxo, one address (the futures buyer) would
get current difficulty / trillion, and the other address (the seller)
would get however much value is locked in the utxo, minus that amount
and miner fee. The payout would be limited by however much value is
locked in the utxo. Since difficulty adjusts very slowly I don't think
overflowing the locked up value would be much of a problem in
practice. We also want a mechanism to enable on-chain purchase of such
a contract, say for 17.4 sats.
One additional opcode that apparently would be required is division.
Some version of rshift could also do.
I am not clear if there is a way to solve the accounting for the
payouts, but perhaps there is a way to do this with covenants.
I'm somewhat new to protocol and script. I would appreciate if anyone
has any further advice on this.
Cheers, Thomas.