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

[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 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  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 o
 ne 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  on behalf 
> of Lonero Foundation via bitcoin-dev 
> Sent: Saturday, 6 March 2021 3:16 AM
> To: Devrandom 
> Cc: Bitcoin Protocol Discussion 
> 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  
> 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  wrote:
>
> Hi Ryan and Andrew,
>
> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev 
>  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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot NACK

[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 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 
>  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 
>  - 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 
> 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: Eric Voskuil 
> Sent: Tuesday, 2 March 2021 9:37 AM
> To: LORD HIS EXCELLENCY JAMES HRMH ; Bitcoin Protocol 
> Discussion 
> Cc: Ariel Lorenzo-Luaces 
> 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 
>>  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 

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

[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 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] reviving op_difficulty

[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.

On Tue, Sep 1, 2020 at 4:07 PM Thomas Hartman  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?
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] reviving op_difficulty

[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 
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? 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] reviving op_difficulty

[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 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!

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] reviving op_difficulty

[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. 

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.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] reviving op_difficulty

[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 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

[bitcoin-dev] reviving op_difficulty

[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

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev