Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining

2021-03-16 Thread Thomas Hartman via bitcoin-dev
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

Re: [bitcoin-dev] Taproot NACK

2021-03-04 Thread Thomas Hartman via bitcoin-dev
“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

Re: [bitcoin-dev] A thought experiment on bitcoin for payroll privacy

2020-10-04 Thread Thomas Hartman via bitcoin-dev
"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 wrote: > > Good Morning Mr. Lee, > > > I cannot front up funds of my own to give > > them inbound balance because it would consume all

Re: [bitcoin-dev] reviving op_difficulty

2020-09-02 Thread Thomas Hartman via bitcoin-dev
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.

Re: [bitcoin-dev] reviving op_difficulty

2020-09-01 Thread Thomas Hartman via bitcoin-dev
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

Re: [bitcoin-dev] reviving op_difficulty

2020-08-19 Thread Thomas Hartman via bitcoin-dev
> > 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

Re: [bitcoin-dev] reviving op_difficulty

2020-08-19 Thread Thomas Hartman via bitcoin-dev
> On Aug 16, 2020, at 2:59 PM, Tier Nolan via bitcoin-dev > 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.

Re: [bitcoin-dev] reviving op_difficulty

2020-08-17 Thread Thomas Hartman via bitcoin-dev
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

[bitcoin-dev] reviving op_difficulty

2020-08-16 Thread Thomas Hartman via bitcoin-dev
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