Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-10-20 Thread ZmnSCPxj via bitcoin-dev



> Anecdata: c-lightning doesn't allow withdraw to segwit > 0. It seems
> that the contributor John Barboza (CC'd) assumed that future versions
> should be invalid:
>
> if (bip173) {
> bool witness_ok = false;
> if (witness_version == 0 && (witness_program_len == 20 ||
> witness_program_len == 32)) {
> witness_ok = true;
> }
> /* Insert other witness versions here. */

I believe this is actually my code, which was later refactored by John Barboza 
when we were standardizing the `param` system.

This was intended only as a simple precaution against creating non-standard 
transaction, and not an assumption that future versions should be invalid.
The intent is that further `else if` branches would be added for newer witness 
versions and whatever length restrictions they may have, as the `/* Insert 
other witness versions here.  */` comment implies.

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


Re: [bitcoin-dev] Progress on Miner Withholding - FPNC

2020-10-07 Thread ZmnSCPxj via bitcoin-dev
Good morning all,

>
> Below is a novel discussion on block-withholding attacks and FPNC. These are 
> two very simple changes being proposed here that will dramatically impact the 
> network for the better.
>
> But first of all, I'd like to say that the idea for FPNC came out of a 
> conversation with ZmnSCPxj's in regards to re-org stability.  When I had 
> proposed blockchain pointers with the PubRef opcode, he took the time to 
> explain to me concerns around re-orgs and why it is a bigger problem than I 
> initially had thought — and I greatly appreciate this detail.   After 
> touching base with ZmnSCPxj and Greg Maxwell there is an overwhelming view 
> that the current problems that face the network outweigh any theoretical ones.
>
> Currently the elephant in the room is the miner withholding attack. There is 
> an unintended incentive to hold onto blocks because keeping knowledge of this 
> coinbase private gives a greedy miner more time to calculate the next block.  
> Major mining pools are actively employing this strategy because winning two 
> blocks in a row has a much greater payoff than common robbery. This unfair 
> advantage happens each time a new block is found, and provides a kind of 
> home-field advantage for large pools, and contributes to a more centralized 
> network. This odd feature of the bitcoin protocol provides a material 
> incentive to delay transactions and encourages the formation of 
> disagreements. In a sense, withholding is a deception of the computational 
> power of a miner, and by extension a deception of their influence within the 
> electorate.  In effect, other miners are forced to work harder, and when they 
> are successful in finding a 2nd solution of the same height — no one 
> benefits. Disagreement on the bitcoin network is not good for the 
> environment, or for the users, or for honest miners, but is ideal for 
> dishonest miners looking for an advantage.

This is my understanding:

The selfish mining attack described above was already presented and known about 
**many years** ago, with the solution presented here: 
https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf

The solution was later determined to actually raise the needed threshhold to 
33%, not 25% in the paper.

That solution is what is used in the network today.

Implementing floating-point Nakamoto Consensus removes the solution presented 
in the paper, and therefore risks reintroducing the selfish mining attack.

Therefore, floating-point Nakamoto Consensus is a hard NAK.


Regards,
ZmnSCPxj

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


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

2020-10-05 Thread ZmnSCPxj via bitcoin-dev
Good morning Mr. Lee, and list,

> I can then look at the gossiped channels and see the size of the channel 
> between the cut-throat company and the other employee, and from there, guess 
> that this is the bi-weekly salary of that employee.


This can be made an argument against always publishing all channels, so let me 
propose something.

The key identifying information in an invoice is the routehint and the node ID 
itself.

There are already many competing proposals by which short-channel-ids in 
routehints can be obscured.
They are primarily proposed for unpublished channels, but nothing in those 
proposals prevents them from being used for published channels.

The destination node ID is never explicitly put in the onion, only implied by 
the short-channel-id in order to save space.
However, the destination node ID *is* used to encrypt the final hop in the 
onion.
So the receiver node can keep around a small number of throwaway keypairs (or 
get those by HD) and use a throwaway to sign the invoice, and when it is unable 
to decode by its normal node ID, try using one of the throwaway keypairs.

With both of the above, what remains is the feerate settings in the invoice.
If the company node gives different feerates per channel, it is still possible 
to identify which channel is *actually* referred to in the invoice.
What the receiver node can do would be to give a small random increase in 
feerate, which basically overpays the company node, but obscures as well 
*which* channel is actually in the invoice.

Regards,
ZmnSCPxj

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


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

2020-10-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Mr. Lee,


> Permanent raises can justify permanently increasing the size of the channel 
> with the employee.

On reflection, this is a bad idea.

Suppose I am a cut-throat employee and I want to have an idea of the bi-weekly 
salary of another employee.

I make some stupid bet, and lose, with the other employee.
I offer to pay the loss of my bet via Lightning, and the other employee, in all 
innocence, issues a Lightning invoice to me.

The Lightning invoice contains the actual node ID of the other employee.
And since I also have a channel with the cut-throat company, I know as well the 
node ID of the cut-throat company.

I can then look at the gossiped channels and see the size of the channel 
between the cut-throat company and the other employee, and from there, guess 
that this is the bi-weekly salary of that employee.

On the other hand --- once the employee has *any* funds at all, they can 
similarly take an offchain-to-onchain swap, and then use the funds to create 
another channel to another part of the network.
The other employee as well can arrange incoming funds on that other channel by 
using offchain-to-onchain swaps to their cold storage.
Thus, as an employee gets promoted and pulls a larger bi-weekly salary, the 
channel with the cut-throat company becomes less and less an indicator of their 
*actual* bi-weekly salary, and there is still some deniability on the exact 
size of the salary.

At the same time, even if I know the node of the other employee, the size of 
all its channels is also still not a very accurate indicator of their salary at 
the throat-cutting company.
For example, it could be a family node, and the other employee and all her or 
his spouses arrange to have their salaries paid to that node.
Or the other employee can also run a neck-reconstruction business on the side, 
and also use the same node.
(Nodelets for the win?)

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


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

2020-10-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Thomas,

> "big to-network channel"
>
> nit: should this be "big from-network channel" ?

As Lightning Network channels are bidirectional, it would be more properly 
"to/from-network", but that is cumbersome.
"to-network" is shorter by two characters than "from-network", and would be 
true as well (since the channel is bidirectional, it is both a "to-network" and 
"from-network" channel), thus preferred.


>
> thanks for this explanation.

You are welcome.

Regards,
ZmnSCPxj

> On Sat, Oct 3, 2020 at 11:45 PM ZmnSCPxj via bitcoin-dev
> bitcoin-dev@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 bal

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

2020-10-03 Thread ZmnSCPxj via bitcoin-dev
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


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

2020-10-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Mr. Lee,

> Lightning network is not much an option because they do not have
> inbound balance to get paid.

Why not?
Your company can open a channel with each employee that has insufficient 
inbound liquidity.
The employee is incentivized to reveal their node to your company so you can 
open a channel to them, since otherwise they would be unable to receive their 
salary.
Your alternative is as you say: openly-visible salaries and throat-cutters who 
might decide to cut your throat.

Let us say your company receives its income stream over Lightning.
Let us say you hire a new throat-cutter, with a bi-weekly salary of 0.042 BTC.
You ask the new hire if his or her Lightning node has that capacity.

If not, you take some of your onchain Lightning funds, swap out say 0.043 BTC 
on Lightning Loop or Boltz Exchange or some other offchain-to-onchain swap.
You use those swapped onchain funds to create a fresh channel to the new hire.

If you are onboarding by batches (which your HR is likely to want to do, so 
they can give the onboarding employee seminars in groups) then you can save 
onchain fees by using C-Lightning `multifundchannel` as well.

The occasional bonus can be a bit tricky, but similarly the employee can use 
Lightning Loop or Boltz Exchange or some other alternative to free up capacity 
for the bonus (and they have an incentive to do so, as they want to get the 
bonus).
Permanent raises can justify permanently increasing the size of the channel 
with the employee.

Even if the employee leaves your employ, that is no justification to close the 
channel with her or his node.
You can earn forwarding fees from his or her new employer or income source.

Because of the onion routing, it is hard for you to learn what the employee 
spends on, and in the future when they leave your employ, it is hard for you to 
figure out her or his new employer.

If the employee is a saver, they can accumulate their funds, thus reducing 
their incoming capacity below their biweekly salary.
If so, he or she can use an offchain-to-onchain swap, again, to move their 
accumulated savings to onchain cold storage.

This is not perfect of course, if you run multiple nodes you can try 
correlating payments by timing and amount (and prior to payment points i.e. 
today, you can correlate by payment hashes).
But this is still much better than the onchain situation, as you describe.

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


Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium

2020-10-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

>
> Looking at these equations, I realize that the incentives against
> post-coinswap-theft-attempt still work even if we set K = 0, because the
> extra miner fee paid by Bob could be enough disincentive.

This made me pause for a moment, but on reflection, is correct.

The important difference here relative to v1 is that the mining fee for the 
collateralized contract transaction is deducted from the `Jb` input provided by 
Bob.


> Unlike the v1 protocol, each CoinSwap party knows a different version of
> the contract transactions, so the taker Alice always knows which maker
> broadcast a certain set of contract transactions, and so can always ban
> the correct fidelity bond.

Great observation, and an excellent property to have.

Will go think about this more.

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


Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

2020-10-01 Thread ZmnSCPxj via bitcoin-dev
Good morning Mike,

That is better than implied name-calling and refusing to lay out your argument 
in detail.
It is still sub-optimal since you are still being insulting by labeling me as 
"reactionary", when you could have just laid out the exact same argument ***in 
the first place*** without being unnecessarily inflammatory, but this is 
significantly better than your previous behavior.

I also strongly prefer to discuss this openly on the mailing list.

> Consider for one moment when the words I have said are correct. Take this 
> moment to see the world from someone else's eyes, and do not be reactionary - 
> just be.
>
> Good.
>
> Consider a threat model, where nodes are unable to form new connections, 
> unless the attacker allows it to happen. The point of threat modeling is not 
> to question if it is possible, but rather to plan on failure because we live 
> in a world where failure happens. Now if you are in a world of limited 
> visibility, and a presented solution has no intrinsic value other than it's 
> length - then you create a node that is gullible. An adversary that controls 
> connections can lie that a new solution was ever even found or selectivally 
> slow the formation of this side of the disagreement, and probably other bad 
> things too.   That sucks, and no one is saying that there is a complete 
> solution to this problem and we are all here to help.
>
> You are absolutely correct - the eclipse effect is never going to be perfect. 
> Which is your point, and it's accurate. Imperfections in the node's 
> visibility allow for a more-fit solution to leak out, and ultimately an 
> identical consensus to form - so long as there is some measure to judge the 
> fitness of two disagreements of identical length.

This is the point at which I think your argument fails.

You are expecting:

* That the attacker is powerful enough to split the network.
* That the attacker is adept enough that it can split the network such that 
mining hashpower is *exactly* split in half.
* That the universe is in an eldritch state such that at the exact time one 
side of the chain split finds a block, the other side of the chain split *also* 
finds a block.

This leads to a metastable state, where both chain splits have diverged and yet 
are at the exact same block height, and it is true that this state can be 
maintained indefinitely, with no 100% assurance it will disappear.

Yet this is a [***metastable***](https://en.wikipedia.org/wiki/Metastability) 
state, as I have mentioned.
Since block discovery is random, inevitably, even if the chain splits are 
exactly equal in mining hashpower, by random one or the other will win the next 
block earlier than the other, precisely due to the random nature of mining, and 
if even a single direct connection were manually made between the chain splits, 
this would collapse the losing chain split and it will be reorganized out 
without requiring floating-point Nakamoto.

This is different if the coin had non-random block production, but fortunately 
in Bitcoin we use proof-of-work.

The confluence of too many things (powerful attacker, exact hashpower split, 
perfect metastability) is necessary for this state --- and your solution to 
this state --- to actually ***matter*** in practice.
I estimate that it is far more likely my meat avatar will be destroyed in a 
hit-and-run accident tomorrow than such a state actually occurring, and I do 
not bother worrying about my meat avatar being destroyed by a hit-and-run 
accident tomorrow.

And in Bitcoin, leaving things alone is generally more important, because 
change is always a risk, as it may introduce *other*, more dangerous attacks 
that we have not thought of.
I would suggest deferring to those in the security team, as they may have more 
information than is available to you or me.

>  This minor change of adding a fitness test to solve disagreements is 
>intended to diminish the influence of delayed message passing, and yes there 
>are multiple solutions to this problem, absolutely, but bringing this fact up 
>just derails the important parts of the conversation. 
>
> By the client having limited visibility, then non-voting nodes who simply 
> pass messages *are* given a say in the election process, and that is a 
> problem.   Any attacker can more easily control when a message arrives than a 
> good fitness value.   The old 2013 solution was about naming one side a 
> looser, but that doesn't really help.  It isn't just about calling one 
> solution a winner and a loser. We need to make sure that all descendants of 
> weak solutions are also going to be weak - and that my friend is the basis 
> for a genetic algorithm.
>
> -Michael Brooks 
> (my real name)

Do you think emphasizing that this is your real name ***matters*** compared to 
actual technical arguments?

>
> On Wed, Sep 30, 2020 at 6:45 PM ZmnSCPxj  wrote:
>
> > Good morning Mike,
> >
> > > You are incorrect. 
> >
> > You make no argument to back this 

Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

2020-09-30 Thread ZmnSCPxj via bitcoin-dev
Good morning Mike,

> ZmnSCPxj,
>
> The growing tare in growing disagreement continues to divide mining capacity 
> while the network waits for formation of future blocks - you'll never get to 
> complete consensus unless three is a way to avoid ambiguity in disagreement, 
> which you have not addressed.  The topic of my discussion is an exploitable 
> condition, your three block plan does not add up.
>
> I wrote the exploit before I wrote the paper. It is telling that still no one 
> here has refenced the threat model, which is the largest section of the 
> entire 8 page paper.  The security came before the introduction of FPNC 
> because security fundamentals is what drives the necessity for the solution.
>
> The text you are reading right now was delivered using the mailing list 
> manager Majordomo2, which I shelled in 2011 and got a severity metric and an 
> alert in the DHS newsletter. Correct me if I am wrong, but I bet that just of 
> my exploits has probably popped more shells than everyone on this thread 
> combined.   Cryptography?  Sure, I'll brag about the time I hacked Square 
> Inc. This is actually my current favorite crypto exploit — it was the time I 
> used DKIM signature-malleability to conduct a replay-attack that allowed an 
> adversary to replay another user's transactions an unlimited number of times. 
> After receiving a normal payment from another Square user you could empty 
> their account.  This was reported ethically and it was a mutual joy to work 
> with such a great team.  Now it is not just impact, but I am also getting the 
> feeling that I have collected more CVEs, all this is to say that I'm not new 
> to difficult vendors.

Argument screens off authority, thus, even if I have no CVEs under this 
pseudonym, argument must still be weighted more highly than any authority you 
may claim.

> To be blunt; some of you on this thread are behaving like a virgin reading a 
> trashy love novel and failing to see the point — Just because you aren't 
> excited, doesn't mean that it isn't hot.
>
> The exploit described in this paper was delivered to the Bitcoin-core 
> security team on August 4 at 9:36 PM PST.  The industry standard of 90 days 
> gives you until November 2nd. Now clearly, we need more time. However, if the 
> consensus is a rejection, then there shouldn't be any concerns with a 
> sensible 90-day disclosure policy. 

I am not a member of this security team, and they may have better information 
and arguments than I do, in which case, I would defer to them if they are 
willing to openly discuss it and I find their arguments compelling.

The attack you describe is:

* Not fixable by floating-point Nakamoto consensus, as such a powerful 
adversary can just as easily prevent propagation of a higher-score block.
* Broken by even a single, manually-created connection between both sides of 
the chain-split.

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

2020-09-30 Thread ZmnSCPxj via bitcoin-dev
Good morning Mike,

An observation to be made is that the current "first seen" is more 
incentive-compatible than floating-point Nakamoto consensus.

If a miner A mines a block at height N, then obviously the first block it has 
seen is that block.

If due to propagation delays on the network, another miner B mines an 
alternative block (let us say with more fitness score, regardless of the 
details of the fitness metric you use) at height N, miner A has no incentive to 
reject its own version of that block and mine on top of the miner B alternative 
version, even if floating-point Nakamoto consensus is deployed by most nodes.

Even if the rest of the mining network is now mining on top of the miner B 
version, if miner A chances on another new block at N+1 built on top of its own 
version of block N, then it would still win both blocks and earn the block 
subsidy and fees of two blocks.
And since block height, as I understand it, trumps over floating-point Nakamoto 
consensus, the B version will be reorganized out anyway in that case.
If miner A had switched to mining on top of the miner B block, then if it won 
another block at height N+1, it would have lost the block subsidy+fees of the 
lower-scoring miner A block at height N.


Thus, floating-point Nakamoto consensus is not incentive-compatible, so I doubt 
it would have any kind of adoption.


The problems with stability you mention can be fixed, fairly trivially, by 
simply waiting for 3 confirmations rather than just 1 confirmation.


In a relativistic universe, information cannot propagate faster than 
light-speed, and thus there will always be a communications network delay in 
propagating data.
As I see it, floating-point Nakamoto consensus cannot fix this issue, as it 
cannot change underlying laws of the universe.

If your goal is "stability" of some kind, then there is still always a 
possibility that two miners on opposite sides of the Earth will create blocks 
at the same height outside of the light cones of each other.
In a relativistic universe, this cannot be eliminated unless all miners occupy 
the same physical location, i.e. have centralized in the same mining hardware.

One of those two blocks created will, with high probability, have a lower 
score, and thus any nodes in the light cone of the miner of the lower-scored 
block will still experience a reorg, as they will first see one block, then 
switch to the higher-scored block when it arrives to them.

Thus, floating-point Nakamoto consensus cannot provide complete stability of 
the network, still, as the universe we operate in does not have instantaneous 
information transfer.

A wise designer of automated systems will ***still*** wait for 3 confirmations 
before doing anything, and by then, the effects of floating-point Nakamoto 
consensus will be literally a thing of the past.


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


Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

2020-09-30 Thread ZmnSCPxj via bitcoin-dev

>  At this point very little is stopping us from speeding up block creation 
>times. PoS networks are proving that conformations can be a minute or less - 
>why not allow for a block formation time that is 6 or 12 times faster than the 
>current target and have 1/6th (or 1/12th) of the subsidy to keep an identical 
>inflation target.

What?

That is surprising information to me.

My understanding is that speeding up block creation times is highly risky due 
to increasing the tendency to "race" in mining.

The average time to propagate to all miners should be negligible to the average 
inter-block time.
Efforts like compact blocks and FIBRE already work at the very edges of our 
capability to keep the propagation time negligible.

Indeed, looking forward, part of my plans for Earth-based civilization involves 
sending out hapless humans into space and forcing them to survive there, thus 
the inter-block time may need to be *increased* in consideration of 
interplanetary communications times, otherwise Bitcoin would dangerously 
centralize around Earth, potentially leading to the Universal Century and 
awesome giant robot battles.

(Hmmm, on the one hand, centralizing around Earth is dangerous, on the other 
hand, giant robots, hmmm)

"PoS" networks mean nothing, as most of them are not global in the scale that 
Bitcoin is, and all of them have a very different block discovery model from 
proof-of-work.
In particular, I believe there is no "racing" involved in most PoS schemes in 
practice.

>
> … The really interesting part is the doors that this patch opens. Bitcoin is 
> the best network, we have the most miners and we as developers have the 
> opportunity to build an even better system - all with incremental soft-forks 
> - which is so exciting.

Changing inter-block times is not possible as a softfork, unless you are 
planning to (ab)use the timewarp bug, which I believe was proposed by maaku7 
before.
My understanding is that the preferred approach would be to close the timewarp 
bug, in which case increasing the block rate would not be doable as a softfork 
anymore.

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


Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

2020-09-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Tom,

> Hi ZmnSCPxj,
>
> > The SE can run in a virtual environment that monitors deletion events and 
> > records them.
> > Such a virtual environment could be set up by a rootkit that has been 
> > installed on the SE hardware.
> > Thus, even if the SE is honest, corruption of the hardware it is running on 
> > can allow recovery of old privkeys and violation of the tr\*st assumption.
>
> This is true, but this threat can be mitigated with secured infrastructure 
> and the use of hardware security modules/trusted execution environments that 
> enable secure (and potentially attestable) deletion. 
>
> > Compare this to, for example, TumbleBit or Wasabi.
> > In those cases, even if the service providing the mixing is corrupted by a 
> > rootkit on the hardware running the honest service software in a virtual 
> > environment and monitoring all its internal state and communications, they 
> > cannot lead to loss of funds even with cooperation of previous participants.
> >They can at most be forced into denial-of-service, but not outright theft of 
> >coins.
>
> Yes, I agree. But on the other side of the scale is a comparison with 
> centralised mixing services, which remain extremely popular. 
>
> > I admit the new solution is superior blockspace-wise, if you consider 
> > multiple mixing rounds. 
>
> The aim of the solution is to replicate the UX (in terms of speed) of a 
> completely centralised mixer (i.e. where the server(s) explicitly holds the 
> full key(s) to the deposits being swapped) but in a way that makes theft more 
> difficult (requiring collusion with previous owners), has an in-built 
> mechanism for users to get back their funds if the service is shut 
> down/blown-up, provides users with proof of ownership/theft, and with the 
> same privacy guarantees as the above mentioned trust-minimised protocols. 

I believe the slowness of TumbleBit and Wasabi have less to do with security 
than with gathering enough participants to get a reasonable anonymity set.

If the statechain entity itself does not participate and put up funds that its 
clients can acquire quickly, than a similar waiting period would be necessary 
anyway to gather enough participants to make the swapping worthwhile.
This would then fail your goal of speed.

If the statechain entity *does* act as a participant, then a client could 
acquire a new coin fairly quickly (as the statechain entity would be a 
"participant of last resort" with which it could swap right now), but the 
"previous participant" in that case would be the statechain entity itself, 
making its ability to outright steal funds absolutely certain, and thus not 
much better than a mixer that provides "put money in this address, I will send 
you money in your address" service.
(unless I can do a cut-and-choose on the hardware, i.e. buy multiple instances 
and reverse-engineer all except a randomly-selected one to check for hardware 
defects that may allow extraction of privkeys, and then use the hardware that 
remains, I do not think the security of TEEs/HSMs is at all high.
And the TEE/HSM would be directly possessed by the statechain entity and not 
me, presumably I as client of the statechain entity cannot audit that, so ---)

If you are going to have a maker-taker model, where takers spend money to get 
immediate swaps for the time that makers spend waiting, then I suggest that the 
SwapMarket plan by Chris Belcher would only require some number of 
confirmations of various transactions to get superior security, which would be 
a better tradeoff than what statechains provide.



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


Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

2020-09-21 Thread ZmnSCPxj via bitcoin-dev
Good morning Tom,

> Hi ZmnSCPxj,
>
> > I think the entire point of non-custodiality ***is*** trust minimization.
>
> There are also legal and regulatory implications. It is much easier for a 
> service to operate without requiring its users to be KYCed if it is 
> non-custodial and funds cannot be frozen/seized. 

Complying with the letter of the law without complying to its spirit seems 
rather hair-splitting to me.

Ideally, a law regarding any financial mechanisms would judge based on how much 
control the purported owner has over the actual coin and what risks it would 
entail for them, and protect citizens against risk of damage to their finances, 
not focus on whether storage is "custodial" or not.

So I still suggest that, for purposes of technical discussion, we should avoid 
the term "custodial" and instead consider technical risks.

>
> > The main objection against custodiality is that someone else can prevent 
> > you from spending the coin.
> > If I have to tr\*st the SE to not steal the funds, is it *really* 
> > non-custodial, when after a swap, a corrupted SE can, in collusion with 
> > other participants, take control of the coin and prevent me from spending 
> > it as I wish?
>
> I would argue that it is non-custodial if the SE performs the protocol as 
> specified (i.e. securely deleting expired key shares).

The SE can run in a virtual environment that monitors deletion events and 
records them.
Such a virtual environment could be set up by a rootkit that has been installed 
on the SE hardware.
Thus, even if the SE is honest, corruption of the hardware it is running on can 
allow recovery of old privkeys and violation of the tr\*st assumption.

Compare this to, for example, TumbleBit or Wasabi.
In those cases, even if the service providing the mixing is corrupted by a 
rootkit on the hardware running the honest service software in a virtual 
environment and monitoring all its internal state and communications, they 
cannot lead to loss of funds even with cooperation of previous participants.
They can at most be forced into denial-of-service, but not outright theft of 
coins.

Thus, I believe this solution is inferior to these older solutions, at least in 
terms of financial security.

I admit the new solution is superior blockspace-wise, if you consider multiple 
mixing rounds.
However, multiple mixing rounds under this solution have increased exposure to 
the risk of theft noted above, and thus it would be better, risk-wise, to 
immediately withdraw after every round, and potentially seek other SEs (to 
reduce risks arising from a particular SE being corrupted), thus obviating the 
blockspace savings.


The above remain true regardless of what definition of "custodial" you have.

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


Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

2020-09-20 Thread ZmnSCPxj via bitcoin-dev
Good morning Tom,

> Hi ZmnSCPxj,
>
> Thanks for the reply. 
>
> > Okay, I suppose this is much too high-level a view, and I have no idea what 
> > you mean by "statecoin" exactly.
>
> Sorry, most of the protocol details are in the links, but terminology should 
> be made clearer. A "statecoin" is a UTXO that is a 2-of-2 between the owner 
> and SE (the tr*sted signing server) i.e. can be transferred off-chain. 
>
> Also, should have been clear that `addr1` is the 'statecoin address' which is 
> different from the on-chain address (the shared public key the bitcoin is 
> paid to). The on-chain address does not change, whereas the 'statecoin 
> address' changes with each new owner and is used to authenticate owners to 
> the SE and act as proof of ownership on the statechain - it is not related to 
> the onchain address/pubkey and controlled by the owner only. 
>
> > So it seems to me that this requires tr\*st that the coordinator is not 
> > going to collude with other participants.
>
> This is correct. The SE also must be trusted to not actively defraud users. 
> The main advantage of this scheme is that assuming the SE can be trusted, it 
> is strictly non-custodial. 
>
> > This is strictly worse than say Wasabi, where the coordinator colluding 
> > with other participants only allows the coordinator to break privacy, not 
> > outright steal funds.
> > It seems to me that the trust-minimized CoinSwap plan by belcher_ is 
> > superior to this, with reduced scope for theft.
>
> This is true if the overriding aim is trust minimisation, but not if the aim 
> is speed and cost while staying non-custodial. Off-chain SE transactions are 
> near instant and orders of magnitude cheaper than on-chain. Probably best 
> thought of as a non-custodial centralised mixer. 


I think the entire point of non-custodiality ***is*** trust minimization.

The main objection against custodiality is that someone else can prevent you 
from spending the coin.
If I have to tr\*st the SE to not steal the funds, is it *really* 
non-custodial, when after a swap, a corrupted SE can, in collusion with other 
participants, take control of the coin and prevent me from spending it as I 
wish?

So I think touting "non-custodial" is relatively pointless if tr\*st is not 
minimized.

(I am aware there is an update mechanism, either Decker-Russell-Osuntokun or 
Decker-Wattenhofer, that is anchored off he onchain transaction output, but 
anyone who can recover the raw keys for signing the funding transaction output 
--- such as a previous participant and a corrupt SE --- can very easily bypass 
the mechanism.)

For example, in my previous description of [implementing investment 
aggregation](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018055.html),
 while I admit you need tr\*st in the business owners who you are investing in, 
it does not require tr\*st in the aggregator, due to the n-of-n, which cannot 
be reconstructed by the aggregator and all other participants without you.

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

2020-09-15 Thread ZmnSCPxj via bitcoin-dev
Good morning Tom,


> Here is a high-level description of how this blinding can operate - with the 
> aim that the conductor does learn how the ownership of individual coins has 
> changed.
> For example, imagine 4 individuals (A,B,C and D) who own equal value 
> statecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap 
> ownership privately, trusting the conductor/SCE to enforce atomicity. In 
> other words, the conductor will randomly assign each statecoin to one of the 
> owners (the mix), but will not be able to gain knowledge of that assignment.
> 1. A,B,C and D signal their participation by signing the swap_token (which 
> has details of the swap) with the proof-key of their input coin. (A statecoin 
> address is formed of a concatenation of the proof key and backup address).
> 2. Each of A,B,C and D then generate a new statecoin address (where they what 
> to receive the swapped coin), which they blind (encrypt) and sign with the 
> proof key of their input coin: add1, add2, add3 and add4 and send to the 
> conductor.
> 3. The conductor authenticates each signature and then signs each payload 
> (i.e. the blinded destination addresses) with a blinded signature scheme and 
> returns these signatures to A,B,C and D.
> 4. Each of A,B,C and D then reconnects over TOR with a new identity.
> 5. Each of A,B,C and D then send their unblinded destination address with the 
> conductor signature to the conductor (the conductor now knows that these 4 
> addresses belong to A,B,C and D, but not which ones map to each input.)
> 6. The conductor randomly assigns each address to one of utxo1, utxo2, utxo3 
> and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2) and 
> requests each participant to initiate the transfer to the given address.
> 7. Each participant then finalises each transfer - if any transfer fails (due 
> to a participant disappearing or acting maliciously) then all transfers are 
> reverted - here atomicity is guaranteed by the SCE.

Okay, I suppose this is much too high-level a view, and I have no idea what you 
mean by "statecoin" exactly.

Let me try to fill in the details and correct me if I am wrong okay?

I imagine that the `add1` etc. are implemented as 2-of-2 between the purported 
owner and the tr\*sted signing module.
The owner of that address can easily create this knowing only the pubkey of the 
tr\*sted signing module.

The initial `utxo1`... are also in similar 2-of-2s.

(they cannot be unilateral control, since then a participant can broadcast a 
replacement transaction, even without RBF, almost directly to miners.)

So when the coordinator talks to Alice, who owns `utxo1` and destination 
`addr1`, it provides partially-signed transactions of `utxo#:addr#`.
Alice then checks that its `addr1` is on one of those transactions, with the 
correct amount, then provides a signature for the `utxo1:addr#` transaction.

However, then the coordinator, who happens to be in cahoots with Bob, Charlie, 
and Dave, simply broadcasts that transaction without soliciting the 
`utxo#:addr1` transaction.

So it seems to me that this requires tr\*st that the coordinator is not going 
to collude with other participants.
This is strictly worse than say Wasabi, where the coordinator colluding with 
other participants only allows the coordinator to break privacy, not outright 
steal funds.

It seems to me that the trust-minimized CoinSwap plan by belcher_ is superior 
to this, with reduced scope for theft.
The plan by belcher_ is potentially compatible with using watchtowers that can 
be used for both CoinSwap and Lightning as well (if we design it well) with the 
watchtower potentially not even learning whether it is watching a CoinSwap or a 
Lightning channel.

Though of course I could be misunderstanding the scheme itself.
Is my understanding correct?

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


Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-09-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris, and probably also Lightningers,

> However, it might be possible to prevent the maker from learning the 
> collateral input at all.
>
> If my understanding of BIP-143 is correct, inputs are hashed separately 
> (`hashPrevouts`) from outputs (`hashOutputs`).
> Bob can provide the `hashPrevouts` as an opaque hash, while providing a 
> decommitment of `hashOutputs` to show that the outputs of the collateralized 
> contract transaction are correct, which is all that Charlie really needs to 
> know.
>
> Bob is incentivized to provide the correct `hashPrevouts`, because if it 
> provides an incorrect `hashPrevouts` it cannot get a signature for a 
> transaction it can use in case of a protocol abort, thus potentially losing 
> its money in case of a protocol abort.
> Conversely, Charlie does not care where Bob gets the funds that goes into its 
> contract output come from, it only cares that the Bob collateralized contract 
> output is I+K.
> It loses nothing to sign that transaction, and it would prefer that 
> transaction since its own contract output is only I.
>
> This solution is mildly "unclean" as it depends on the details of the sighash 
> algorithm, though, and is not proposed seriously.
> Hopefully nobody will change the sighash algorithm anytime soon.
>
> In addition, it complicates reusing Lightning watchtowers.
> Lightning watchtowers currently trigger on txid (i.e. it would have triggered 
> on the txid of the B collateralized contract tx), but watching this needs to 
> trigger on the spend of a txo, since it is not possible to prove that a 
> specific `hashPrevouts` etc. goes with a specific txid without revealing the 
> whole tx (which is precisely what we are trying to avoid), as both are hashes.
> Watchtowers may need to be entrusted with privkeys, or need to wait for 
> `SIGHASH_ANYPREVOUT` so that the exact txid of the B collateralized contract 
> tx does not need to be fixed at signing time, thus this solution is 
> undesirable as well.

On the other hand, when considering Decker-Russell-Osuntokun, the `(halftxid, 
encrypted_blob)` approach to watchtowers simply does not work.
Watchtowers are simpler in Decker-Russell-Osuntoku if and only if the 
watchtower knows the funding outpoint, therefore knows which channel it is 
watching *before* an attack on the channel occurs, and is less private.

I have argued before that we should instead use `(sighash[0:15], 
encrypted_blob)` rather than `(txid[0:15], encrypted_blob)`.
This makes Decker-Russell-Osuntokun blobs indistinguishable from Poon-Dryja 
blobs, and the watchtower is not even made aware what the commitment type of 
the channel is until an actual attack occurs.

If watchtowers use `(sighash[0:15], encrypted_blob)` instead, the proposal to 
hide the collateral input behind `hashPrevouts` would be workable, as Charlie 
knows the entire sighash of the B collateralized contract transaction even if 
it does not know the txid.
This also does not reveal the funding outpoint, or whether it is watching a 
Poon-Dryja channel, a Decker-Russell-Osuntokun channel, or a CoinSwap.

--

Even if we propose that CoinSwap makers should run their own watchtowers rather 
than hire a public watchtower, it's safer for a CoinSwap maker to have 
watchtowers that are unaware of exactly *what* they are watching.
If the watchtowers are aware of the funding outputs they are watching, then 
every additional watchtower a maker creates increases the attack surface on the 
privacy of the maker, as the funding outputs becoming known allows the maker 
hodlings to be derived.

If watchtowers only get a partial sighash, then the information that they 
contain are not sufficient by themselves to determine what coins are owned by 
the maker, thus every additional watchtower is no longer a potential attack 
vector on the privacy of the maker.

So this is off-topic, but anyway, we should probably move to using 
`sighash[0:15]` instead of `txid[0:15]` for watchtowers.


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


Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-09-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine,


> > This can be arranged by having one side offer partial signatures for the 
> > transaction of the other, and once completing the signature, not sharing it 
> > with the other until we are ready to actually broadcast the transaction of 
> > our own volition.
> > There is no transaction that both participants hold in completely-signed 
> > form
>
> I don't think that's different from the current model where you have either a 
> valid HTLC-timeout or HTLC-Sucess tx to solve a HTLC output but never full 
> witness material to build both ?

It is different in that the current (actually, now *previous*) model looks like 
this:


funding out ->  contract tx -->  HTLC-timeout
 OR
 HTLC-success


Whereas what I am describing looks like this:

funding out ->  HTLC-timeout
OR
HTLC-success

The attack being described has to do with the fact that, after private key 
turnover (i.e. after hash-lock resolution), the contract tx can be used to at 
least annoy the supposed new owner of the funding out, since the contract tx 
deducts fees from its input to pay for itself.
And at the end of the swap (after private key turnover) the one who funded the 
funding outpoint (and swapped its control for this outpoint already, for a 
different outpoint) can at least try to broadcast the contract tx for a 
*chance* that the HTLC-timeout becomes valid and it can steal the coin even 
after taking the swapped coin on the other side of the swap.


Chris recently described a different technique, which has different contract 
txes, with the contract tx held by the offerrer of the HTLC (who can otherwise 
later annoy the acceptor of the HTLC once the HTLC has been hash-resolved) 
costing the offerrer of the HTLC some coins if it is published after swap 
completion.


> > To reduce this risk, A can instead first swap A->B->A, then when that 
> > completes, A->C->A.
> This limits its funding lockup to 1 week.
>
> Okay I think I understand your point. So by intermediating the chain with the 
> taker you ensure that in case of previous hop failure, taker funds are only 
> timelocked for the delta of this faulting hop not the whole route. But still 
> not anchoring onchain the next route segment means that any moment the next 
> maker can exit from the proposed position ?
>
> That's interesting, so a) you require all takers to lock their funds onchain 
> before initiating the whole routing and you will pay more in service fees or 
> b) you only lock them step by step but you increase risk of next hop default 
> and thus latency. Roughly.
>  
> It might be an interesting construction to explore on its own, minus the 
> downside of producing weird spend patterns due to next hop maker bidding with 
> another party.
>

Correct, a taker can pay higher fees for lots of smaller swaps that reduce its 
lockup risk, or pay less (with similar privacy bought) but with greater total 
lockup risk.

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


Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-09-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,


> > This seems a great solution!
> > Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be 
> > B as well.
> > This means, the taker has to have some collateral input, of at least value 
> > K, that it cannot swap (because if it tried to swap that amount, it would 
> > be unable to provide a collateral as well).
> > How much does C need to know about the B collateralized contract 
> > transaction?
> > At the minimum, it has to know the output pays out to the correct contract, 
> > so it seems to me it has to know the entire B collateralized contract 
> > transaction, meaning it learns another input of B ("collateral(B)") that is 
> > not otherwise involved in the CoinSwap.
> > This is important, again, if B is a taker, as it means an unrelated input 
> > of B is now learned by C as having the same ownership as B.
>
> Yes, in fact that's why in my example I talk about a CoinSwap between
> two makers Bob and Charlie. Makers can be reasonably expected to own
> multiple UTXOs, but takers cannot. As you say because collateral
> payments breaks the ability of takers to sweep their entire wallet
> through CoinSwap.
>
> Happily, I think takers themselves don't need to use collateral
> payments. Here's an argument to why:
>
> Riskless theft attempts by the taker who no longer controls the coins
> actually isnt riskless or costless: Because it reduces the privacy of
> the previously-owned coins. If a taker genuinely wanted good privacy
> (Which, after all, they're paying for via miner fees and CoinSwap fees)
> then they would benefit if the coins they no longer own remain unspent
> for a long time, because it increases their anonymity set by making them
> hide among a greater crowd of coins which also don't get spent for a
> long time.

Hmmm.

The attack can only be mounted after protocol completion.
Thus, at that point, makers have made money, and takers have paid.
And taker is now in possession of a coin unlinked with its original coin, which 
is what it paid for.

However, if the taker considers the maker fee it has already paid as a sunk 
cost, then it would still be rational of them to mount this attack (sunk costs 
should be ignored).
>From this point-of-view, it is possible to do so with only a *subsequent* 
>potential gain, and still no downside.

For example, suppose the taker has already performed an "honest" CoinSwap.
Then, it is now in possession of a UTXO that is not linked with its income 
stream.
It can then perform another CoinSwap, and *then* perform the attack.
This reveals that the UTXO it provided is involved in a CoinSwap due to 
publication of the contract transaction, which is not a loss in this case since 
the UTXO it put in was not linked to its income stream already, via a previous 
non-attacked CoinSwap.

A taker might rationally consider doing riskless costless theft with its 
already-delinked coins if it assesses that some maker is not sufficiently 
online and with insufficient watchtowers (both operating expenditures!) that it 
has some probability of success times amount it has to seed the theft, versus 
the fee of that maker plus miner fees.

In response, a maker that is forced to accept a sweeping taker will raise its 
fee, so as to disincentivize this attack using already-delinked coins.

Hmmm.

In addition, post-Scriptless-Script, assuming relative-locktime-use is 
"normalized" as proposed in 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002412.html
 , then the "contract transaction" and its timelock-path-transaction look 
exactly the same as ordinary (P2SH-)P2WPKH single-input-single-output 
transactions, thus in that case the taker does ***not*** lose any privacy.
This removes whatever protection you can get from contract transaction 
blackmail.

--

The above suggests to me that you still want the collateralized contract 
transaction from the taker as well.

A sweeping taker can split its funds in half, swapping one half (and using the 
remainder for collateral input), then after that swap, using the 
already-swapped coins for the collateral input of the remaining unswapped coins.
This leaks information: you are now linking a post-mix coin with a pre-mix 
coin, not onchain (if you do not mount an attack, which you probably will not) 
but you *do* reveal this information to the maker (one input is from the 
funding tx that is pre-mix, the collateral input is from the post-mix coin).

The only protection here is that the maker is unaware of the fact that your 
input coin is pre-mix and your collateral input is post-mix, so it can be hard 
for a maker to *use* this information.


However, it might be possible to prevent the maker from learning the collateral 
input at all.

If my understanding of BIP-143 is correct, inputs are hashed separately 
(`hashPrevouts`) from outputs (`hashOutputs`).
Bob can provide the `hashPrevouts` as an opaque hash, while providing a 
decommitment of `hashOutputs` to show that the 

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-09-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

> A big downside is that it really ruins the property of allowing coins to
> remain unspent indefinitely. That has privacy implications: if a coin
> remains unspent for longer than 2 weeks (or another short locktime) then
> for sure the transaction was not a CoinSwap, and so the anonymity set of
> the CoinSwap system would be far smaller For this reason I'm pretty
> desperate to solve the vulnerability without losing the coins remaining
> unspent indefinitely feature.

Ah, right accept no small privacy leaks!

>
> We need to solve the vulnerability you found, which I'll call the
> riskless theft attempt problem. So what do you think of this solution:
>
> == Building block 1: A, B and C having different contract txes ==
>
> In the original proposal each CoinSwap peer has the same contract
> transaction, and either side can broadcast it whenever they like. This
> actually isn't necessary. We can have a contract transaction
> fully-signed but only known to one peer, with a possibly-different
> transaction transaction fully-signed and only known to the other peer.
>
> Obviously for the CoinSwap to work both contract transactions must have
> the same hash-time-locked contract, but they can differ in other ways.
>
> == Building block 2: collateral payments ==
>
> The riskless theft attempt problem happens because the previous owner of
> the coins knows the fully-signed contract transaction and can broadcast
> it at no cost to themselves. So to solve the problem we add a cost.
>
> There is a 2of2 multisig made up of Bob's and Charlie's keys. The
> associated contract transaction known to Bob must now also have one of
> Bob's single-sig inputs. The outputs are such that some of the money
> from Bob's input now ends up in the HTLC output. The result is that
> after the CoinSwap if Bob broadcasts his contract transaction but fails
> to take the money from the HTLC output, then Bob will have lost money.

Just to be clear:

* B is the one who originally funded the HTLC, and owns the timelock.
* C is the one who will accept the HTLC, and owns the hashlock.

> I'm calling this idea collateral payments, by analogy with collateral
> used for loans. A collateral is someone valuable a debtor puts on the
> table, and if they don't repay the loan then they lose the collateral
> (presumably the creditor sells it to repay the loan).
>
> Here is a diagram of the contract transaction known to Bob:
>
> multisig (B+C) [I btc]---> (B+timelock_B OR C+hash) [I+K-M~ btc]
>
> collateral(B)  [J btc] (Bob)[J-K btc]
>
>
> where:
> I = CoinSwap amount
> J = Value of Bob's collateral input
> K = Value that Bob loses if he broadcasts his contract tx but doesnt
> get the money
> M~ = miner fee (random variable)
>
> The value K is something that can be set by the protocol, and made high
> enough so that doing a riskless theft attempt is not worth it. Probably
> the value of K will be quite small because the odds of a riskless
> payment attempt succeeding is very small (assuming the makers all use
> multiple redundant watchtowers). Mostly likely K will be smaller than
> M~, so if the collateral is lost to Bob then the miners will the ones to
> gain, rather than Charlie.

This seems a great solution!

Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be B as 
well.
This means, the taker has to have *some* collateral input, of at least value K, 
that it cannot swap (because if it tried to swap that amount, it would be 
unable to provide a collateral as well).

How much does C need to know about the B collateralized contract transaction?
At the minimum, it has to know the output pays out to the correct contract, so 
it seems to me it has to know the entire B collateralized contract transaction, 
meaning it learns another input of B ("collateral(B)") that is not otherwise 
involved in the CoinSwap.
This is important, again, if B is a taker, as it means an unrelated input of B 
is now learned by C as having the same ownership as B.

A fresh maker that is given its starting funds in a single UTXO needs to split 
up its funds to make at least one collateral input it can use.

Of note is that the B output also serves as a point for CPFPing this 
transaction, thus only one version of the B collateralized contract transaction 
needs to be made, and the B collateralized contract transaction can be at or 
close to the minimum relay feerate and later CPFPed.

In terms of onchain analysis heuristics, it looks like the B output is change, 
while the B+C contract output is the send-out, I think, for most cases.
In case of a protocol abort, this heuristic is misled, since both outputs 
become owned by B due to the protocol abort.
In case of a protocol completion, this heuristic is accurate, since the B+C 
contract output will be claimed by C, but we do not expect this transaction to 
be confirmed onchain after protocol completion anyway (it effectively donates K 
to C or miners), so this 

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-30 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

> It seems having just one contract transaction which includes anchor
> outputs in the style already used by Lightning is one way to fix both
> these vulnerabilities.
>
> For the first attack, the other side cannot burn the entire balance
> because they only have access to the small amount of satoshi of the
> anchor output, and to add miner fees they must add their own inputs. So
> they'd burn their own coins to miner fees, not the coins in the contract.

Minimum output size is 547 sats, so anchor outputs are that amount at minimum.
A P2SH-P2WPKH output costs something like ~130 vbytes to spend, at 1.000 
sat/vbyte that is only ~130 sats to spend a 547 sat anchor output, an 
opportunistic camper could collect from a few swaps it would have done anyway 
(e.g. as a passive popular maker?) and broadcast the contract txes of those 
swaps and then spend the anchor outputs together to get a few sats in a 
not-so-dusty UTXO, getting (547 - 130) sat per input minus the cost of creating 
a new tiny output.
Assuming the camper has already claimed its side of the swap in order to put it 
in cold, this is basically a tiny but free amount of extra money, and if small 
CoinJoins in JoinMarket are any indication, the 547 sats minus fee to spend it 
minus fee to create (amortized among the multiple contract txes) new UTXO might 
be comparable to the actual maker fee.

Since this camping attack is done after the CoinSwap, the maker fidelity bond 
is a weak protection against this.
The maker can keep around contract transactions indefinitely, and if standard 
wallets assume they can leave the coins in the same UTXO indefinitely, the 
contract transactions remain valid indefinitely, including up to fidelity bond 
timeout.
When the fidelity bond times out, the maker has to destroy its identity anyway, 
so it could opportunistically wait for a low-fee period after fidelity-bond 
timeout (we currently get low fee periods once a week, for example, so the 
camper can wait for at most a week to do this) to publish all still-valid 
contract transactions, and spend all the anchor outputs including the fidelity 
bond at the minimum feerate, getting a slightly larger fidelity bond fund, then 
CoinSwap it to honest makers to clean it, then make a new fidelity bond.
And if one of the takers happens to not be watching for contract tx timeout, it 
can potentially get free money, again, from the inattention.

(I call it a "camper attack" since the attacking CoinSwap participant waits 
around in a single place (maker fidelity bond) and snipes passing contract 
transactions to extract value from them when opportunity (low fee rate) is 
good, like a camper.)

To protect against this, we should force contract txes to signal RBF, make 
contract txes min-relay=feerate (requires CPFP package relay at base layer 
tho), and during low-fee periods we should collect outputs whose private key 
have been turned over to us, paying at a feerate slightly higher than 547 sat / 
130 vbyte fee rate (at which point it becomes uneconomical for campers to mount 
their sniping attack as they would lose the anchor output amount to fees 
anyway).

In fact the wallet can do that all the time, and if prevailing fees are above 
the 547 / 130 rate it will not confirm and the wallet that wants to spend its 
funds *now* can sign a new RBF tx at higher feerate to replace it.

Low fees, who would have thought that would enable an attack vector

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


Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-24 Thread ZmnSCPxj via bitcoin-dev


Good morning Antoine,


> Note, I think this is independent of picking up either relative or absolute 
> timelocks as what matters is the block delta between two links.

I believe it is quite dependent on relative locktimes.
Relative locktimes *require* a contract transaction to kick off the relative 
locktime period.
On the other hand, with Scriptless Script (which we know how to do with 
2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a 
contract transaction.

With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one 
participant holds a completely-signed timelock transaction while the other 
participant holds a completely-signed pointlock transaction.
This can be arranged by having one side offer partial signatures for the 
transaction of the other, and once completing the signature, not sharing it 
with the other until we are ready to actually broadcast the transaction of our 
own volition.
There is no transaction that both participants hold in completely-signed form.

This should remove most of the shenanigans possible, and makes the 30xRBF safe 
for any range of fees.
I think.

Since for each PTLC a participant holds only its "own" transaction, it is 
possible for a participant to define its range of fees for the RBF versions of 
the transaction it owns, without negotiation with the other participant.
Since the fee involved is deducted from its own transaction, each participant 
can define this range of RBFed fees and impose it on the partial signatures it 
gets from the other participant.

--

Private key turnover is still useful even in an absolute-timelock world.

If we need to bump up the block delta between links, it might be impractical to 
have the total delta of a multi-hop swap be too long at the taker.

As a concrete example, suppose A is a taker who wants to route over makers B 
and C.
However, B and C require a CLTV delta of 1 week.

If A wants to route "directly" A->B->C->A, then if something bad happens, it 
could be looking at having its funds locked for two weeks.

To reduce this risk, A can instead first swap A->B->A, then when that 
completes, A->C->A.
This limits its funding lockup to 1 week.

Private key turnover is useful since as soon as the A->B->A swap completes, it 
can directly fund the A->C->A swap from the B-side funding transaction of the 
A->B->A swap.

 |   A->B->A |A->C->A   |
 :   :  :
  A -:->funding A> B :  :
 :   :  :
  B -:->funding A -:--> funding A --> C :
 :   :  :
 :   :C-> funding A --:-> to-cold  A -->
 :   :  :

This increases the number of transactions by 1 per swap beyond the first, 
compared to a direct routing A->B->C->A, but this may be worth it for A if the 
timelocks involved are too big for A.

With 2p-ECDSA, a funding A looks exactly the same as a to-cold A, so B is 
unable to reliably determine if it is the last hop in the route.

Without private key turnover, A would have:

  **NO** private key turnover!

 |   A->B->A |A->C->A  |
 :   : :
  A -:->funding A> B : :
 :   : :
  B -:->funding A -:--> claim A -> funding A --> C :
 :   : :
 :   :   C-> funding A --:-> to-cold  A 
-->
 :   : :

So if timelock-deltas are possibly-high (to reduce the probability of the 
MAD-HTLC argument, and other attacks, succeeding), takers might prefer to route 
by completing one swap first before starting the next one, and private key 
turnover is useful by reducing blockspace required by each hop.

For reference, this is how it looks like with a single A->B->C->A swap with 
private key turnover:

 |   A->B->C->A  |
 :   :
  A -:->funding A> B :
 :   :
  B -:->funding B -> C :
 :   :
  C -:->funding A -:-> to-cold A -->
 :   :

This is still smaller than in the A->B->A, A->C->A with private key turnover, 
by one funding tx per hop.
However, A risks a much higher timelock (twice the timelock).
Thus, A might prefer a lower timelock in exchange for paying for an additional 
transaction.

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


Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-21 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,


> > Absolute timelocks mean that you can set a timer where you put your node to 
> > sleep without risk of loss of funds (basically, once the absolute timelocks 
> > have resolved, you can forget about CoinSwaps).
> > But I think the ability to spend at any time would be better, and getting 
> > 100% online 144 blocks a day, 2016 blocks a retargeting period is becoming 
> > more and more feasible.
>
> You can always put your node to sleep as a maker, and your watchtowers
> will protect you.

Assuming you have multiple watchtowers, yes.

It would be best if watchtowers for CoinSwap and watchtowers for Lightning 
could be the same thing, and ideally, a watchtower would not even know if what 
it was watching were a Lightning channel or a CoinSwap until an attack happens.

>
> What do you mean by the point about 100% online nodes getting more
> feasible? Many bitcoin nodes have been always-on for years, I think I
> missed something.

Not all locations on Earth make it easy to be 100% online.
However, as the technology of you puny humans advance, it becomes more and more 
possible for a random point on Earth to be 100% online.

> > > You're right that attempting such an move by the taker is riskless, but
> > > its not costless. The taker sets up the entire CoinSwap protocol because
> > > they wanted more privacy; but if the taker broadcasts the Alice contract
> > > transaction and waits for the timeout, then all they've achieved is
> > > spent miner fees, got their own coin back and draw attention to it with
> > > the unusual HTLC script. They've achieved no benefit from what I see, so
> > > they won't do this. Any taker or maker who attempts anything like this
> > > will be spending miner fees.
> >
> > They would be spending miner fees from the funds being stolen, thus still 
> > costless.
> > In particular, let us imagine a simple 1-maker swap.
> >
> > -   The taker and the maker complete the swap.
> > -   The taker now has possession of:
> > -   The private key for its incoming HTLC.
> > -   The pre-signed contract transaction for its outgoing HTLC.
> > -   The taker spends from its incoming HTLC using the private key.
> > -   The maker ignores this, because this is just normal operation.
> > -   Fees paid for this is not an additional cost, because a taker that 
> > wants to put its freshly-private funds into cold storage will do this 
> > anyway.
> > -   The taker gets a fresh, private coin from this incoming HTLC, so it 
> > gets the privacy it paid for.
> > -   The taker waits for the incoming-HTLC-spend to confirm.
> > -   The taker broadcasts the pre-signed contract transaction, in the hope 
> > that the maker is offline.
> > -   The fees paid for this are from the contract transaction that the 
> > taker is trying to steal.
> > Even if the theft attempt fails, the taker has already gotten its 
> > private money out, and is thus not risking anything.
> >
> > -   Semantically, the outgoing HTLC is already "owned" by the maker 
> > (the maker has private key to it).
> > -   Thus, the taker commits an action that the maker pays fees for!
> > -   The maker cannot react except to spend via the hashlock branch.
> > In particular, because the taker-incoming (maker-outgoing) UTXO is 
> > already spent, it cannot retaliate by also broadcasting the contract 
> > transaction of the taker-incoming (maker-outgoing) HTLC.
> >
> > -   The theft succeeds (the timelock passes) because the maker happens to 
> > be offline for that long.
> > -   This is "free money" to the taker, who has already gotten what it 
> > paid for --- private money in cold storage --- from the CoinSwap.
> > -   Even if the stolen fund reveals the contract, the taker can 
> > re-acquire privacy for the funds it stole for free, by paying for --- wait 
> > for it --- another CoinSwap for its swag.
>
> Yep you're right, I get it.
>
> The biggest defense against theft will have to be multiple redundant
> watchtowers. But as you say the attack is riskless and costless for the
> taker to attempt, so they might try anyway even if the probability of
> success is very low.
>
> If this attack becomes widespread then it effectively breaks the
> property that maker's coins remain unspent indefinitely. It seems like
> that would lead to makers increasing their CoinSwap fees because they
> know they'll always have to spend a bit of miner fees afterwards.
>
> Hopefully the success rate for this attack can be low enough that
> taker's human niceness will stop them trying. But for sure this is a
> concerning problem.

Indeed.

We also cannot use succinct atomic swaps because their asymmetry makes them 
unroutable --- you can only use it for single-maker swaps.
This makes it obvious to the maker that you have only a single maker.

> > Using an absolute timelock (implemented by a `nLockTime` tx directly off 
> > the 2-of-2, not `OP_CHECKLOCKTIMEVERIFY`), plus a Scriptless Script 

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-20 Thread ZmnSCPxj via bitcoin-dev
Good morning,



> Right, so if the taker uses only a single maker then they must have more
> than one UTXO.

Spending one UTXO is fine, it is generating a transaction that has one output 
that is problematic.

What needs to happen is that this single UTXO is spent to two outputs: the 
CoinSwap 2-of-2 and the change output.
This is because intermediate makers will have very high likelihood of 
generating such a pattern (it is unlikely they have an exact amount that a 
taker would require of them), and the occassional maker might have a very large 
UTXO that it can use for similar purposes.

One thing a taker can do would be to multipath its CoinSwap, i.e. it spends any 
number of UTXOs and creates two outputs, which are actually two separate 
CoinSwap 2-of-2s to different makers.
As each maker is unaware of the other, this should be similar to the case where 
the maker is an intermediate hop and is getting its incoming HTLC from another 
maker, which is unlikely to have a precise amount and will thus have a 
transaction that has two outputs, the 2-of-2 CoinSwap and the change.

>
> This leak in the case of a taker spending a single UTXO also happens
> when the taker needs to create a branching route. I described this in my
> original email "Design for a CoinSwap implementation for massively
> improving Bitcoin privacy and fungibility" under the section "Combining
> multi-transaction with routing" (the second diagram).
>
> I think this might be unavoidable. If the taker has just one UTXO they'd
> be much better off using multiple makers for this reason.
>
> > -   The makers can try timing the communications lag with the taker.
> > The general assumption would be that more makers == more delay in taker 
> > responses.
> >
>
> Sounds like adding random delays would fix this. The protocol already
> involves waiting for a confirmation (average waiting time 10 minutes, at
> best) and might involve more confirmations for extra security and
> privacy. So adding a random delay of up to 0.5-1 minutes shouldnt cause
> too many issues.
> Also the Tor network can be pretty laggy so that might add enough noise
> anyway.

Indeed, this seems a bit of a long shot for the surveilling maker.

> > > === Miner fees ===
> > > Makers have no incentive to pay any miner fees. They only do
> > > transactions which earn them an income and are willing to wait a very
> > > long time for that to happen. By contrast takers want to create
> > > transactions far more urgently. In JoinMarket we coded a protocol where
> > > the maker could contribute to miner fees, but the market price offered
> > > of that trended towards zero. So the reality is that takers will pay all
> > > the miner fees. Also because makers don't know the taker's time
> > > preference they don't know how much they should pay in miner fees.
> > > The taker will have to set limits on how large the maker's transactions
> > > are, otherwise makers could abuse this by having the taker consolidate
> > > maker's UTXOs for free.
> >
> > Why not have the taker pay for the first maker-spent UTXO and have 
> > additional maker-spent UTXOs paid for by the maker?
> > i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 
> > BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs).
> > Disagreements on feerate can be resolved by having the taker set the 
> > feerate, i.e. "the customer is always right".
> > Thus if the maker has to spend two UTXOs to make up the 0.4 BTC bag, it 
> > pays for the mining fees for that extra UTXO.
> > The maker can always reject the swap attempt if it has to spend multiple 
> > UTXOs and would lose money doing so if the taker demands a too-high feerate.
>
> Having the taker pay for just one UTXO will have an unfortunate side
> effect of resulting in the maker's money being split up into a large
> number of UTXOs, because every CoinSwap they take part in has an
> incentive to increase their UTXO count by one. At the start of
> JoinMarket this was an issue where then a taker wanting to CoinJoin a
> large would come along and the result would be a huge CoinJoin
> transaction with many many small inputs. Perhaps the taker could pay for
> 2-3 UTXOs to counteract this. (Of course the exact number would be
> configurable by the taker user, but defaults usually don't get changed).
>
> I'm still not convinced with having makers contribute to miner fees. In
> JoinMarket we tried to get makers to contribute a little to miner fees
> and simply they never did in any meaningful way. The market has spoken.
> In terms of incentives makers are happy to wait a very long time, if we
> assume they're just HODLers then even if they earn a few thousand
> satoshis that's good.
>
> > > == Contract transaction definitions ==
> > > Contract transactions are those which may spend from the 2-of-2 multisig
> > > outputs, they transfer the coins into a contract where the coins can be
> > > spent either by waiting for a timeout or providing a 

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-20 Thread ZmnSCPxj via bitcoin-dev
Good morning Nadav,

> Hey Chris and all,
>
> Looking good :) I have one major concern though
>
> >    q = EC privkey generated by maker
> >    Q = q.G = EC pubkey published by maker
> >
> >    p = nonce generated by taker
> >    P = p.G = nonce point calculated by taker
> >
> >    R = Q + P = pubkey used in bitcoin transaction
> >      = (q + p).G
>
> If I'm understanding this correctly (which I'm not sure I ame), it seems like 
> the plan is to put R on-chain as the key to an output? As stated this is 
> completely insecure as Q is known in advance so the taker can always choose a 
> nonce p but then claim that their nonce point is p.G - Q so that the key that 
> goes on-chain is (p.G - Q + Q) = p.G allowing them to steal the funds.

My reading from this is that nonce `p` has to be given by the taker to the 
maker outright.
In original post:

> Taker sends unsigned transaction which pays to multisig using pubkey Q,
> and also sends nonce p.

Thus, taker provides a proof-of-knowledge, i.e. the actual `p` scalar itself 
(not zero-knowledge, but what the maker needs is proof-of-knowledge, and could 
not care less if the proof is zero-knowledge or not).

On the other hand, I do not see the point of this tweak if you are going to use 
2p-ECDSA, since my knowledge is that 2p-ECDSA uses the pubkey that is 
homomorphic to the product of the private keys.
And that pubkey is already tweaked, by the fresh privkey of the maker (and the 
maker is buying privacy and wants security of the swap, so is incentivized to 
generate high-entropy temporary privkeys for the actual swap operation).

Not using 2p-ECDSA of some kind would remove most of the privacy advantages of 
CoinSwap.
You cannot hide among `2   2 OP_CHECKMULTISIG` scripts of Lightning, 
because:

* Lightning channel closes tend to be weeks at least after the funding outpoint 
creation, whereas CoinSwap envisions hours or days.
* Lightning mutual channel closes have a very high probability of spending to 
two P2WPKH addresses.

You need to hide among the much larger singlesig anonymity set, which means 
using a single signature (created multiparty by both participants), not two 
signatures (one from each participant).

Or is this intended for HTLCs in open-coded SCRIPTs `OP_DUP OP_IF OP_HASH160 
 OP_EQUAL  OP_ELSE  OP_CHECKSEQUENCEVERIFY OP_DROP  OP_ENDIF 
OP_CHECKSIG`?
This provides a slight privacy boost in a case (contract transaction 
publication) where most of the privacy is lost anyway.

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


Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-20 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

Great to see this!

Mostly minor comments.



>
> == Direct connections to Alice ===
>
> Only Alice, the taker, knows the entire route, Bob and Charlie just know
> their previous and next transactions. Bob and Charlie do not have direct
> connections with each other, only with Alice.
>
> Diagram of Tor connections:
>
> Bob Charlie
> | /
> | /
> | /
> Alice
>
> When Bob and Charlie communicate, they are actually sending and
> receiving messages via Alice who relays them to Charlie or Bob. This
> helps hide whether the previous or next counterparty in a CoinSwap route
> is a maker or taker.
>
> This doesn't have security issues even in the final steps where private
> keys are handed over, because those private keys are always for 2-of-2
> multisig and so on their own are never enough to steal money.

This has a massive advantage over CoinJoin.

In CoinJoin, since all participants sign a single transaction, every 
participant knows the total number of participants.
Thus, in CoinJoin, it is fairly useless to have just one taker and one maker, 
the maker knows exactly which output belongs to the taker.
Even if all communications were done via the single paying taker, the maker(s) 
are shown the final transaction and thus can easily know how many participants 
there are (by counting the number of equal-valued outputs).

With CoinSwap, in principle no maker has to know how many other makers are in 
the swap.

Thus it would still be useful to make a single-maker CoinSwap, as that would be 
difficult, for the maker, to diferentiate from a multi-maker CoinSwap.

There are still a few potential leaks though:

* If paying through a CoinSwap, the cheapest option for the taker would be to 
send out a single large UTXO (single-output txes) to the first maker, and then 
demand the final payment and any change as two separate swaps from the final 
maker.
  * Intermediate makers are likely to not have exact amounts, thus is unlikely 
to create a single-output tx when forwarding.
  * Thus, the first maker could identify the taker.
* The makers can try timing the communications lag with the taker.
  The general assumption would be that more makers == more delay in taker 
responses.



>
> === Miner fees ===
>
> Makers have no incentive to pay any miner fees. They only do
> transactions which earn them an income and are willing to wait a very
> long time for that to happen. By contrast takers want to create
> transactions far more urgently. In JoinMarket we coded a protocol where
> the maker could contribute to miner fees, but the market price offered
> of that trended towards zero. So the reality is that takers will pay all
> the miner fees. Also because makers don't know the taker's time
> preference they don't know how much they should pay in miner fees.
>
> The taker will have to set limits on how large the maker's transactions
> are, otherwise makers could abuse this by having the taker consolidate
> maker's UTXOs for free.

Why not have the taker pay for the *first* maker-spent UTXO and have additional 
maker-spent UTXOs paid for by the maker?
i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 BTC", 
and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs).

Disagreements on feerate can be resolved by having the taker set the feerate, 
i.e. "the customer is always right".
Thus if the maker *has to* spend two UTXOs to make up the 0.4 BTC bag, it pays 
for the mining fees for that extra UTXO.
The maker can always reject the swap attempt if it *has to* spend multiple 
UTXOs and would lose money doing so if the taker demands a too-high feerate.


> == Contract transaction definitions ==
>
> Contract transactions are those which may spend from the 2-of-2 multisig
> outputs, they transfer the coins into a contract where the coins can be
> spent either by waiting for a timeout or providing a hash preimage
> value. Ideally contract transactions will never be broadcast but their
> existence keeps all parties honest.
>
> M~ is miner fees, which we treat as a random variable, and ultimately
> set by whichever pre-signed RBF tx get mined. When we talk about the
> contract tx, we actually mean perhaps 20-30 transactions which only
> differ by the miner fee and have RBF enabled, so they can be broadcasted
> in sequence to get the contract transaction mined regardless of the
> demand for block space.

The highest-fee version could have, in addition, CPFP-anchor outputs, like 
those being proposed in Lightning, so even if onchain fees rise above the 
largest fee reservation, it is possible to add even more fees.

Or not.
Hmm.


Another thought: later you describe that miner fees are paid by Alice by 
forwarding those fees as well, how does that work when there are multiple 
versions of the contract transaction?

>
> (Alice+timelock_A OR Bob+hash) = Is an output which can be spent
> either with Alice's private key
> after waiting for a relative
> timelock_A, or by Bob's private key by
> 

Re: [bitcoin-dev] reviving op_difficulty

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

2020-08-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Tier, Thomas, and aj,

> On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev 
>  wrote:
>
> > 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
>
> Any kind of opcode is a binary option.  Either the output can be spent or it 
> can't.
>
> You could get a pseudo-continuous future by having lots of outputs with 
> different thresholds.
>
> Alice and Bob create a transaction with 100 outputs and each having 1% of the 
> future's value.
>
> Output 0:  Pay Alice if diff < 1.00 trillion else Bob
> Output 1:  Pay Alice if diff < 1.01 trillion else Bob
> 
> Output 98:  Pay Alice if diff < 1.98 trillion else Bob
> Output 99:  Pay Alice if diff < 1.99 trillion else Bob
>
> If the difficulty is 1.25 trillion, then Alice gets outputs 0-24 and Bob gets 
> outputs 25-99.  The future has a tick size of 1%.  It isn't very efficient 
> though

Taproot MAST to the rescue.

* Alice and Bob agree on the number of ticks N and payout schedule.
* Alice and Bob generate N fresh keypairs and share them.
* Alice and Bob generate tapleaf scripts of the form:
  * script[i] = Alice[i] && Bob[i] && diff < 1.00 trillion + i * tick_size && 
CLTV(deadline)
* Alice and Bob generate the taproot MAST for the above scripts.
* Alice and Bob generate, but do ***NOT*** sign, a funding transaction paying 
out to the generated taproot MAST.
* Bob generates partial signatures for N payout transactions, with 
lower-difficulty-targets paying out less to Alice and more to Bob, and 
higher-difficulty-targets paying out more to Alice and less to Bob.
  * This requires spending the [i]th tapleaf script with the appropriate 
difficulty target.
* Alice saves all the Bob signatures.
* At deadline, Alice rationally selects the highest-paying version that is 
still acceptable, based on the actual difficulty target at the time.

This requires publishing only O(log N) data (the merkle path to the selected 
tapleaf).
This translates to the 100-tick example requiring only one TXO, 1 scripthash, 
and 7 or so Merkle-tree-path hashes, compared to the above example which 
requires 100 TXOs and 100 script hashes.

The same scheme can be used with `OP_CTV` and without keypairs being involved, 
but basically anything `OP_CTV` can do, signing keypairs with pre-generated 
signatures from all participants can do just as well, with higher storage and 
setup costs.

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


Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

2020-08-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Matt,

> Hmm, apologies that little context was provided - this was meant in the 
> context of the current crop of relay-based attacks that have been discovered. 
> As we learned in those contexts, “just handle it when it confirms” doesn’t 
> provide the types of guarantees we were hoping for as placing commitment 
> transactions in mempools can be used to prevent honest nodes from 
> broadcasting the latest state. This implies that HTLC security may be at risk.
>

Ah, okay.

So the attack is this:

* Attacker connects twice to the LN: one to any node near the victim, one to 
the victim.
* Attacker arranges for the attacker-victim channel to have most funds in the 
side of the victim.
* The attacker routes a circular payment terminating in the victim-attacker 
channel.
  * The victim accepts some incoming HTLC, and provides an outgoing HTLC to the 
attacker via the victim-attacker channel.
* The attacker broadcasts a very low-fee old-state transaction of the 
victim-attacker channel, one that is too low-fee to practically get confirmed, 
just before the HTLC timeout.
* The victim-outgoing HTLC times out, making the victim broadcast a unilateral 
close attempt for the victim-attacker channel in order to enforce the HTLC 
onchain.
  * Unfortunately for the victim, relay shenanigans prevent the latest 
commitment from being broadcast.
* The attacker waits for the victim-incoming HTLC to timeout, which forces the 
victim to `update_htlc_failed` the incoming HTLC or risk having that channel 
closed (and losing future routing fees).
  * The attacker now gets back its outgoing funds.
* The attacker lets the old-state transaction get relayed, and then re-seats 
the latest update transaction to that.
* Once the latest transaction allows the HTLCs to be published, the attacker 
claims the victim-outgoing HTLC with the hashlock branch.
  * The attacker now gets its incoming funds, doubling its money, because that 
is how the "send me 1 BTC I send you 2 BTC back" Twitter thing works right?

Hmmm.

The only thing I can imagine helping here is for the forwarding node to drop 
channels onchain "early", i.e. if the HTLC will time out in say 14 blocks we 
drop the channel onchain, so we have a little leeway in bumping up fees for the 
commitment transaction.
Maybe.
I am sure Matt can find yet another relay attack that prevents that, at this 
point, haha.

"Are we *still* talking about onchain fees?" - Adelaide 2018

Regards,
ZmnSCPxj




> > On Aug 4, 2020, at 00:23, ZmnSCPxj zmnsc...@protonmail.com wrote:
> > Good morning Matt,
> >
> > > While I admit I haven’t analyzed the feasibility, I want to throw one 
> > > additional design consideration into the ring.
> > > Namely, it would ideally be trivial, at the p2p protocol layer, to relay 
> > > a transaction to a full node without knowing exactly which input 
> > > transaction that full node has in its mempool/active chain. This is at 
> > > least potentially important for systems like lighting where you do not 
> > > know which counterparty commitment transaction(s) are in a random node’s 
> > > mempool and you should be able to describe to that node that you are 
> > > spending then nonetheless.
> > > This is (obviously) an incredibly nontrivial problem both in p2p protocol 
> > > complexity and mempool optimization, but it may leave SIGHASH_NOINPUT 
> > > rather useless for lighting without it.
> > > The least we could do is think about the consensus design in that 
> > > context, even if we have to provide an external overlay relay network in 
> > > order to make lighting transactions relay properly (presumably with 
> > > miners running such software).
> >
> > Ah, right.
> > A feasible attack, without the above, would be to connect to the fullnode 
> > of the victim, and connect to miners separately.
> > Then you broadcast to the victim one of the old txes, call it tx A, but you 
> > broadcast to the miners a different old tx, call it B.
> > The victim reacts only to tA, but does not react to B since it does not see 
> > B in the mempool.
> > On the other hand --- what the victim needs to react to is onchain 
> > confirmed transactions.
> > So I think all the victim needs to do, in a Lightning universe utilizing 
> > primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events 
> > and ignore mempool events.
> > So if we give fairly long timeouts for our mechanisms, it should be enough, 
> > I think, since once a transaction is confirmed its txid does not malleate 
> > without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" to 
> > that txid, unless a reorg unconfirms the transaction.
> > We only need to be aware of deep reorgs and re-broadcast with a malleated 
> > prevout until the tx being spent is deeply confirmed.
> > In addition, we want to implement scorch-the-earth, keep-bumping-the-fee 
> > strategies anyway, so we would keep rebroadcasting new versions of the 
> > spending transaction, and spending from a 

Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

2020-08-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Matt,

> While I admit I haven’t analyzed the feasibility, I want to throw one 
> additional design consideration into the ring.
>
> Namely, it would ideally be trivial, at the p2p protocol layer, to relay a 
> transaction to a full node without knowing exactly which input transaction 
> that full node has in its mempool/active chain. This is at least potentially 
> important for systems like lighting where you do not know which counterparty 
> commitment transaction(s) are in a random node’s mempool and you should be 
> able to describe to that node that you are spending then nonetheless.
>
> This is (obviously) an incredibly nontrivial problem both in p2p protocol 
> complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather 
> useless for lighting without it.
>
> The least we could do is think about the consensus design in that context, 
> even if we have to provide an external overlay relay network in order to make 
> lighting transactions relay properly (presumably with miners running such 
> software).

Ah, right.

A feasible attack, without the above, would be to connect to the fullnode of 
the victim, and connect to miners separately.
Then you broadcast to the victim one of the old txes, call it tx A, but you 
broadcast to the miners a *different* old tx, call it B.
The victim reacts only to tA, but does not react to B since it does not see B 
in the mempool.

On the other hand --- what the victim needs to react to is *onchain* confirmed 
transactions.
So I think all the victim needs to do, in a Lightning universe utilizing 
primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events and 
ignore mempool events.

So if we give fairly long timeouts for our mechanisms, it should be enough, I 
think, since once a transaction is confirmed its txid does not malleate without 
a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" to that txid, 
unless a reorg unconfirms the transaction.
We only need to be aware of deep reorgs and re-broadcast with a malleated 
prevout until the tx being spent is deeply confirmed.

In addition, we want to implement scorch-the-earth, keep-bumping-the-fee 
strategies anyway, so we would keep rebroadcasting new versions of the spending 
transaction, and spending from a transaction that is confirmed.

Or are there other attack vectors you can see that I do not?
I think this is fixed by looking at the blockchain.

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


Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

2020-08-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Richard,

> Thanks AJ for the updated BIP - very exciting!
>
> I'm also interested in this in the context of a Taproot version of 
> Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your 
> thoughts on how this would work. I have had some difficulty understanding 
> when someone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this is 
> a clever demonstration of how the differences can be exploited.
>
> I sketched out the protocol you described to help my understand it (below) 
> and some questions came to mind:
>
> 1) If you do a collaborative close, would you need to use script-path 
> spending, or could you use key-path spending instead to improve privacy?

It can (and should) use key-path, yes.

>
> 2) You mention 1.5 round trips for the (two party) MuSig signing session. 
> Must there be separate 1.5 round trips for each of the two signatures 
> produced (update, settlement) for each state update?

I believe we can amortize this slightly by providing the `R` commitments for 
the *next* signing session with the `s` for the *current* signing session, 
reducing to 1.0 round trips.

However, I believe a provably-safe 2-round MuSig (with composable MuSig even!) 
is being worked on and should be released in a week or two, and if it is safe 
to provide the first round of the *next* session with the final round of the 
*current* session then we could reduce it to just one (large) message send per 
update.

>
> 3) A related question: can the 1.5 round trips for signing be combined with 
> the 1.5 round trips required to update the channel (ie. A signs settlement 
> tx, B signs settlement & update txs, A signs update tx)? 
>
> Perhaps something like this:
>  -> A provides partial signature for settlement tx
>  <- B provides complete signature for settlement tx and partial signature for 
> update tx
>  -> A provides complete signature for update tx

My understanding (which might be incorrect!) is that it should be safe to 
perform the signing sessions for the settlement and update txes simultaneously, 
i.e.

* round 1: send `R` commitments for both update and settlement tx (can be sent 
with round 3 of previous signing session).
* round 2: send `R` for both update and settlement tx.
* round 3: send `s` for both update and settlement tx.

Depending on how we do the HTLCs / PTLCs, we might also need to send signatures 
for all HTLCs, in parallel with the update+settlement tx signatures, as well.

> 4) I'm not sure why AJ's formulation included an addition sig(X), but 
> otherwise is it similar to what you're suggesting?
>   
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html

This might have been the "chaperone signatures" proposed for `SIGHASH_NOINPUT` 
/ `SIGHASH_ANYPREVOUT` back then.
This was supposed to protect against replaying a `SIGHASH_ANYPREVOUT` signature 
in case of address reuse.
I pointed out that it would be much simpler for a Lightning spec to provide a 
privkey for a common `X` used by all Lightning nodes, and thus would not really 
provide much better security in practice.


I believe what we intend now is a form of hidden output tagging to protect 
against signature replay.
An output has to have a special taproot version in order to be spent with 
`SIGHASH_ANYPREVOUT` or `SIGHASH_ANYPREVOUTANYSCRIPT` in the script path, and 
`SIGHASH_ANYPREVOUT`/`SIGHASH_ANYPREVOUTANYSCRIPT` is not usable with key path 
spends.


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


Re: [bitcoin-dev] Smaller Transactions with PubRef

2020-08-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Mike,

The issue with SCRIPT re-evaluation is that reorgs cause more processing to be 
done by nodes.

Floating-point Nakamoto Consensus does not help here, since a node can receive 
the lower-scored block first, and *then* a higher-scored block, and thus will 
***still*** observe a reorg since the chain tip is replaced with a 
higher-scored block later.

This still increases the processing load on validating fullnodes, and prevents 
any kind of pruning from working for validating fullnodes.

A miner can also still mount a DoS on validating fullnodes, with `OP_PUBREF` 
and Floating-Point Nakamoto Consensus by re-mining the same block, and 
broadcasting a block if it has higher score than the previous chain tip.
This locks the blockchain ***and*** increases the load on fullnodes, which have 
to re-validate uses of `OP_PUBREF` that might refer to the chain tip.

Regards,
ZmnSCPxj

> Hey  ZmnSCPxj,
>
> Re-orgs should be solved in a different way. 
>
> Best Regards,
> Micahel
>
> On Sat, Aug 1, 2020 at 5:36 PM ZmnSCPxj  wrote:
>
> > Good morning Mike,
> >
> > Hard NAK.
> >
> > The responses to the original posting already pointed out important 
> > problems with this:
> >
> > * Encourages address reuse, hurting fungibility and privacy.
> > * Prevents pruning, since access to previous blocks must always be 
> > available in order to validate.
> > * Optimized implementation requires creating yet another index to previous 
> > block data, increasing requirements on fullnodes.
> > * Requires SCRIPT to be re-evaluated on transactions arriving in  
> > newblocks, to protect against reorgs of the chaintip, and in particular 
> > `OP_PUBREF` references to near the chaintip.
> >
> > None of these issues have been addressed in your current proposal.
> > The proposal looks at clients only, without considering what validators 
> > have to implement in order to validate new blocks with this opcode.
> >
> > Regards,
> > ZmnSCPxj


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


Re: [bitcoin-dev] Smaller Transactions with PubRef

2020-08-01 Thread ZmnSCPxj via bitcoin-dev
Good morning Mike,

Hard NAK.

The responses to the original posting already pointed out important problems 
with this:

* Encourages address reuse, hurting fungibility and privacy.
* Prevents pruning, since access to previous blocks must always be available in 
order to validate.
* Optimized implementation requires creating yet another index to previous 
block data, increasing requirements on fullnodes.
* Requires SCRIPT to be re-evaluated on transactions arriving in  newblocks, to 
protect against reorgs of the chaintip, and in particular `OP_PUBREF` 
references to near the chaintip.

None of these issues have been addressed in your current proposal.
The proposal looks at clients only, without considering what validators have to 
implement in order to validate new blocks with this opcode.

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


Re: [bitcoin-dev] Implementing Investment Aggregation

2020-07-21 Thread ZmnSCPxj via bitcoin-dev
Good morning Hilda,

> Good Day ZmnSCPxj,
>
> Thanks for sharing the idea! I read through the doc and have some concerns 
> that might be off the topic or outside the scope. Please bear with me.
>
> The traditional banking system provides more than custodial holding of funds 
> in terms of lending & borrowing. One important function is to match long term 
> investments with short or variable term deposits. Alice might be willing to 
> make investments at time 0, but some emergency occurs and she may need (part 
> of) her bitcoins back at time 1 before the loan due date. 

This may be possible by using a Decker-Russell-Osuntokun ("eltoo") mechanism.

The laon-payback transaction (the one that is signed with `SIGHASH_ANYPREVOUT`) 
can, instead of paying out directly to the investors, pay out to a 
Decker-Russell-Osuntokun mechanism that is signed by a MuSig of the investors 
plus the coordinator.

The initial state of this mechanism is the payouts of each investor, in 
proportion to the amounts they lent out.
Thus, if none of the investors need to liquidate early, this initial state is 
what gets posted on the blockchain ***if*** the loaning business successfully 
pays back / does not default.

If one of the investors needs to liquidate its position in this loan agreement, 
the coordinator can offer to buy its position (in whole or in part) for a 
smaller amount (as the coordinator takes on more risk).
Then all the investors plus the coordinator sign a new state of the 
Decker-Russell-Osuntokun mechanism, with the coordinator getting more funds, 
and the liquidating investor losing all or part of its allocation.
The investor doing the liquidation can demand a pay-for-signature, so that its 
signature share of the new state is only acquired by the coordinator if and 
only if it actually gets paid with Bitcoins now.

The position need not be bought by the coordinator --- one of the other small 
investors in the business can "double down" and purchase more of the share of 
the eventual loan-payback by the same mechanism, from peer investors who need 
to liquidate their position in the loan-payback early, increasing its risk 
exposure but potentially getting even more profit in case the invested business 
pays back the loan.


>
> Also, in the banking system, there are usually sophisticated risk analysis 
> systems covering formulas, due diligence, and funds for loan defaults. Banks 
> can reinvest partial of what they namely have and obtain profits to cover 
> possible losses when borrowers cannot pay back 100%. In this way, they are 
> more resilient to defaults & change of collaterals' value, and borrowers 
> might be able to leverage 1 unit worth of collateral to get 3 units fund 
> instead of 1. 

Similar constructions could be done by the coordinator and / or the investors 
directly; unfortunately I know too little of them to give an idea how this can 
be done.

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


Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

2020-07-21 Thread ZmnSCPxj via bitcoin-dev
Good morning Andy,

> > A Cryptographic Notion of Time
> >
> > ===
> >
> > Time stops for no one; it will not stop for thee.
> > Or, in more science-appropriate terms: the passage of time is the direction 
> > in which universal entropy increases.
> > Now, we can observe that block header hashes are, in fact, low-entropy.
> > This is because the higher bits of block header hashes are consistently 0; 
> > there are thus fewer bits of entropy you can extract from a block header 
> > hash.
> > Now, we can observe that temperature is largely itself also an expression 
> > of entropy.
> > Higher-entropy areas are higher temperature, and lower-entropy areas are 
> > lower temperature
>
> , at constant pressure

True.

> > .
>
> Or, at constant temperature, higher entropy areas have lower pressure
> and lower entropy areas have higher pressure. See the background contour
> of the figure on the bottom left here for an example with carbon dioxide:
>
> http://andyschroder.com/CO2Cycle/Explorer?DatasetNumber=1&0_ValueIndex=Optimal=0&1_ValueIndex=Optimal=1&2_ValueIndex=Optimal&3_ValueIndex=Optimal&4_ValueIndex=Optimal&5_ValueIndex=0&6_ValueIndex=0&7_ValueIndex=0&8_ValueIndex=0&9_ValueIndex=0&10_ValueIndex=0&11_ValueIndex=0&12_ValueIndex=0=efficiency=efficiency=Temperature=Pressure=Entropy

Yes, PVT relation.

> > Overall, the temperature differential across the universe decreases in the 
> > direction of future time.
> > However, it is possible to implement a sort of Maxwell's Demon.
> > Maxwell's Demon is an entity that guards a hole between two containers 
> > containing air.
> > If a high-speed, high-tempreature molecule of air on the left side 
> > approaches the hole, Maxwell's Demon magically swats it away, but if a 
> > similar high-speed, high-temperature molecule of air on the right side 
> > approaches the hole, Maxwell's Demon lets it pass.
> > It has the reverse policy for low-temperature molecules of air, letting it 
> > go from the left container to the right container.
> > Over time, the temperature of the right container drops, because all the 
> > high-temperature molecules have been moved to the left container.
> > Of course, we already have implementations of Maxwell's Demon.
> > We call such implementations "refrigerators".
>
> Don't know why I never thought of it this way!
>

Yes.

> > Refrigerators, to do their magic, must consume energy and emit heat.
> > Indeed, the total heat emitted by the refrigerator is much larger than the 
> > heat it removes in the cold part of the refrigerator.
>
> Not necessarily "much larger". For example, a good geothermal heat pump
> has a COP greater than 8. That means 8 units of heat are removed for 1
> unit of work input. That means that the total heat emitted by the
> refrigerator is only (1-(8+1)/8) = 12.5% higher than the heat it removes
> from inside the refrigerator.
>

Granted.
I am now investigating geothermal heat pumps in the context of taking over the 
world, thank you for your information.

> > We can verify that the refrigerator is working, trivially, by checking that 
> > the supposedly-cold part of the refrigerator is indeed cold
>
> and it's temperature does not begin to rise over time.
>
> > But we know that refrigerators, to do their work, must consume
>
> mechanical
>
> > energy and emit heat.
> > And we also know that, due to the heat emitted by the refrigerators, the 
> > universal level of entropy increases, and we know thereby a direction of 
> > time is equivalent to a refrigerator successfully freezing something.
>
> However, the entropy inside a chamber can still decrease if the pressure
> goes up and heat is allowed to conduct away as the temperature tries to
> go up. This however, also results in more work being input into the
> refrigerator, which means it still consumes energy. Also, if you are
> okay with the temperature inside a chamber going up (instead of down),
> you can consume energy and compress it adiabatically and the pressure
> will rise and so will the entropy rise.
>
> > .
> > Similarly, in order to create low-entropy ("cold") block header hashes, 
> > miners of Bitcoin must consume energy and emit heat.
> > Bitcoin miners then act similarly to Maxwell's Demon; they reject candidate 
> > blocks whose block header hashes are not "cold enough" (i.e. have entropy
>
> production
>
> > greater than the difficulty target), and only allow "cold" block headers to 
> > be broadcast over the blockchain.
>
> Blocks freeze the transactions in place!

Certainly an interesting thought!

>
> Or, blocks compress transactions in place.
>
> > And since we know that:
> >
> > -   The future is where the universal entropy is larger than the past.
> > -   Miners producing blocks must consume energy and emit waste heat 
> > (increasing universal entropy).
> >
> > ...then we know that a longer proof-of-work header chain represents more 
> > actual physical time passing.
> > Proof-of-work is therefore also an 

[bitcoin-dev] Implementing Investment Aggregation

2020-07-20 Thread ZmnSCPxj via bitcoin-dev
Introduction


In a capitalist economic system, it is allowed for an entity to lend money out 
to another entity, as long as both agree upon the conditions of the loan: how 
long, how much interest, any collateral, etc.
This is a simple extension of basic capitalist economic thinking: that the 
owner of funds or other capital, is the one who should decide how to utilize 
(or not utilize) that capital, including the decision to lend (or not lend).

It has been observed as well that groups of people may have relatively small 
savings that they can afford to put into investment (i.e. loaning out for an 
interest rate), but as the technological capabilities of our shared 
civilization have expanded, the required capital to create new businesses or 
expand existing ones have grown much larger than most single individuals can 
invest in.

Thus, coordinators that aggregate the savings of multiple individuals, and then 
lend them out for interest to new or expanding businesses, have also arisen, in 
order to take advantage of the larger return-on-investment of more 
capital-intensive but high-technology businesses, capturing the long tail of 
small investors.
Traditionally, we call these coordinators "banks".

However, this typically involves delegating the work of judging whether a 
business proposal is likely to give a return on investment, or not, to the 
coordinator itself.
Further, the coordinator typically acts as a custodian of the funds, thus 
adding the risk of custodial default to the small-time investors in addition to 
loan default.
(In this view-point, central banks that provide fiscal insurance in case of 
loan default by printing new money, are no different from custodial default, as 
they degrade the monetary base in doing so.)

This writeup proposes the use of features that we expect to deploy at some 
point in the future, to allow for a non-custodial coordinator of multiple small 
investors.

This is not a decentralized system, as there is a coordinator; however, as the 
coordinator is non-custodial, and takes on the risk of default as well, the 
risk is reduced relative to a centralized custodial solution.

Note that custodiality is probably a much bigger risk than centralization, and 
a centralized non-custodial probably has fewer risks than a decentralized 
custodial setup.
In particular, a decentralized custodial setup can be emulated by a centralized 
custodial setup using sockpuppets, and without any decent sybil protection 
(which can be too expensive and price out investments by the long tail of small 
investors, thus leading to centralization amongst a few large investors 
anyway), is likely no better than a centralized custodial setup.
Focusing on non-custodiality rather than decentralization may be a better 
option in general.

A group of small investors may very well elect a coordinator, and since each 
investor remains in control of its funds until it is transferred to the lendee, 
the coordinator has no special power beyond what it has as one of the small 
investors anyway, thus keeping decentralization in spirit if not in form.

Non-custodial Investment Aggregation


In principle, if a small investor finds a potentially-lucrative business that 
needs capital to start or expand its operation, and promises to return the 
loaned capital with interest later, then that small investor need not store its 
money with anyone else: it could just deal with the business itself directly.

However, the small investor still needs to determine, for itself, whether the 
business is expected to be lucrative, and that the expected return on 
investment is positive (i.e. the probability of non-default times (1 plus 
interest rate) is greater than 1, and the absolute probability of non-default 
fits its risk profile).
We will not attempt to fix this problem here, only the requirement (as with the 
current banking system) to trust some bank **in addition to** trusting the 
businesses that are taking on loans to start/expand their business.

(again: not your keys not your coins applies, as always; investors are taking 
on risk of default.)

The coordinator need only do something as simple as find a sufficiently large 
set of entities that are willing to indicate their Bitcoin UTXOs as being 
earmarked for investment in a particular business.

The coordinator, upon finding such a set, can then create a transaction 
spending those UTXOs and paying unilaterally to the business taking the loan.
The business provides proof that the destination address is under its 
unilateral control (so that investors know that they only need to trust that 
the business itself will do everything in its power to succeed and pay back the 
loan, without having additional trust in the coordinator to hold their funds in 
custody).
Then the individual investors sign the transaction, releasing their funds to 
the business.

However, the issue now arises: suppose the business succeeds 

Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

2020-07-20 Thread ZmnSCPxj via bitcoin-dev
Good morning list,

Andy Schroder shared a mildly related link: 
http://andyschroder.com/DistributedCharge/

The above project does not use the Cryptographic Relay.
Briefly, it is a rentable charging station for electric cars.

I observed, however, that a rentable Cryptographic Relay device could be 
implemented using Cryptographic Relay features:

* Support for MuSig (by use of Schnorr signatures).
* Timelocks (by use of block header chains).
* Delegated operators.

> Suppose you own a Cryptographic Relay controlling a charger for electrical 
> cars.
> And I wish to rent this charger for some time so I can charge my electrical 
> car.
>
> This rental contract can be done by this ritual:
>
> * We generate two fresh keypairs.
>   * Call the first keypair the "rent-transfer" keypair.
>   * Call the second keypair the "rental-period" keypair.
> * You generate, but do not sign, a rent-transfer command to transfer 
> ownership from your unilateral ownership to the MuSig of our rent-transfer 
> keys.
> * We generate an initial backout command to transfer ownership from the MuSig 
> rent-transfer key back to your control, but with an `nLockTime` in the close 
> future.
>   We sign this command.
> * We generate a rental-start command to transfer ownership from the MuSig 
> rent-transfer key to our MuSig rental-period key.
>   I create a partial signature, missing only your share.
> * We generate a command to add me as a delegated operator of the device, 
> authorized by the MuSig rental-period key.
> * We generate a rental-end command to transfer ownership from the MuSig 
> rental-period key, back to your unilateral control, with an `nLockTime` equal 
> to the end of the rental period.
>   We sign this command.
> * Then, I create (but do not sign!) a rent-funding Bitcoin transaction for 
> the rent, paying to the Musig rent-transfer key.
> * We generate a rent-reclaim Bitcoin transaction spending the above 
> rent-funding Bitcoin transaction, sending the funds back to my unilateral 
> control, but with an `nLockTime` in the future but less than the timeout of 
> the initial backout command.
>   We sign this transaction.
> * You sign the rent-transfer command and feed it to the device.
> * We generate a rent-claim Bitcoin transaction spending the above 
> rent-funding Bitcoin transaction, sending the funds to your unilateral 
> control.
>   I demand an adaptor signature, such that I can learn your share of the 
> signature of the rental-start command.
>   Then I provide a partial signature to you.
> * You complete the rent-claim Bitcoin transaction signature, claiming the 
> rental fee.
> * I get the completed rental-start command signature and send it to the 
> device, transferring ownership of the device to our MuSig rental-period 
> pubkey.
> * I send the command to add me as an operator of the device, letting me use 
> the device as I see fit, but not transfer ownership to anyone else.
> * When the rental period ends, you send the rental-end command to the device 
> and turn it off so I can no longer use it.
>
> The above can probably also be done with the Bitcoin-side payments done via 
> Lightning-with-PTLC.
> It requires Taproot, but does not require `SIGHASH_ANYPREVOUT`.

We can also consider the case where the renter of the device wishes to return 
it early, for a partial refund of the total rent (or equivalently, for the 
renter to rent in units of smaller time and just extending the rental period as 
needed).

> As the ownership of the device is in a 2-of-2 between the renter and the 
> "true owner", they can, after having a meeting of minds, arrange for an early 
> return command conditional on a partial refund of the original rent.
> Again, there is simply a need for pay-for-signature, with the renter 
> partial-signing a command to return the device ownership early, which if 
> completed by the owner, completes the signature to refund the original rent.
>
> Alternately, the rent may pay for a short rental period, and to extend the 
> rental period, the 2-of-2 between the nenter and "true owner" on the device 
> is "reseated" (i.e. fresh keypairs to generate a fresh 2-of-2 are created and 
> ownership transferred to the new 2-of-2) which invalidates the previous 
> timeout, and moves to a later timeout.
> The "re-rental" command which moves the ownership from the previous 2-of-2 to 
> the next 2-of-2 is partially signed by the renter, and to complete the 
> signature, the renter pays for the signature share from the owner.
> (this is done after setting up the command to make the renter a delegated 
> operator and the command to let the owner re-acquire unilateral ownership of 
> the device, I elide those steps here.)
> The pay-for-signature can be done over Lightning as well.

Now, suppose the device being rented out is in fact a smart domicile, which can 
be locked/unlocked by the owner/operator of a Cryptographic Relay.
Typically, when renting out domiciles, a deposit is involved, where:

* The 

[bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

2020-07-20 Thread ZmnSCPxj via bitcoin-dev
Introduction


An electrical relay is an electrically-controlled switch, often diagrammed as:

  +-o
  |
  |   \
  |\
  +--o  o---o

o  |
 ) |
 ) |
 ) |
o  |

The terminals at the left feed into a coil.
When electricity passes through the coil, it magnetizes a core, and the 
magnetism attracts a switch into a closed position, which would let electricity 
to pass through the terminals at the right.
This can be used to "turn on" or supply power to a different electrical device.

If no electricity is passing through the coil via the terminals on the left, 
then no electricity can pass through the terminals on the right, as the switch 
is an open position at default.

This is a fairly simple logic circuitry, upon which more complicated circuitry 
can be made.

Similarly, a Cryptographic Relay is a hardware electrical component that allows 
control of some electrical circuit.
It has two terminals which are the two terminals of a switch.
It can also be contacted, for example via Bluetooth, by an electronic computing 
device.
The Cryptographic Relay has a public key, which represents the current owner of 
the relay.
If the electronic device is able to provide a proof-of-knowledge of the private 
key (i.e. a signature) corresponding to the public key that the Cryptographic 
Relay knows, then it allows the switch to be controlled by that device.

Motivation
==

Suppose I have a car I wish to sell to you, for Bitcoins.
This car, as it happens, has a Cryptographic Relay: it will only start its 
engine if it gets a signed message from me using a private key I have on my 
phone.
It knows my public key, and will only turn off and on at my command.

Now, you want to be able to know that by paying me Bitcoins, you get sole 
ownership of the car I am selling.

This is in fact, nothing more than a swap operation.
I have an asset, a car, and you have an asset, some Bitcoins.
We want to atomically swap one asset for the other asset, and those assets do 
not exist in a single asset-assignment system.

Paying Bitcoins For Cars Via Succinct Atomic Swaps
==

Fortunately, there is an atomic swap operation, Succinct Atomic Swaps, which 
can be used to create an atomic swap between my car and your Bitcoins.

An important part of this Succinct Atomic Swap is that all timeouts are only in 
one asset-assignment system.
The original Succinct Atomic Swap discussion gives an example of swapping 
Bitcoins for Litecoins.
Each has its own distinct blockchain, which is a distinct distributed 
asset-assignment system.

A crucial part of the Succinct Atomic Swap is that all timelocks are only on 
one asset-assignment system.
The other asset-assignment system need not support anything other than 
assigning ownership of assets to (homomorphically additive) public keys.

This is important as a major simplification of the Cryptographic Relay:
The relay only needs to know its *current owner*, and does not need to know the 
current time!

Thus, in order for you to buy my car:

* You set up the Succinct Atomic Swap on the Bitcoin blockchain.
* We generate fresh private keys, then combine them via MuSig, and I transfer 
the ownership of the car to that MuSig public key.
* If I claim the funds, that atomically reveals my share of the private key to 
you, so you can claim the car using your private key plus my share and transfer 
the car to sole control of you.
* If I fail to claim the funds, then when you reclaim your funds at timeout, 
that atomically reveals your share of the private key to me, so that I can 
claim the car using my private key plus your share and transfer the car back to 
sole control of me.

This is in fact the same as the Succinct Atomic Swap example, except that 
instead of me swapping my Litecoins for your Bitcoins, I am swapping my 
Cryptographic Relay for your Bitcoins.

Cryptographic Relay Operations
==

Thus, a Cryptographic Relay needs to support only the following basic 
operations.
These operations are triggered by its owner sending a message, plus a signature 
verifiable by the public key, to the Cryptographic Relay.
(Cryptographer warning: if using Schnorr, the message hashed into the signature 
also has to include the public key that is signing it, since BIP32 nonhardened 
derivation allows a Schnorr signature created by one child private key to be 
trivially malleated into a signature for the same message by a sibling private 
key; this does not exist in ECDSA due to its nonlinearity.
message sends need not include the public key, it can be added by the 
cryptographic relay since it has to know the public key of the owner anyway.
Of note is that the bip-340 description of Schnorr includes the public key in 
the hash operation of signatures as well, and does not require this.)

The only operations necessary are:

1.  Turn on.
2.  Turn off.
3.  

Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-07-17 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

> On 13/06/2020 15:06, ZmnSCPxj wrote:
>
> > Good morning Chris,
> >
> > > Would it be fair to summarize the idea in this way:
> > > CoinSwappers can slow down the CoinSwap process which will give an
> > > opportunity for makers to use batching.
> >
> > I think so.
> > Regards,
> > ZmnSCPxj
>
> It's definitely a good idea. As well as improving privacy by pretending
> to be a service provider which uses batching, it may also be practical
> just because CoinSwap takers will want to slow down the process for
> greater privacy so that an adversary would have to search more of the
> blockchain to attempt to deanonymize them. Also, by being prepared to
> wait longer the takers will also save miner fees.

Despite the subject title, I have realized belatedly that the same kind of 
batching can be done by the taker as well.

For example, the taker can contact two makers in parallel to setup separate 
CoinSwaps with them.
Then the taker produces a transaction spending its funds and sending them out 
to two outputs.

If the taker uses P2PKH for receiving and change, and we use (via 2p-ECDSA) 
P2PKH 2-of-2 to anchor the swaps, then if both CoinSwap operations are 
successful, the transaction looks exactly like an ordinary 
pay-to-someone-and-get-back-change transaction.

Indeed, each of the two makers contacted, if they are not themselves colluding 
with each other, cannot really differentiate this from somebody doing a 
CoinSwap only with them, since the other output is indistinguishable from 
change.

I am uncertain how much extra privacy (or cheapness) this buys the taker, 
however.

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


Re: [bitcoin-dev] Thoughts on soft-fork activation

2020-07-16 Thread ZmnSCPxj via bitcoin-dev
Good morning list, BlueMatt and aj,

There is an idea circulating on IRC and elsewhere, which seems to be at least 
mildly supported by gmax and roconnor, which I will try to explain here.

(These are my words, so if there is some mistake, I apologize)

Basically:

* Deploy a BIP8 `lockinontimeout=true` `lockin=+42 months` (or 36 months, or 24 
months) at next release.
  * Pedanty note: BIP8 uses blockheights, not actual times.
* Then 1 year after `starttime`, ***if*** it is not activated yet:
  * Discuss.
  * If we think it is only because of miner apathy and user support seems good 
regardless, deploy a BIP91 reduced-threshold 80% that enforces the BIP8 bit.
* We hope that this will stave off independent attempts at a UASF with a 
faster timeout.
  * If we think there are real reasons not to continue with Taproot as-is, 
deploy an abort: a softfork that disallows transaction outputs with `OP_1 
<32-bytes>` `scriptPubKey` (other lengths and other versions are allowed).

This approximates what aj is proposing:

* Ultimately, we expect to deploy a BIP8 `lockinontimeout=true` that will have 
a timeout that ends +42 months after the first countdown, even with Modern 
Softfork Activation.
* The abort is roughly equivalent to the Modern Softfork Activation case where 
during the 6 month discussion period we decide not to deploy Taproot after all.
* The deployment of a BIP91 reduced-threshold 80% approximates what aj 
proposes, to reduce the threshold for activation later.

As I understand it, an advantage of this proposal is that we can deploy very 
quickly a relatively simple BIP8 `locktimeontimeout=true`, then continue debate 
on various details (is 80% too low? too high? are users actually deploying? are 
mining pools updating? etc) in parallel.
This lets the code into the hands of users where they can start deploying it 
and we can start getting better gauges on how well Taproot is supported.


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


Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories

2020-07-14 Thread ZmnSCPxj via bitcoin-dev
Good morning Mr. Lee,

> Sorry. Re-sending with correction to CC bitcoin-dev
>
> I am sorry if this was already brought up in previous threads. If I know
> lightning network correctly then HTLC is used to enforce settlements on
> blockchain if there is a dispute. Could a person lose money if their HTLC
> does not get confirmed in the timeframe or if an older HTLC gets
> confirmed first? I see different ways this could happen.
>
> One, if the blockchain is very saturated with other transactions. The
> reason we need lightning network is why it might have troubles with
> settlements?

This could happen, but the entire exercise is to move transactions off the 
blockchain, precisely to lower this risk.

Otherwise, transfers onchain will take a long time.
In practice, a long time to settle a payment will invalidate many real-world 
economic exchanges anyway (consider paying for food at a restaurant --- if your 
payments take days to settle, the food has gotten stale before the restaurant 
receives payment and releases your food).
Thus, if an onchain transfer takes a long time to settle, there is already risk 
of economic loss present.

By moving activity offchain, we reduce pressure onchain and improve settlement 
speeds on both offchain and onchain, reducing risk of economic loss due to 
delay.


> Two, competition from a different conflicting HTLC. A newer
> HTLC might not get confirmed before an older HTL.

I cannot make sense of this.

You cannot create conflicting HTLCs.
Either you have some free money to create an HTLC, in which case there is no 
possible conflict with an existing HTLC (the fund is reserved for HTLCs, or it 
is yours without further encumbrance).

Thus it is not possible to create a conflicting HTLC in any case: either you 
have funds (that are not already in an HTLC) to fund an HTLC and that HTLC 
cannot conflict with existing ones, or you have no funds and a new HTLC cannot 
be created until one of the HTLCs is resolved one way or another.

> Three, denial of service
> the lightning router so they never have a chance to send a settlement
> HTLC.

This is possible, but only that node risks loss.

The reason why unilateral close is always possible is to handle the case where 
a routing node comes offline.

If you have offered an HTLC to a routing node, you retain a timelock branch 
back to you (the "T" in HTLC).

If the routing node goes offline past the timelock in the HTLC, then you 
unilaterally close the channel and drop the HTLC onchain.
This is what lets you recover your funds.


>
> I found out about a recent attack technique that sounds like it might be
> similar called "flood and loot".

Roughly, my understanding of Flood and Loot is to make a lot of uneconomically 
tiny HTLCs going through a target victim forwarding node.
You make circular routes going from your own node back to yourself.
Then you refuse to actually claim the HTLCs sent back to yourself.

Then you go offline.
This means that the only way for the forwarding node to recover its funds is to 
drop the channel(s) involved onchain.
But if the HTLCs are many and tiny, they are simply too uneconomic to claim 
onchain, so they just lose the channel funds as fees.



>
> Is this a concern on lightning network?

Yes.
Work is being done (anchor commitments) to mitigate the effects of onchain fees 
on Lightning.

> I humbly say that I do not fully
> understand all of lightning network yet. I am working to grasp the idea.
> These are questions I look to find answer for. Another question I have. I
> did read the paper Scalable Funding of Bitcoin Micropayment Channel
> Networks. Would channel factories be better and eliminate my concern?

They would not.
Ultimately, your "final defense" is to drop the entire construction onchain 
until you reach the HTLCs and you can have the blockchain enforce the HTLC 
contract.

It would *help* to reduce blockchain bloat by reducing the size of transactions 
to create multiple channels, and thus also secondarily helps reduce onchain fee 
pressure and also reduce Flood-and-Loot (which is basically a layer-crossing 
attack, taking advantage of lower-layer fees to create attacks on higher 
layers).

But always the underlying problem remains: security costs something, and you 
have to pay for protection on the Internet when transacting with potentially 
untrusted (and untrustable) entities.
It seems unlikely that "security costs something" can be eliminated.
One can consider that modern-day state-imposed taxation is paying for security, 
for instance, of traditional face-to-face transactions.
With Bitcoin, you can choose to either transact and pay for security, or not 
transact and forgo what you would have bought.
With some tradeoffs, you can pay by other means that may be cheaper for you.


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


Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT

2020-07-09 Thread ZmnSCPxj via bitcoin-dev
Good morning aj,

It seems okay to me.

--

Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction 
could, in theory, have only a single internal taproot pubkey, `P = MuSig(A, B)` 
for a channel between A and B.

So the funding outpoint would be spent with a taprooted P + a single tapscript 
`<1> OP_CHECKSIG`.

Update transactions would be signed with the internal taproot pubkey using 
`SIGHASH_ANYPREVOUTANYSCRIPT`.
The update transaction output would be spendable with a taprooted P + a single 
tapscript ` OP_CHECKLOCKTIMEVERIFY OP_DROP <1> OP_CHECKSIG`.
Each update transaction would have a monotonically-increasing `nLockTime`, i.e. 
the above `index`.

Then a state transaction would be signed with the internal taproot pubkey using 
`SIGHASH_ANYPREVOUT`, which commits to the exact script including ``, which is unique for each update transaction.
Thus a state transaction can only spend the specific update transaction, but 
the update transaction can spend the funding outpoint or any update transaction 
outpoint.
State transaction input would have an `nSequence` requiring a relative locktime 
of the agreed-upon unilateral close delay.

The above assumes MuSig signing, which requires 1.5 round trips for a channel, 
or three broadcast rounds for a multiparticipant (n >= 3) construction.


Regards,
ZmnSCPxj

> Hello world,
>
> After talking with Christina ages ago, we came to the conclusion that
> it made more sense to update BIP 118 to the latest thinking than have
> a new BIP number, so I've (finally) opened a (draft) PR to update BIP
> 118 with the ANYPREVOUT bip I've passed around to a few people,
>
> https://github.com/bitcoin/bips/pull/943
>
> Probably easiest to just read the new BIP text on github:
>
> https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
>
> It doesn't come with tested code at this point, but I figure better to
> have the text available for discussion than nothing.
>
> Some significant changes since previous discussion include complete lack
> of chaperone signatures or anything like it (if you want them, you can
> always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no
> longer commits to the value (details/rationale in the text).
>
> Cheers,
> aj
>
> 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] MAD-HTLC

2020-07-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Dave,


> > > -   Inputs:
> > > -   Bob 1 BTC - HTLC amount
> > > -   Bob 1 BTC - Bob fidelity bond
> > > -   Cases:
> > > -   Alice reveals hashlock at any time:
> > > -   1 BTC goes to Alice
> > > -   1 BTC goes to Bob (fidelity bond refund)
> > > -   Bob reveals bob-hashlock after time L:
> > > -   2 BTC goes to Bob (HTLC refund + fidelity bond refund)
> > > -   Bob cheated, anybody reveals both hashlock and bob-hashlock:
> > > -   2 BTC goes to miner
> > >
> > > [...]
> >
> > The cases you present are exactly how MAD-HTLC works. It comprises two
> > contracts (UTXOs):
> >
> > -   Deposit (holding the intended HTLC tokens), with three redeem paths:
> > -   Alice (signature), with preimage "A", no timeout
> > -   Bob (signature), with preimage "B", timeout T
> > -   Any entity (miner), with both preimages "A" and "B", no timeout
> > -   Collateral (the fidelity bond, doesn't have to be of the same amount)
> > -   Bob (signature), no preimage, timeout T
> > -   Any entity (miner), with both preimages "A" and "B", timeout T
>
> I'm not these are safe if your counterparty is a miner. Imagine Bob
> offers Alice a MAD-HTLC. Alice knows the payment preimage ("preimage
> A"). Bob knows the bond preimage ("preimage B") and he's the one making
> the payment and offering the bond.
>
> After receiving the HTLC, Alice takes no action on it, so the timelock
> expires. Bob publicly broadcasts the refund transaction with the bond
> preimage. Unbeknownst to Bob, Alice is actually a miner and she uses her
> pre-existing knowledge of the payment preimage plus her received
> knowledge of the bond preimage to privately attempt mining a transaction
> that pays her both the payment ("deposit") and the bond ("collateral").
>
> Assuming Alice is a non-majority miner, she isn't guaranteed to
> succeed---her chance of success depends on her percentage of the network
> hashrate and how much fee Bob paid to incentivize other miners to
> confirm his refund transaction quickly. However, as long as Alice has a
> non-trivial amount of hashrate, she will succeed some percentage of the
> time in executing this type of attack. Any of her theft attempts that
> fail will leave no public trace, perhaps lulling users into a false
> sense of security.


This note seems to have gotten missed in discussion.

Another note is that from what I can tell, the preimages "A" and "B" can be 
provided by any miner.

If the fund value plus the collateral is large enough, it may incentivize 
competing miners to reorg the chain, redirecting the funds of the MAD-HTLC to 
themselves, rather than advance the blockchain state, at least until 
alternative transctions bump their fees up enough that the collateral + fund is 
matched.

This may not apply to Lightning at least if you do not go beyond the Wumbo 
limit, but *could* apply to e.g. SwapMarket, if it uses MAD-HTLCs.

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] MAD-HTLC

2020-07-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Ittay,


 The analysis in our MAD-HTLC paper shows that when all players are 
rational (i.e., make the best decisions), and have the greater strategy space 
(which is easy to achieve, 150 Loc), the subgame-perfect-equilibrium strategy 
(this is like Nash-equilibrium for dynamic 
gameshttps://en.wikipedia.org/wiki/Subgame_perfect_equilibrium) for even 
relatively-small fee is to support the attack. Putting it in game-theory terms 
-- strategy "exclude-Alice-until-timeout-then-include-Bob" results with higher 
utility than strategy "include-Alice-Tx-now" (and by definition, 
"include-Alice-Tx-now" does not dominante 
"exclude-Alice-until-timeout-then-include-Bob").

It may be helpful to think in terms of Prisoner Dilemma.


   | cooperate | betray
---+---+-
cooperate  | -1, -1| 0, -3
---+---+-
betray | -3, 0 | -2, -2

"include-Alice-Tx-now" imposes a greater cost on those playing 
"exclude-Alice-until-timeout-then-include-Bob" players, than the benefit that 
both miners play "exclude-Alice-until-timeout-then-include-Bob".

Basically, "cooperate" == "exclude-Alice-until-timeout-then-include-Bob", 
"betray" == "include-Alice-Tx-now".

One way to get around this is to invoke Iterated Prisoner Dilemma, but that 
requires that miners can identify other miners and to be able to act 
accordingly to how those other miners have acted in the past.
The entire point of Bitcoin mining is to allow strong anonymity of miners (not 
that this commonly happens in practice, given the habit of putting identifying 
information in coinbases).

Another way would be to have a higher system that polices its constituents and 
ensures that every miner plays "exclude-Alice-until-timeout-then-include-Bob", 
and punishes "include-Alice-Tx-now".
But that would be equivalent to a centralized cartel, and would be the death of 
Bitcoin anyway, at which point, all Bitcoin tokens will be worthless.


Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] MAD-HTLC

2020-07-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Ittay,

> Hi all,
>
> Itay from MAD-HTLC here. I feel like some details got lost along the way so 
> please let me get these sorted out.
>
> 1. Myopic and non-myopic miners:
> When we use the term myopic we mean a miner that optimizes transaction 
> selection for the next block with respect only to the next block. The term 
> non-myopic refers to a miner that optimizes transaction selection for the 
> next block with respect to several future blocks. To accommodate for the 
> stochastic nature of block creation these optimizations are of the expected 
> revenue. However, neither of these mean that these miners choose to act in a 
> way that reduces their expected revenue -- specifically, if from a 
> non-myopic's miner perspective including Alice's immediate transaction is 
> better off than waiting for Bob's future transaction, then this is what they 
> do.
>
> Consequently, saying that "being myopic" dominates "being non-myopic" is 
> incorrect -- myopic is included in being non-myopic, thus cannot be better 
> than it.

The term "dominates" here is a technical term in game theory.

A strategy dominates over another strategy if, in a mixed environment, the 
first strategy always wins more points than the second strategy, no matter what 
proportion they may initially start in the mixed environment.

For example, in an environment of prisoner dilemma games, a tit-for-tat 
strategy dominates over the always-betray strategy, which dominates over 
always-cooperate strategy.

The above is the use of the term "dominate", and not that somehow one strategy 
"contains" the other.
Always-betray does not contain always-cooperate.

It is immaterial that the non-myopic "contains" myopic strategy as a 
sub-strategy.
Sometimes, overriding a sub-strategy can lead to worse outcomes and you are 
better off sticking to the sub-strategy rather than an extended strategy that 
sometimes overrides the sub-strategy

(notice how mixed teams of computer+human are no longer dominant in chess, 
because computer chess AIs are now so sophisticated that on average, the human 
overriding the computer strategy often leads to worse outcomes than just 
following the computer; yet about a decade ago such mixed computer+human teams 
were dominant over pure-computer and pure-human teams; yet you could say the 
same, that the computer+human "includes" the pure-computer strategy, but 
nowadays does ***not*** dominate it).

Or: worse is better.


What matters is, if you make them compete in an environment, myopic strategies 
will consistently beat non-myopic strategies because the myopic miners will 
impose costs on the non-myopic miners.


>
> So, the next issue to address is estimation of how much of the hash rate is 
> actually non-myopic. Currently that answer is simple -- probably 0. Bitcoin 
> Core (97% of the blocks) doesn't offer these optimizations, and most likely 
> other clients do not have these as well. But, we showed this is rather 
> trivial to implement (150 LoC in Bitcoin Core), and theoretically can be 
> included in Core's next version AFAIK. Moreover, any miner can simply apply 
> our patch independently, achieving the same effect.
>
> Please note more elaborate optimizations are in miners' best interest, 
> especially as mining incentives transition from block minting to fees -- the 
> latter are becoming the main income source, and I believe less sophisticated 
> miners will miss out substantially. You can check out Phil Daian's paper 
> about front-running in Ethereum for example: https://arxiv.org/abs/1904.05234

Yes, but again: myopic strategies dominate over non-myopic strategies, thus 
implementing non-myopic strategies is pointless, since they will lose revenue 
in an environment where even a single miner is myopic.

It is immaterial that it takes only 150 LoC to implement non-myopia: if it 
earns less money in an environment where even a minority of blocks are created 
by myopic miners (much less 97%), nobody will use the non-myopic strategy and 
they will remain at negligible near-0% hashrate.

As they say, "you can't get to there from here".


> As common in game-theory papers, our analysis does assume Common Knowledge -- 
> all participants know all other participants, their available strategies and 
> utilities (Tejaswi et al.'s paper makes the same assumption). As commented 
> before, true, this is not always the case -- nodes might have different 
> mempools, and some might not have applied the optimization patch and act 
> myopically. Such miners are therefore "resisting" the attack -- as stated, by 
> including Alice's transaction they ruin other miners' potential profit from 
> Bob's high fee transaction.

The only additional assumption you are missing is that miners care about 
*themselves* and not about *all miners*.

Non-myopia may earn more money for *all* miners if *all* miners use it, but if 
a *single* miner starts using myopic strategies in a non-myopic environment, 
they will earn 

Re: [bitcoin-dev] MAD-HTLC

2020-07-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Tejaswi,



> > But if an attack happens during a fee spike, then even though we retain our 
> > current default `to_self_delay` of 144, we still have the ability to 
> > gradually and automatically move to higher fee regions until our 
> > transaction confirms, and we have a good excuse for it to present to users: 
> > "a fee spike was happening at the time, so you had to pay some extra miner 
> > fees".
>
> Agree on the UX. There is a tradeoff between the timelocked value of the 
> channel balance to Alice during benign vs malicious abandonment by Bob. In 
> your opinion, increasing the fees beyond 1% (and thereby cutting into Alice's 
> share itself) is a slightly better tradeoff than increasing to_self_delay. 

Currently, we say `to_self_delay` is a parameter of how long you can be 
offline, and is imposed on your counterparty (so its effect on you is to allow 
the counterparty to safely be offline for that long).
This explanation seems palatable to users; they understand that it is the 
counterparty which is asking this of them, and that they ask a similar number 
of their counterparty, which is also their own protection.

On the other hand, we do not really expect to get beyond 1% unless we are under 
attack, *or* the fee spikes are really, really bad.
So this seems a practical tradeoff for us over in Lightning-land.


> > And since you and your paper openly discusses it anyway, I would like to 
> > reveal that the MAD-HTLC argument does not apply to *just* HTLCs.
>
> We know. Maybe we should have made it clear in the paper that when we use the 
> Poon-Dryja channel construction, we use the idea that the knowledge of the 
> preimage of a hash is equivalent to knowing the private key of the revocation 
> public key. In fact, this is how the Poon-Dryja construction is explained in 
> McCorry's Ph.D thesis, and IMHO is easier to understand than the original 
> description in the Poon-Dryja paper (or Bolt #3, for that matter). 

Yes, I realized it a little after reading MAD-HTLC that it applied to all the 
other known channel mechanisms as well, not just HTLCs, and decided to 
investigate this topic further, and have been circumspect regarding this.

> You could further argue that the hashlock is an incidental artefact, and our 
> paper mostly refers to timelocked transactions. And the rest of your email 
> describes applications of timelocked (and obviously presigned) transactions, 
> which are all vulnerable to the same bribing attack. Additionally, the 
> Wattehnofer in our paper is the same Wattenhofer from the Duplex Channel 
> paper.

Yes, I agree that the hashlock is an incidental artefact.

What MAD-HTLC questions is our assumption that a valid transaction with an 
earlier locktime supersedes a valid transaction spending the same txout with a 
later locktime.
Whether it involves presigned transactions or hashlocks are incidental 
artefacts.
So for example, a SCRIPT `OP_IF  OP_ELSE <1 day> OP_CHECKSEQUENCEVERIFY 
OP_DROP  OP_ENDIF OP_CHECKSIG` would also be vulnerable to the MAD-HTLC 
argument.

(Indeed, BOLT spec uses something very much like that script, now that I look 
at it again; in our case the `` is a combination of keys from both parties, 
that cannot be signed with unless one party knows both sub-keys.)

>
> > My current analysis suggests that in practice, the MAD-HTLC argument does 
> > not apply at all (else I would not be revealing that all channel mechanisms 
> > are broken **if** the MAD-HTLC argument *does* apply), since the myopic 
> > strategy seems to be pretty much inevitably dominant at stable states.
>
> We agree. 
>  
>
> > But it would still be best to investigate further until we are fully 
> > convinced that the MAD-HTLC argument ("'earlier supersedes later' might be 
> > falsified by bribery") does not apply.
>
> I think this is the analysis our paper does, and perhaps it's our mistake 
> that we do not set the context better. We only mention (and propose fixes 
> for) Poon-Dryja channel construction, and Tier Nolan's Atomic Swap 
> construction. 
>
> We could have addressed Spilman's one-way channels or Decker-Wattenhofer 
> duplex channels, but that would have been pointless as they were never going 
> to make it into production after Poon-Dryja and subsequently, Eltoo were 
> proposed.

I suggested that, until `SIGHASH_ANYPREVOUT` gets enabled, the 
Decker-Wattenhofer construction (removing the duplex Spilman-like channels at 
the end and leaving just the decrementing-`nSequence` constructions) could be 
used for Ruben Somsen StateChains, so you might not want to dismiss that so 
readily.

The decrementing-`nSequence` mechanisms have the advantage that it does not 
require a punishment/revocation branch, similar to Decker-Russell-Osuntokun 
"eltoo", and thus would work just as well to implement statechains, at least 
until all the debates around `SIGHASH_ANYPREVOUT` settle and it gets deployed.

Similarly, the proposed CoinPool as well could be 

Re: [bitcoin-dev] MAD-HTLC

2020-07-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Tejaswi,

> > So it looks to me that scorched-earth is a possible mitigation against this 
> > attack.
>
> I don't follow this. We show that a reasonable value of fees and timelock are 
> enough to avoid the attack. Why scorch the earth?

Because your model only considers that a block might have only 0 or 1 
transactions, and there is no such thing as a mempool containing alternative, 
fee-paying transactions that the miner could include *instead*.

In reality, what a miner can earn from adding Alice transaction is the 
*difference* between the Alice transaction fee and the transaction that *just* 
misses getting included in the block because of feerate.

Thus, the f will not, in fact, *quite* be the Alice fee, but instead less than 
that.

Indeed if the Alice transaction fee is lower than the top 4 Mweight 
transactions in the mempool, the miner would be *losing* funds by including the 
Alice transaction.

My understanding is that we expect mempools to eventually never empty, as the 
block subsidy reduces over time, thus the payoff f for including the Alice 
transaction *instead of* some other transaction will be less than the Alice fee.


This effect also holds for Bob, but we can probably expect, all things being 
equal, that approximately the same value will be deducted from both the Bob 
bribe and Alice fee by the mempool effect.
Thus the ratio should really be (f - x) / (b - x), where x is the 
fee-of-transaction-that-just-misses-the-block.
At fee spikes, this x will go higher, and thus (f - x) / (b - x) will be far 
smaller than f / b and might even become negative, in which case the Alice 
transaction will not be confirmed even by myopic miners, because the Alice 
transaction will be below the top 4Mweight transactions in the mempool.


So it seems to me reasonable to use a *gradual* scorched earth policy, as it is 
not only resilient against this attack, but also to fee spikes.
Alice starts at the 1% reserve, then for every block that goes by, bumps up the 
fee.
Then Alice will settle at an (f - x) / (b - x) level that achieves the least 
weak miner that is known to run the myopic strategy.


I believe this is also better for UX --- people already accept that during high 
fee spikes, they end up paying more for onchain activities.
But boosting up `to_self_delay` is bad because it makes honest unilateral 
closes take longer, and we already get frownie faces from users about this 
parameter.
By using a gradual scorched-earth strategy we can start at the reserve level, 
and if we are not under attack and there is no fee spike, do not lose anything 
other than the reserve funds of the thief (which is not ours, but is instead 
that of the thief).
But if an attack happens during a fee spike, then even though we retain our 
current default `to_self_delay` of 144, we still have the ability to gradually 
and automatically move to higher fee regions until our transaction confirms, 
and we have a good excuse for it to present to users: "a fee spike was 
happening at the time, so you had to pay some extra miner fees".




And since you and your paper openly discusses it anyway, I would like to reveal 
that the MAD-HTLC argument does not apply to *just* HTLCs.
You make recommendations about `to_self_delay` and `channel_reserve_satoshis`, 
which are not parameters of Lightning HTLCs (those are stuff like `cltv_delta` 
and `final_cltv`), but are channel parameters.

The MAD-HTLC argument applies just as well to channel mechanisms themselves, 
***independently of*** any HTLCs they transport.

The MAD-HTLC paper has the following core argument:

* We currently assume that currently-valid transactions will inevitably 
supersede alternate transactions that are valid at a later block height, simply 
because of the time advantage.
  * However, the owner of a later-block-height transaction can bribe miners to 
defer confirmation of currently-valid transactions, until its 
later-block-height transaction is valid and confirms.

The above core argument is presented as applying to HTLCs.

However, the same argument actually **also** applies to all current offchain 
multiparticipant cryptocurrency systems (i.e. "channel mechanisms").

* Spilman
* Poon-Dryja (what we currently use in Lightning)
* Decker-Wattenhofer decrementing-`nSequence`
* Decker-Russell-Osuntokun

The [Khabbazian-Nadahalli-Wattenhofer "Timelocked Bribing" 
paper](https://eprint.iacr.org/2020/774.pdf) mentions the use of revoked 
transactions in a Poon-Dryja mechanism, but seems to imply that the issue is 
with the HTLC instantiated inside the revoked transaction.
But note that the paper describes recommendations for the `to_self_delay` 
parameter and also analyzes the `channel_reserve_satoshis` parameter, which are 
parameters of the ***Poon-Dryja*** mechanism, and **not** of the HTLCs 
instantiated inside it.

So, to be very clear, the MAD-HTLC argument applies to all the above mechanisms 
*even if HTLCs are not used at all*.
Or put 

Re: [bitcoin-dev] MAD-HTLC

2020-07-01 Thread ZmnSCPxj via bitcoin-dev
ic strategy, they would all earn more, the fact of the matter is that 
each miner works for themselves, and themselves alone, in a highly competitive 
environment.
Thus, even though they know *all of them* will benefit if they use the 
non-myopic strategy, they cannot be sure, unless they are all perfectly 
synchronized mind-clones of each other, that the other miners will rather be 
selfish and mine for themselves, even if in the end every miner earns less
The standard for success is to earn more *than your competitors*, not ensure 
that *every* miner earns more.

Fortunately, since miners are running a business, this competition leads to 
better services to the the customers of the mining business, a known phenomenon 
of the free market, yay free market greed is good.
The user Alice is a customer of the mining business.
Alice gets, as a side effect of this competitiveness of miners (which leads to 
miners adopting myopic strategies in order to gain an edge over non-myopic 
miners), improved security of their HTLCs without requiring slashable fidelity 
bonds or such-like that MAD-HTLC proposes.


Using this model, it seems to me that non-myopic miners can only maintain hold 
over the blockchain if all miners agree to use non-myopic strategy.
This is basically all miners forming a cartel / monopoly, which we know is 
detrimental to customers of the monopoly, and is the reason why we prefer 
decentralization.


Regards,
ZmnSCPxj




> On Mon, Jun 29, 2020 at 8:05 PM ZmnSCPxj via bitcoin-dev 
>  wrote:
>
> > Good morning Dave, et al.,
> >
> > > >      Myopic Miners: This bribery attack relies on all miners
> > > >
> > > >
> > > > being rational, hence considering their utility at game conclu-
> > > > sion instead of myopically optimizing for the next block. If
> > > > a portion of the miners are myopic and any of them gets to
> > > > create a block during the first T − 1 rounds, that miner would
> > > > include Alice’s transaction and Bob’s bribery attempt would
> > > > have failed.
> > > > In such scenarios the attack succeeds only with a certain
> > > > probability – only if a myopic miner does not create a block
> > > > in the first T − 1 rounds. The success probability therefore
> > > > decreases exponentially in T . Hence, to incentivize miners
> > > > to support the attack, Bob has to increase his offered bribe
> > > > exponentially in T .
> > >
> > > This is a good abstract description, but I think it might be useful for
> > > readers of this list who are wondering about the impact of this attack
> > > to put it in concrete terms. I'm bad at statistics, but I think the
> > > probability of bribery failing (even if Bob offers a bribe with an
> > > appropriately high feerate) is 1-exp(-b*h) where `b` is the number of
> > > blocks until timeout and `h` is a percentage of the hashrate controlled
> > > by so-called myopic miners. Given that, here's a table of attack
> > > failure probabilities:
> > >
> > > "Myopic" hashrate
> > > B 1% 10% 33% 50%
> > > l +-
> > > o 6 | 5.82% 45.12% 86.19% 95.02%
> > > c 36 | 30.23% 97.27% 100.00% 100.00%
> > > k 144 | 76.31% 100.00% 100.00% 100.00%
> > > s 288 | 94.39% 100.00% 100.00% 100.00%
> > >
> > > So, if I understand correctly, even a small amount of "myopic" hashrate
> > > and long timeouts---or modest amounts of hashrate and short
> > > timeouts---makes this attack unlikely to succeed (and, even in the cases
> > > where it does succeed, Bob will have to offer a very large bribe to
> > > compensate "rational" miners for their high chance of losing out on
> > > gaining any transaction fees).
> > >
> > > Additionally, I think there's the problem of measuring the distribution
> > > of "myopic" hashrate versus "rational" hashrate. "Rational" miners need
> > > to do this in order to ensure they only accept Bob's timelocked bribe if
> > > it pays a sufficiently high fee. However, different miners who try to
> > > track what bribes were relayed versus what transactions got mined may
> > > come to different conclusions about the relative hashrate of "myopic"
> > > miners, leading some of them to require higher bribes, which may lead
> > > those those who estimated a lower relative hash rate to assume the rate
> > > of "myopic" mining in increasing, producing a feedback loop that makes
> > > other miners think the rate of "myopic" miners is increasi

Re: [bitcoin-dev] Is Bitcoin mempool synchronized?

2020-06-30 Thread ZmnSCPxj via bitcoin-dev
Good morning Hilda,

> Hi there,
>
> I have been assuming Bitcoin system to be well synchronized, including 
> mempools. But after being challenged, I started to think that I actually 
> cannot verify this without knocking the door of every miner in every single 
> second (just a time slice reasonable to me; stop torturing me by asking why). 
> Can anyone share any thoughts with me?


No, definitely not.

There is no good way to limit the amount of transactions someone can push at 
you, except by various heuristics.
Yet those very same heuristics mean that someone with a good knowledge of those 
heuristics can make your mempool desynchronized with that of somebody else.

Fortunately for Bitcoin, it is the blockchain itself that we synchronize on.
People cannot push blocks at you without doing the work of grinding towards the 
difficulty target, thus it is not possible to spam blocks.

TANSTAAGM - There Ain't No Such Thing As A Global Mempool

For this reason, any consensus rule has to refer only to data inside blocks, 
and never to data in mempools, are mempools are ephemeral and not synchronized 
across all nodes.

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


Re: [bitcoin-dev] MAD-HTLC

2020-06-29 Thread ZmnSCPxj via bitcoin-dev
Good morning Dave, et al.,


> >  Myopic Miners: This bribery attack relies on all miners
> >
> >
> > being rational, hence considering their utility at game conclu-
> > sion instead of myopically optimizing for the next block. If
> > a portion of the miners are myopic and any of them gets to
> > create a block during the first T − 1 rounds, that miner would
> > include Alice’s transaction and Bob’s bribery attempt would
> > have failed.
> > In such scenarios the attack succeeds only with a certain
> > probability – only if a myopic miner does not create a block
> > in the first T − 1 rounds. The success probability therefore
> > decreases exponentially in T . Hence, to incentivize miners
> > to support the attack, Bob has to increase his offered bribe
> > exponentially in T .
>
> This is a good abstract description, but I think it might be useful for
> readers of this list who are wondering about the impact of this attack
> to put it in concrete terms. I'm bad at statistics, but I think the
> probability of bribery failing (even if Bob offers a bribe with an
> appropriately high feerate) is 1-exp(-b*h) where `b` is the number of
> blocks until timeout and `h` is a percentage of the hashrate controlled
> by so-called myopic miners. Given that, here's a table of attack
> failure probabilities:
>
> "Myopic" hashrate
> B 1% 10% 33% 50%
> l +-
> o 6 | 5.82% 45.12% 86.19% 95.02%
> c 36 | 30.23% 97.27% 100.00% 100.00%
> k 144 | 76.31% 100.00% 100.00% 100.00%
> s 288 | 94.39% 100.00% 100.00% 100.00%
>
> So, if I understand correctly, even a small amount of "myopic" hashrate
> and long timeouts---or modest amounts of hashrate and short
> timeouts---makes this attack unlikely to succeed (and, even in the cases
> where it does succeed, Bob will have to offer a very large bribe to
> compensate "rational" miners for their high chance of losing out on
> gaining any transaction fees).
>
> Additionally, I think there's the problem of measuring the distribution
> of "myopic" hashrate versus "rational" hashrate. "Rational" miners need
> to do this in order to ensure they only accept Bob's timelocked bribe if
> it pays a sufficiently high fee. However, different miners who try to
> track what bribes were relayed versus what transactions got mined may
> come to different conclusions about the relative hashrate of "myopic"
> miners, leading some of them to require higher bribes, which may lead
> those those who estimated a lower relative hash rate to assume the rate
> of "myopic" mining in increasing, producing a feedback loop that makes
> other miners think the rate of "myopic" miners is increasing. (And that
> assumes none of the miners is deliberately juking the stats to mislead
> its competitors into leaving money on the table.)

A thought occurs to me, that we should not be so hasty to call non-myopic 
strategy "rational".
Let us consider instead "myopic" and "non-myopic" strategies in a population of 
miners.

I contend that in a mixed population of "myopic" and "non-myopic" miners, the 
myopic strategy is dominant in the game-theoretic sense, i.e. it might earn 
less if all miners were myopic, but if most miners were non-myopic and a small 
sub-population were myopic and there was no easy way for non-myopic miners to 
punish myopic miners, then the myopic miners will end up earning more (at the 
expense of the non-myopic miners) and dominate over non-myopic miners.
Such dominant result should prevent non-myopic miners from arising in the first 
place.

The dominance results from the fact that by accepting the Alice transaction, 
myopic miners are effectively deducting the fees earned by non-myopic miners by 
preventing the Bob transaction from being confirmable.
On the other hand, even if the non-myopic miners successfully defer the Alice 
transaction, the myopic miner still has a chance equal to its hashrate of 
getting the Bob transaction and its attached fee.
Thus, myopic miners impose costs on their non-myopic competitors that 
non-myopic miners cannot impose their myopic competitors.
If even one myopic miner successfully gets the Alice transaction confirmed, all 
the non-myopic miners lose out on the Bob bribe fee.

So I think the myopic strategy will be dominant and non-myopic miners will not 
arise in the first place.


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


Re: [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn

2020-06-25 Thread ZmnSCPxj via bitcoin-dev
Good morning CS,

The difficulty is not so much the proof-of-whatever, but rather, the peg itself.
My understanding of your pegout from sidechain to mainchain is that this pegout 
is very low-bandwidth, i.e. only a tiny amount can be pegged out at each 
mainchain block.
This suggests to me that the sidecoin can still drop lower than maincoin during 
times when overall side-to-main flows are higher than main-to-side flows.
(atomic swaps cannot *maintain* a peg, they can only follow a peg if it exists; 
if the peg is weak, atomic swaps cannot strengthen it.
this is because atomic swaps allow a non-1:1 exchange rate, as in 
cross-currency atomic swaps.)


In any case, from my reading of your text, I seem, the goal is scaling 
("acceptable option for lower value tx").
I studied sidechains some years ago, and, came to the conclusion that 
sidechains are not good for scaling.
We already know that blockchains do not scale well (excessive bandwidth use, 
permanent records needed to support newcomers); thus, the scaling solution for 
cryptocurrency cannot be via **more** blockchains.
Hence, Lightning Network.

In Lightning Network, every channel is a consensus system between two 
participants, hence every channel is a 2-of-2 (i.e. requires consensus of both 
participants to advance).
We use atomic swaps to transfer between channels and the blockchain.
The channel construction requires reference to an ultimate arbiter of any 
dispute/non-consensus between the channel participants; this is provided by the 
blockchain layer off which the channel is based.

Thus blockchain for arbitration, channels for scaling.


Regards,
ZmnSCPxj


> Hi everyone,
>
> I am hoping to get a critique on a proposal of how to construct childchains 
> "on-top" of Bitcoin without requiring any changes to Bitcoin itself nor 
> requiring any user or miner to be aware of them.
>
> The childchain is Bitcoin-aware and simulates the properties of Proof of Work 
> by requiring continuous burning of Bitcoin in return for the fees on the 
> childchain.
>
> The childchain tip is selected by highest total accumulated Bitcoin burnt 
> (with goal to simulate total accumulated work) for that full chained set of 
> childchain block commits.
>
> The only asset on the childchain is a 2-way-peg coin that's secured in value 
> without oracles or collateral by requiring that each valid child chain block 
> must not only burn Bitcoin, but must always use a small % of the burnt amount 
> to deterministically reimburse withdrawals from the childchain.
>
> Childchain -> mainchain :: user burns the child-BTC and is added to 
> withdrawal queue filled as part of validity requirements by childchain 
> "miners" until filled 1:1 on mainchain or more. Note that occasionally 
> overpaying a widthdrawal does not break 1:1 peg as there's no fixed size 1:1 
> pool of coins necessary.
>
> mainchain -> childchain :: user burns BTC (independent of mining childchain) 
> and is issued equivalent 1:1 child-BTC on the childchain
>
> While childchains are less secure than the mainchain, both the childchain 
> security and the 2-way-peg accuracy might be an acceptable option for lower 
> value tx on scale determined by the burning rate. 
>
> Childchains would replace the need for any additional Proof of Work chains 
> for new blockchains to introduce any complexity (e.g. mimblewimble 
> childchain).
>
> They would effectively use Proof of Work done on Bitcoin as proxy for 
> unforgeable costliness and benefit from Bitcoin's censorship resistance and 
> data availability. Large numbers of low value tx that might be priced out of 
> using the main chain could possibly in bulk provide enough childchain fees 
> combined through childchain miners to afford much higher mainchain fees like 
> "batching for fees".
>
> It also has the "benefits" claimed by proof of stake like no energy 
> consumption without relying on internal permissions or tokens, trusted 
> distributions, or centralizing mechanisms like staking by simulating proof of 
> work. It should allow both growing the Bitcoin ecosystem and replace the need 
> to create alternative cryptocurrencies just to make a new blockchain.
>
> More detailed write up available here: 
> https://bitcointalk.org/index.php?topic=5214173.0  
>
> I am hoping for a review if there's an overlooked issue or maybe interest to 
> create a proof of concept.
>
> Thank you
> -CS


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


Re: [bitcoin-dev] MAD-HTLC

2020-06-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Nadav,

> > I and some number of Lightning devs consider this to be sufficient 
> > disincentive to Bob not attacking in the first place.
>
> An additional disincentive could be introduced in the form of bribery proofs 
> for failed attempts.
>
> If we assume that "honest" users of the LN protocol won't reveal their 
> timelocked transactions before reaching the timelock expiry (they shouldn't 
> anyway because standard full node implementations won't relay them), we can 
> prove that Bob attempted bribery and failed to an outside observer by showing 
> Bob's signed timelocked transaction, spending an output that was in reality 
> spent by a different transaction prior to the locktime expiry, which should 
> not be possible if Bob had waited.


Unfortunately this could be subject to an inversion of this attack.

Alice can wait for the timelock to expire, then bribe miners to prevent 
confirmation of the Bob timelocked transaction, getting the Alice hashlocked 
transaction confirmed.

Now of course you do mention "prior to the locktime expiry" but there is now 
risk at around locktime.

Particularly, "natural" orphaned blocks and short-term chainsplits can exist.
Bob might see that the locktime has arrived and broadcast the signed timelocked 
transaction, then Alice sees the locktime has not yet arrived (due to 
short-term chainsplits/propagation delays) and broadcast the signed hashlocked 
transaction, then in the end the Alice side of the short-term chainsplit is 
what solidifies into reality due to random chance on which miner wins which 
block.
Then Bob can now be accused of bribery, even though it acted innocently; it 
broadcasted the timelock branch due to a natural chainsplit but Alice 
hashlocked branch got confirmed.

Additional complications can be added on top to help mitigate this edge case 
but more complex == worse in general.
For example it could "prior to locktime expiry" can ignore a few blocks before 
the actual timelock, but this might allow Bob to mount the attack by initiating 
its bribery behavior earlier by those few blocks.

Finally, serious attackers would just use new pseudonyms, the important thing 
is to make pseudonyms valuable and costly to lose, so it is considered 
sufficient that LN nodes need to have some commitment to the LN in the form of 
actual channels (which are valuable, potentially money-earning constructs, and 
costly to set up).

Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris 
Belcher, could use similar disincentivizing; I know Chris is planning a 
fidelity bond system for SwapMarket makers, for example, which would mimic the 
properties of LN channels (costly to set up, money-earning).

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


Re: [bitcoin-dev] MAD-HTLC

2020-06-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Stanga et al,


> > Hi ZmnSCPxj, 
> >
> > Thank you for taking the time to respond, these are very good points. 
> > Responses inline.
> >
> > On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj  wrote:
> >
> > > Good morning Itay, Ittay, and Matan,
> > >
> > > I believe an unstated assumption in Bitcoin is that miners are 
> > > short-sighted.
> > >
> > > The reasoning for this assumption is:
> > >
> > > * Deployment of new mining hardware controlled by others may occur at any 
> > > time you do not control.
> > >   * Thus, any transactions you leave on the table are potentially taken 
> > > by somebody else and not by you.
> > >   * Sudden changes in hashpower distribution may reduce your expected 
> > > future earnings, so any future theoretical earnings should be discounted 
> > > (*in addition to* expected return-on-investment on getting money you can 
> > > invest *now*).
> >
> > Our analysis assumes constant difficulty, i.e., no significant changes of 
> > the miners set. Indeed, hash-rate changes typically occur at a much larger 
> > granularity than your average HTLC timeout. For instance, we noticed plenty 
> > of lightning nodes use timeouts of a day. So, we do not consider 
> > optimization at infinity, just a day ahead, and within this time frame all 
> > the factors you mentioned are not expected to dramatically change. 
> >
> > That being said, it would be interesting to analyze the effect of miners 
> > joining during the HTLC duration. Intuitively, this shouldn’t affect the 
> > results, as those new miners have the same incentive to wait for the 
> > higher-paying tx.

We already know that hashrate tends to trend upwards, and that we do not expect 
hashrate to fall except for occasional transients.

The expectation is not that new miners have different incentives.
Instead, the expectation is that current miners discount future possible gains 
because in the future, they expect to have less hashrate share than right now.

The only trustless way for Bob to bribe miners into deferring Alice tx is to 
attach the bribe to the future confirmation of the Bob tx, thus Bob is offering 
future-coins, not present-coins like Alice can offer, and the fact that miners 
expect an overall uptrend in total hashrate (leading to an overall downtrend in 
their hashrate share) means that miners discount the Bob offered future-coins.
The discounting is proportional to the time delay involved, as a larger delay 
implies greater reduction in hashrate share.

This discounting is, again, *in addition to* natural discounting a.k.a. "I will 
gladly pay you Thursday for a hamburger today", the hamburger seller will want 
some pretty stiff assurances plus a bigger payment on Thursday for giving you a 
hamburger today, due to expected returns on investment.


> >  
> >
> > > It also strikes me that, in a world with RBF and CPFP, the same endpoint 
> > > (i.e. miners earn the entire fund of the HTLC) is achieved by existing 
> > > HTLCs, without the additional branch and script opcodes needed by 
> > > MAD-HTLC.
> > > For example, if an HTLC is confirmed but the hashlock-claiming 
> > > transaction is not being confirmed (because miners are holding it up 
> > > because Bob is offering a much higher fee in the future for the 
> > > timelock-claiming transaction), then Alice can, regardless of the reason 
> > > why it is not being confirmed, bump up the fee with RBF or CPFP.
> > >
> > > If the fee bump offered by Alice is sufficiently large, then miners will 
> > > start re-preferring the Alice hashlock transaction.
> > > To counter this, Bob has to bid up its version higher.
> > >
> > > As the timeout approaches, Alice can bump up its fee until it is just 1 
> > > satoshi short of the total fund.
> > > It is rational for Alice to do so since at timeout, it can expect to lose 
> > > the entire fund.
> > > In order for Bob to win, it has to beat that fee, at which point it 
> > > equals or exceeds the total fund, and miners get the total fund (or more).
> > >
> > > Knowing this end-point, rational Bob will not even begin this game.
> > >
> > > I think this research considers these two endpoints to be distinct:
> > >
> > > * Bob misbehaves and the entire fund is punished by miners, leaving 
> > > miners with the fund and Alice and Bob without money (MAD-HTLC).
> > > * Bob misbehaves, Alice counters, and the ensuing fee war leads to fees 
> > > approaching the fund value, leaving miners with the fund and Alice and 
> > > Bob without money (standard HTLC).
> > >
> > > But in practice I think both endpoints are essentially equivalent.
> >
> > These are not the same scenario, since in HTLC there is a race between 
> > Alice and Bob. Alice might not wish to pay the full HTLC amount once she 
> > sees Bob is trying to cheat. She could wait until close to the timeout so 
> > as to reduce the time Bob can respond. Of course Bob would do the same. So 
> > this is an actual race, and Bob takes no risk since his payment is all 

Re: [bitcoin-dev] MAD-HTLC

2020-06-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Itay, Ittay, and Matan,

I believe an unstated assumption in Bitcoin is that miners are short-sighted.

The reasoning for this assumption is:

* Deployment of new mining hardware controlled by others may occur at any time 
you do not control.
  * Thus, any transactions you leave on the table are potentially taken by 
somebody else and not by you.
  * Sudden changes in hashpower distribution may reduce your expected future 
earnings, so any future theoretical earnings should be discounted (*in addition 
to* expected return-on-investment on getting money you can invest *now*).

It also strikes me that, in a world with RBF and CPFP, the same endpoint (i.e. 
miners earn the entire fund of the HTLC) is achieved by existing HTLCs, without 
the additional branch and script opcodes needed by MAD-HTLC.
For example, if an HTLC is confirmed but the hashlock-claiming transaction is 
not being confirmed (because miners are holding it up because Bob is offering a 
much higher fee in the future for the timelock-claiming transaction), then 
Alice can, regardless of the reason why it is not being confirmed, bump up the 
fee with RBF or CPFP.

If the fee bump offered by Alice is sufficiently large, then miners will start 
re-preferring the Alice hashlock transaction.
To counter this, Bob has to bid up its version higher.

As the timeout approaches, Alice can bump up its fee until it is just 1 satoshi 
short of the total fund.
It is rational for Alice to do so since at timeout, it can expect to lose the 
entire fund.
In order for Bob to win, it has to beat that fee, at which point it equals or 
exceeds the total fund, and miners get the total fund (or more).

Knowing this end-point, rational Bob will not even begin this game.

I think this research considers these two endpoints to be distinct:

* Bob misbehaves and the entire fund is punished by miners, leaving miners with 
the fund and Alice and Bob without money (MAD-HTLC).
* Bob misbehaves, Alice counters, and the ensuing fee war leads to fees 
approaching the fund value, leaving miners with the fund and Alice and Bob 
without money (standard HTLC).

But in practice I think both endpoints are essentially equivalent.

--

What MAD-HTLC can do would be to make different claims:

* Inputs:
  * Bob 1 BTC - HTLC amount
  * Bob 1 BTC - Bob fidelity bond

* Cases:
  * Alice reveals hashlock at any time:
* 1 BTC goes to Alice
* 1 BTC goes to Bob (fidelity bond refund)
  * Bob reveals bob-hashlock after time L:
* 2 BTC goes to Bob (HTLC refund + fidelity bond refund)
  * Bob cheated, anybody reveals both hashlock and bob-hashlock:
* 2 BTC goes to miner

This is an actual improvement over HTLC: Bob misbehavior leads to loss of the 
fidelity bond.
The above cases can be assured by requiring both Alice and Bob to sign in the 
alice-hashlock branch, so that the splitting of the fund is enforced, and 
SegWit signing so that the dependent transaction is signed before the 
HTLC-funding transaction is.
It can also be implemented with `OP_CHECKTEMPLATEVERIFY`.

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


Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-06-22 Thread ZmnSCPxj via bitcoin-dev
Good morning Bastien,

> Thanks for the detailed write-up on how it affects incentives and 
> centralization,
> these are good points. I need to spend more time thinking about them.
>
> > This is one reason I suggested using independent pay-to-preimage
> > transactions[1]
>
> While this works as a technical solution, I think it has some incentives 
> issues too.
> In this attack, I believe the miners that hide the preimage tx in their 
> mempool have
> to be accomplice with the attacker, otherwise they would share that tx with 
> some of
> their peers, and some non-miner nodes would get that preimage tx and be able 
> to
> gossip them off-chain (and even relay them to other mempools).

I believe this is technically possible with current mempool rules, without 
miners cooperating with the attacker.

Basically, the attacker releases two transactions with near-equal fees, so that 
neither can RBF the other.
It releases the preimage tx near miners, and the timelock tx near non-miners.

Nodes at the boundaries between those that receive the preimage tx and the 
timelock tx will receive both.
However, they will receive one or the other first.
Which one they receive first will be what they keep, and they will reject the 
other (and *not* propagate the other), because the difference in fees is not 
enough to get past the RBF rules (which requires not just a feerate increase, 
but also an increase in absolute fee, of at least the minimum relay feerate 
times transaction size).

Because they reject the other tx, they do not propagate the other tx, so the 
boundary between the two txes is inviolate, neither can get past that boundary, 
this occurs even if everyone is running 100% unmodified Bitcoin Core code.

I am not a mempool expert and my understanding may be incorrect.

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


Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-06-20 Thread ZmnSCPxj via bitcoin-dev
Good morning again,

> Good morning Dave,
>
> > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> > hoping one of Bitcoin's several inventive cryptographers would come
> > along and describe how someone with an adaptor signature could use that
> > information to create a pubkey that could be put into a transaction with
> > a second output that OP_RETURN included the serialized adaptor
> > signature. The pubkey would be designed to be spendable by anyone with
> > the final signature in a way that revealed the hidden value to the
> > pubkey's creator, allowing them to resolve the PTLC. But if that's
> > fundamentally not possible, I think we could advocate for making
> > pay-to-revealed-adaptor-signature possible using something like
> > OP_CHECKSIGFROMSTACK.[3]
>
> 
>
> The signed message could be a signature to `SIGHASH_NONE`, finally an actual 
> use for that flag.

If you are going to embed it in an `OP_RETURN` in the same transaction, you 
also need `SIGHASH_ANYPREVOUT`, otherwise you cannot embed the adaptor 
signature for spending from that transaction in the transaction being spent, it 
also implies `A[p4s] = a[p4s] * G` is a one-time-use keypair.

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


Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-06-20 Thread ZmnSCPxj via bitcoin-dev
Good morning Dave,

> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was
> hoping one of Bitcoin's several inventive cryptographers would come
> along and describe how someone with an adaptor signature could use that
> information to create a pubkey that could be put into a transaction with
> a second output that OP_RETURN included the serialized adaptor
> signature. The pubkey would be designed to be spendable by anyone with
> the final signature in a way that revealed the hidden value to the
> pubkey's creator, allowing them to resolve the PTLC. But if that's
> fundamentally not possible, I think we could advocate for making
> pay-to-revealed-adaptor-signature possible using something like
> OP_CHECKSIGFROMSTACK.[3]


Not a cryptographer, I just play one on the Internet, but maybe the 
pay-for-signature construction could work...?

Assuming a PTLC has a pointlocked branch, which involves signing with MuSig(A, 
B).
A offers to B the amount if B reveals the secret `t` behind `T = t * G`; A 
knows `T` but not `t`.
This is done by B handing over `R[B]` and `s'[B]`:

R = R[A] + R[B] + T
s'[B] = r[B] + h(MuSig(A, B) | R | m) * b

Then A provides its partial signature to B.

s[A] = r[A] + h(MuSig(A, B) | R | m) * a

B has to complete the signature by:

s = s[A] + s'[B] + t

Since A knows both `s[A]` and `s'[B]`, once it knows `s`, it can compute `t`.


Now, we can massage the equation for `s`:

s = r[A] + h(MuSig(A, B) | R | m) * a + r[B] + h(MuSig(A, B) | R | m) * b + 
t
; multiply both sides by G
s * G = r[A] * G + h(MuSig(A, B) | R | m) * a * G + r[B] * G + h(MuSig(A, 
B) | R | m) * b * G + t * G
; replace with public points
s * G = R[A] + h(MuSig(A, B) | R | m) * A + R[B] + h(MuSig(A, B) | R | m) * 
B + T

Note that A can compute `s * G` above, because it generated `R[A]`, was given 
`R[B]` and `T`, and knows who `A` and `B` are.

So what A needs to do is to offer a fund that can only be claimed by leaking 
knowledge of `s` behind `s * G`.
A can do this by creating a new keypair `A[p4s] = a[p4s] * G` and putting a 
fund into it.

Then A generates an `R[A][p4s] = r[A][p4s] * G`, and computes:

R[p4s] = R[A][p4s] + s * G
s'[A][p4s] = r[A][p4s] + h(A | R[p4s] | m) * a[p4s]

The signed message could be a signature to `SIGHASH_NONE`, finally an actual 
use for that flag.

A reveals publicly (in an `OP_RETURN` as you suggest):

* `R[A][p4s]`
* `s * G`
* `s'[A][p4s]`
* `A[p4s]` - Already the Schnorr output pubkey.

In order to complete the above signature, a third party C has to learn `s` from 
B.

The third party has to scan every onchain 1-of-1 signature for an `s` that 
matches `s * G`, so there is greater processing (point multiplies are more 
expensive than hashes, also there are more 1-of-1s).
But once learned, the third party can complete the signature and claim the 
funds.
And A then learns `s`, from which it can derive `t`.

The third party learns about which channel (i.e. the UTXO that was spent to 
create the PTLC in the first place), but never learns `t` or `T`, which is a 
small but nice privacy bonus.


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


Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-15 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine, Gleb, and list,

In some ways, CoinPool is really part of a swarm of ideas:

* CoinPool
* Multiparticipant (N > 2) channels
* Channel factories
* Nodelets

What CoinPool and multiparticipant channels buy us is better flexibility with 
forwarding.
For example, if we compare a multiparty channel to a channel factory, suppose 
there exists three entities A, B, and C in the multiparty construction.

In a channel factory, each entity has to decide how much of its liquidity to 
tie up in a channel with a specific other peer in the multiparty construction.
This limits the practical payment forwarding when integrated into the Lightning 
Network.

In a CoinPool, any of the entities can forward to any of the other entities, 
without tying their liquidity to a channel specifically with those entities.

However, in a CoinPool, once any of the entities goes offline, the entire 
CoinPool can no longer update.
This is in contrast with channel factories, where, if entity C goes offline, 
the channel between A and B remains useable for forwarding.
In other words, channel factories degrade gracefully.

Further, we already have a decent solution for liquidity redistribution: JIT 
Routing by Rene Pickhardt.
Thus the liquidity issue with channel factories are somewhat mitigated (and if 
all participants are online, they also have the option of redistributing 
channel funds *inside* the factory as well, not just JIT routing), while 
gaining graceful degradation of the factory.


Another is that pathfinding algorithms work best if graph edges are edges and 
not in fact some kind of twisted multi-edge that connects more than two nodes 
together.

On the other hand, the participants of a CoinPool could create a "virtual node" 
that is a MuSig of their individual keys, and report that as the "real" node on 
LN gossip (each of them pretending to have a large channel with that virtual 
node), so that the rest of the network only sees edges that link two nodes (and 
existing pathfinding algos still work seamlessly, never realizing that this 
node is actually a virtual node that represents a CoinPool).
This is basically them creating a sort of Nodelet node, which other nodes 
cannot make channels to, and which uses channels with the Nodelet node as 
proxies for the CoinPool as a whole.


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


Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-06-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

>
> Would it be fair to summarize the idea in this way:
>
> CoinSwappers can slow down the CoinSwap process which will give an
> opportunity for makers to use batching.

I think so.

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


Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine,

By dropping the requirement that a participant can seamlessly leave the 
CoinPool, it allows participants to split up their coins among new aliases and 
to use a different identity for later claiming coins.
With WabiSabi, none of the other participants can get a mapping between 
current-state aliases and the actual participants.

Now, in order to authorize moving coins from an output on the current state to 
a new output on the next state, obviously the pool needs to get a signature 
from its current owner.
Ideally, we would not want to have to implement SCRIPT inside the CoinPool 
software.

And with Taproot, a pubkey can hide one or more SCRIPTs.
If we use pubkeys as the identities of owners of coins, then it allows an alias 
to encode a SCRIPT.

With the combination of both features, we can instantiate HTLCs (or, with 
`SIGHASH_ANYPREVOUT`, PTLCs) inside a CoinPool "alias" pubkey identity, 
allowing for interoperation with LN.

Now suppose I have 1.0 BTC in a CoinPool.
I want to make an HTLC with you (hashlocked to you, timelocked to me), for 0.5 
BTC.

I encode the HTLC SCRIPT, and put it into a Taproot whose internal pubkey is a 
MuSig of fresh identities of mine and yours.

Then, inside the CoinPool, I split my 1.0BTC to a 0.5BTC coin to a fresh 
identity of mine, and 0.5BTC to our HTLC Taproot.

If you can acquire the hash, you give it to me, and I am supposed to hand you a 
partial signature share to the HTLC Taproot that you can later complete and 
present to the CoinPool in the next update round in order to get the HTLC value.
If I do not hand you the signature share even after you hand the hash, you just 
drop the entire CoinPool onchain, instantiating the HTLC Taproot output 
onchain, and using the SCRIPT branch to claim using the hash you know.

If the timelock expires, I ask you to hand over your partial signature to the 
HTLC Taproot that I can later complete and present to the CoinPool in the next 
update round to recover the HTLC value.
If you do not hand over the signature share, I drop the CoinPool onchain, which 
instantiates the HTLC Taproot output onchain, and use the SCRIPT branch to 
claim using the timelock branch.

You can also ask to abort the HTLC "early", before the timelock expires, by 
handing over your partial signature to the HTLC Taproot, which I can later 
complete and present to the CoinPool in the next update round.
This is equivalent to `update_fail_htlc` in the current LN BOLT spec.

This allows operation of any SCRIPT, incidentally, without requiring that 
CoinPool software include a SCRIPT interpreter, only signature validation.
Any time an output absolutely needs a SCRIPT, we just drop the CoinPool onchain 
and let onchain handle the SCRIPT interpretation.

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine,


> Yes, that's part of future research, defining better *in-pool* observer. 
> Sadly, right now, even if you use mask construction inside, it's quite easy 
> to trace leaves by value weight. Of course, you can enforce equal-value 
> leaves, as for a regular onchain CoinJoin. I think it comes with a higher 
> onchain cost in case of pool breakage.


Perhaps not necessarily.

An advantage of WabiSabi is I can pretend to be two or more participants.

For example, I can pretend to be "Alice" and "Bob", and pretend that "Alice" 
owes a life debt to "Bob".

At initial state setup, I put a 1.0 BTC coin as "Alice" and a 0.5 BTC coin as 
"Bob".

Now, at each state update I need to sign as "Alice" and "Bob".
However, after the first initial state, I can use a new persona "Bobby" to 
*own* my coins, even though I still have to sign as "Alice" and "Bob" in every 
state update.

What the other pool participants see is that the 1.0 BTC "Alice" coin and the 
0.5 BTC "Bob" coin are merged into the 1.5 BTC "Bobby" coin.
What they cannot be sure of is:

* "Alice" paid to "Bob", who is now pretending to be "Bobby".
* "Bob" paid to "Alice", who is now pretending to be "Bobby".
* "Alice" and "Bob" are the same person, and is also pretending to be "Bobby".

All the other participants know is that whoever owns the coin *now* is still 
part of the pool, but cannot be sure which participant *really* owns which 
coin, and whether participants are sockpuppets (which is why it should use 
n-of-n at each state update, incidentally).

In effect, it "imports" the possibility of PayJoin inside the CoinPool 
construction.



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


Re: [bitcoin-dev] WabiSabi Inside Batched CoinSwap

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning list,

> -   Alice (resp. Bob or Carol) creates (but does not sign) a funding 
> transaction from Alice coins to MuSig(Alice, Macky).
> -   Alice and Macky create a backout transaction, with `nLockTime` at L2, and 
> complete the plain MuSig signing ritual.
> -   Alice broadcasts the original funding transaction.

Sorry, the taker funding transactions should have the nearer locktime L1, and 
the maker funding transctions should be the one with the later locktime L2.
This forces Macky to claim the incoming funds earlier, and claiming any of them 
unlocks the outgoing payout transaction.


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


Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine and Gleb,

I have not studied the proposal in close detail yet, but anyway, my main 
takeaway roughly is:

* The core of CoinPool is some kind of multiparticipant (N > 2) offchain update 
mechanism (Decker-Wattenhofer or Decker-Russell-Osuntokun).
  * The output at each state of the update mechanism is some kind of splitting 
construction (which I have not studied in detail).
  * At each update of the state, all participants must sign off on the new 
state.

It seems to me that it would be possible to use a [WabiSabi 
protocol](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017969.html)
 during negotiation of a new state.

Now, WabiSabi is a client-server protocol.
As all participants in the CoinPool are needed in order to ratify each new 
state anyway, they can simply elect one of their number by drawing lots, to act 
as server for a particular state update.

Then the participants can operate as WabiSabi clients.
Each participant registers the outputs they currently own in the current state, 
getting credentials that sum up to the correct value.
Then, during the WabiSabi run, they can exchange credentials among the 
participants in order to perform value transfers inside the WabiSabi 
construction.
Then, at output registration, they register new outputs to put in the next 
state of the CoinPool.

In order to hide transfers from the elected WabiSabi server, participants can 
maintain two coins in every state, and move coins randomly across the two coins 
they own at each state update, in order to hide "real" transfers from the 
elected server.

Then, after output registration, the participants ratify the new state by 
signing off on the new state and revoking the previous state, using the update 
mechanism.

Of course, we should note that one desired feature for CoinPool in the original 
proposal is that a participant can exit, and the CoinPool would still remain 
valid, but only for the remaining participants.

This is arguably a mild privacy leak: every other participant now knows how 
much that particular participant took out from the CoinPool.
Indeed, from what I can understand, in order to properly set up the splitting 
transactions in the first place, at each state every participant needs to know 
how much each other participant actually owns in the CoinPool at that point in 
time.

To hide how much each participant owns in the CoinPool from other participants, 
we would have to make unilateral closes expose all the current outputs, without 
trying to identify *which* participant exited the CoinPool, and thus preventing 
anyone else from figuring out exactly how much each *other* participant 
actually owns in the CoinPool on exit.
That way, output addresses can be to fresh pseudonyms of the participant, 
removing all linkages of participant to amount they own, and each participant 
can maintain multiple outputs per state for their own purposes and to mildly 
obscure exactly how much they own in total.

If we drop that feature (of being able to exit a participant without closing 
the *entire* CoinPool), of course, we need to mildly disincentivize a 
participant closing unilaterally for trivial reasons.
We can do this by using `SIGHASH_ANYPREVOUT` to force whoever performs a 
unilateral close of the CoinPool to pay the onchain fees involved, so that it 
would have to be a good reason indeed to perform a unilateral close.


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


[bitcoin-dev] WabiSabi Inside Batched CoinSwap

2020-06-11 Thread ZmnSCPxj via bitcoin-dev
Introduction


THIS ENTIRE PROTOCOL IS NOVEL CRYPTO AND HAS NO PROOF THAT IT IS SECURE AND 
PRIVATE AND WHY WOULD YOU TRUST SOME RANDOM PSEUDONYM ON THE INTERNET SRSLY.

While 
[WabiSabi](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017969.html)
 is planned for some kind of CoinJoin operation, a limitation is that the use 
of CoinJoin creates a transaction where the inputs are known to be linked to 
the outputs, as the generated transaction directly consumes the inputs.

It would be better if the server in the WabiSabi created outputs from 
independent outputs it owns, acquired from previous clients.
Then the outputs would, onchain, be linked to previous clients of the server 
instead of the current clients.
This is precisely the issue that CoinSwap, and the new swap scheme [Succinct 
Atomic 
Swaps](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html),
 can be used to solve.
By using [Batched 
CoinSwap](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017967.html),
 makers can act as WabiSabi servers, and batched takers can act as WabiSabi 
clients.

Of course, WabiSabi has the advantage that payments between the clients are 
obscured from the server.
But a naive CoinSwap requires that outputs from the maker be linkable, at least 
by the maker, to inputs given to the maker, which is precisely the information 
that WabiSabi seeks to hide from the server.

However, by instead using [Signature 
Selling](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002077.html)
 in combination with standard Scriptless Script adaptor signatures, it is 
possible to arrange for a CoinSwap to occur without the make being able to link 
outputs to inputs.

Signature Selling
=

The final output of the Schnorr signing process is a pair (R, s) for a pubkey A 
= a * G and ephemeral nonce R = r * G, where:

s = r + h(P | R | m) * a

Now, instead of the pair (R, s), the signer can provide (R, s * G).
The receiver of (R, s * G) can validate that s * G is correct using the same 
validation as for Schnorr signatures.

s * G = R + h(P | R | m) * A

The receiver of (R, s * G) can then offer a standard Scriptless Script adaptor 
signature, which when completed, lets them learn s.
The receiver may incentivize this by having the completed signature authorize a 
transaction to the sender of the original (R, s * G), so that the completed 
signature atomically gives the receiver the correct signature.

This can be used as a basis for atomic CoinSwap, and which we will use in this 
proposal.

Note that even in a MuSig case, it is possible for a participant to sell its 
share of the final signature, after the R exchange phase in MuSig.

WabiSabi


WabiSabi replaces blind signatures with credentials.
The primary advantage of credentials is that credentials can include a 
homomorphic value.
We use this homomorphic value to represent a blinded amount.

WabiSabi has a single server that issues credentials, and multiple clients that 
the server serves.
Clients can exchange value by swapping credentials, then claiming credentials 
they received from the server and exchanging them for fresh credentials.
Clients hold multiple credentials at a time, and the server consumes (and 
destroys) a set of credentials and outputs another set of fresh credentials, 
ensuring that the output value is the same as the input value (minus any fees 
the server wants to charge for the operation).

>From a high enough vantage point, the WabiSabi process is:

1.  Server issues 0-valued credentials to all clients.
2.  Clients put in money into the server by providing onchain inputs to the 
server plus their existing credentials, getting credentials with their input 
credential value plus the onchain input value.
3.  Clients swap credentials with each other to perform payments between 
themselves, then claim the credentials by asking the server to reissue them.
* Receiving clients move their amounts among all the credentials they own 
(via server consume-reissue credential operations) so as to make one of their 
multiple credentials into a 0-value credential.
* Sending clients move their amounts among all the credentials they own so 
that one of their multiple credentials has the sent value.
* The receiving client exchanges its 0-value credential for the sent-value 
credential from the sending client, by cooperatively making a consume-reissue 
operation with the server.
4.  Clients then claim the value in their credentials by providing pubkeys to 
pay to, and amount, to the server, plus existing credentials, getting back 
credentials whose total value is minus the onchain output value.
5.  The server generates the final output set.
6.  The clients check that the final output set is indeed what they expected 
(their claimed outputs exist) and ratify the overall transaction.
* In the CoinJoin case, the overall transaction is ratified by 

[bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-06-11 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris, and bitcoin-dev (but mostly Chris),


I made a random comment regarding taint on bitcoin-dev recently: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017961.html

> For CoinSwap as well, we can consider that a CoinSwap server could make 
> multiple CoinSwaps with various clients.
> This leads to the CoinSwap server owning many small UTXOs, which it at some 
> point aggregates into a large UTXO that it then uses to service more clients 
> (for example, it serves many small clients, then has to serve a single large 
> client that wants a single large UTXO for its own purposes).
> This aggregation again leads to spreading of taint.

I want to propose some particular behaviors a SwapMarket maker can engage in, 
to improve the privacy of its customers.

Let us suppose that individual swaps use some variant of Succinct Atomic Swap.
Takers take on the role of Alice in the SAS description, makers take on the 
role of Bob.
We may be able to tweak the SAS protocol or some of its parameters for our 
purposes.

Now, what we will do is to have the maker operate in rounds.

Suppose two takers, T1 and T2, contact the sole maker M in its first ever round.
T1 and T2 have some coins they want to swap.
They arrange things all the way to confirmation of the Alice-side funding tx, 
and pause just before Bob creates its own funding tx for their individual swaps.
The chain now shows these txes/UTXOs:

 42 of T1 --->  42 of T1 & M
 50 of T2 --->  50 of T2 & M
100 of T1 ---> 100 of T1 & M

200 of M  -

Now the entire point of operating in rounds is precisely so that M can service 
multiple clients at the same time with a single transaction, i.e. batching.
So now M provides its B-side tx and complete the SAS protocols with each of the 
takers.
SAS gives unilateral control of the outputs directly to the takers, so we elide 
the fact that they are really 2-of-2s below:

 42 of T1 --->  42 of T1 & M
 50 of T2 --->  50 of T2 & M
100 of T1 ---> 100 of T1 & M

200 of M  +-->  11 of M
  +--> 140 of T1
  +-->  49 of T2

(M extracted 1 unit from each incoming coin as fee; they also live in a 
fictional universe where miners mine transactions out of the goodness of their 
hearts.)
Now in fact the previous transactions are, after the SAS, solely owned by M the 
maker.
Now suppose on the next round, we have 3 new takers, T3, T4, and T5, who offer 
some coins to M to CoinSwap, leading to more blockchain data:

 42 of T1 --->  42 of T1 & M
 50 of T2 --->  50 of T2 & M
100 of T1 ---> 100 of T1 & M

200 of M  -+->  11 of M
   +-> 140 of T1
   +->  49 of T2

 22 of T3 --->  22 of T3 & M
 90 of T3 --->  90 of T3 & M
 11 of T4 --->  11 of T4 & M
 50 of T4 --->  50 of T4 & M
 20 of T5 --->  20 of T5 & M

In order to service all the new takers of this round, M takes the coins that it 
got from T1 and T2, and uses them to fund a new combined CoinSwap tx:

 42 of T1 --->  42 of T1 & M -+--+-> 110 of T3
 50 of T2 --->  50 of T2 & M -+  +->  59 of T4
100 of T1 ---> 100 of T1 & M -+  +->  14 of T5
 +->   9 of M
200 of M  -+->  11 of M
   +-> 140 of T1
   +->  49 of T2

 22 of T3 --->  22 of T3 & M
 90 of T3 --->  90 of T3 & M
 11 of T4 --->  11 of T4 & M
 50 of T4 --->  50 of T4 & M
 15 of T5 --->  15 of T5 & M

That transaction, we can observe, looks very much like a batched transaction 
that a custodial service might produce.

Now imagine more rounds, and I think you can begin to imagine that the magic of 
transaction batching, ported into SwapMarket, would help mitigate the 
blockchain size issues that CoinSwap has.

Makers are expected to adopt this technique as this reduces the overall cost of 
transactions they produce, thus they are incentivized to use this technique to 
increase their profitability.

At the same time, it spreads taint around and increases the effort that chain 
analysis must go through to identify what really happened.

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


Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine and Gleb,

One thing I have been idly thinking about would be to have a *separate* 
software daemon that performs de-eclipsing for your Bitcoin fullnode.

For example, you could run this deeclipser on the same hardware as your Bitcoin 
fullnode, and have the deeclipser bind to port 8334.
Then you set your Bitcoin fullnode with `addnode=localhost:8334` in your 
`bitcoind.conf`.

Your Bitcoin fullnode would then connect to the deeclipser using normal P2P 
protocol.

The deeclipser would periodically, every five minutes or so, check the latest 
headers known by your fullnode, via the P2P protocol connection your fullnode 
makes.
Then it would attempt to discover any blocks with greater blockheight.

The reason why we have a separate deeclipser process is so that the deeclipser 
can use a plugin system, and isolate the plugins from the main fullnode 
software.
For example, the deeclipser could query a number of plugins:

* One plugin could just try connecting to some random node, in the hopes of 
getting a new connection that is not eclipsed.
* Another plugin could try polling known blockchain explorers and using their 
APIs over HTTPS, possibly over Tor as well.
* Another plugin could try connecting to known Electrum servers.
* New plugins can be developed for new mitigations, such as sending headers 
over DNS or blocks over mesh or etc.

Then if any plugin discovers a block later than that known by your fullnode, 
the deeclipser can send an unsolicited `block` or `header` message to your 
fullnode to update it.

The advantage of using a plugin system is that it becomes easier to prototype, 
deploy, and maybe even test new de-eclipsing mitigations.

At the same time, by running a separate daemon from the fullnode, we provide 
some amount of process isolation in case some problem with the plugin system 
exists.
The deeclipser could be run by a completely different user, for example, and 
you might even run multiple deeclipser daemons in the same hardware, with 
different non-overlapping plugins, so that an exploit of one plugin will only 
bring down one deeclipser, with other deeclipser daemons remaining functional 
and still protecting your fullnode.

Finally, by using the P2P protocol, the fullnode you run could be a 
non-Bitcoin-Core fullnode, such as btcd or rust-bitcoin or whatever other 
fullnode implementations exist, assuming you actually want to use them for some 
reason.

What do you think?

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
Good morning nopara73 and Chris,


> One way to resist a likely taint analysis attack is to involve other
> parts of the bitcoin economy in your transactions. For example our
> exchange thief could deposit and then withdraw his stolen coins through
> a Bitcoin Casino or other bitcoin service hot wallet. His coins might no
> longer be 100% tainted from the exchange hack but perhaps have 5%
> exchange hack, 5% bitcoin ATM, 5% mined coins, etc etc. The numbers are
> made up and they depend on the exact algorithm but the main point is
> that involving the rest of the bitcoin economy in your transaction is
> one practical way to stop taint analysis being a useful attack against
> on you.
>
> Another important point is that taint isn't part of bitcoin's code
> anywhere. It is an external reality that surveillance companies impose
> on users. The only reason taint has any influence is because of
> censorship, for example an exchange which uses the services of a
> surveillance company has the power to freeze funds (i.e. censor a
> transaction) if they believe the user's deposit transaction is tainted.

Adding on to this, we can consider the *economics* of taint.

Tainted coins are less valuable than untainted coins.

However, as pointed out as well, taint is not a consensus among all Bitcoin 
users.
There are no cryptographic underpinnings that would allow all nodes to agree on 
their individual taint analysis.

The people knocking on doors often have limited amounts of reach: there are 
real economic barriers to the knock-on-doors people being shipped to the other 
side of the Earth (fuel costs, ammunition costs, sociopolitical knock-on 
effects).

Thus, suppose I am a miner with N coins.
As the coins have no history, they are "completely clean", as it were.

As a miner, I exist somewhere in the universe.
It is possible that I exist in some location on Earth (we cannot know; please 
ignore scurrilous slander that I am somehow existent outside of time and space).

Now suppose you have some tainted coins.
As noted, those coins are tainted only within some jurisdiction.
Outside that jurisdiction, however, they have no taint (taint is not a global 
consensus).

If I happen to live outside the jurisdiction where your coins are tainted, and 
I have some clean freshly-mined coins, I can offer this deal to you:

* Give me N+1 tainted coins for my N clean coins.

Now, again, the premise here is that there exists no global knock-on-doors 
people who can come to my datacenter and start asking questions to the sysads 
administering my computational substrate.

In that case, you might very well take the deal:

* You have not lost economic power, because the tainted coins, in your 
jurisdiction, are of lower value than N+1 anyway, and might even have value 
below that of N clean coins.
* I have gained economic power, because the tainted coins, in my jurisdiction, 
are not tainted and have the same cleanliness as my fresh mined coins.

This is a simple example of gains from trade, this time from jurisdictional 
arbitrage, thus such deals will exist.

--

But that is specious, as it assumes that there exists no global knock-on-doors 
people.
Obviously, there could exist one or more entities who are able to ship 
knocks-on-doors people all over the globe, taking advantage of economies of 
scale and reinvestment (more knock-on-doors people to knock on doors of people 
they can extract more economic power from to hire more knock-on-doors people) 
to achieve practically global coverage.

Against this, we must remember that ultimately censorship resistance of the 
coin is what can protect against such an attacker, which can impose its own 
non-consensual-but-pretty-damn-important view of taint practically globally.

Censorship resistance requires that owners of coins have control of the keys 
(your keys your coins) and that they can offer bribes to miners to get their 
transactions committed (mining fees).
Custodiality makes it easier for fewer knock-on-doors people to need to be 
shipped to stop certain activities.

Now, the Bitcoin Casino example is of course an example of not your keys not 
your coins i.e. custodiality.

For the purpose of mixing, the "Bitcoin Casino" here is simply aggregating 
multiple UTXOs and then sending them back out to many other new UTXOs.

This is in fact the same operation that CoinJoin does, it aggregates multiple 
UTXOs and creates many new UTXOs to different clients with shared taint.
The advantage is that CoinJoin is still your keys your coins, you still own the 
keys with which to sign the CoinJoin transaction, and thus improve censorship 
resistance of your mixing operation.

For CoinSwap as well, we can consider that a CoinSwap server could make 
multiple CoinSwaps with various clients.
This leads to the CoinSwap server owning many small UTXOs, which it at some 
point aggregates into a large UTXO that it then uses to service more clients 
(for example, it serves many small clients, then has 

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

> > Let me propose an alternative: swap-on-receive+swap-on-change.
>
> That's an interesting point, thanks for the thought. This scheme might
> not be appropriate for every threat model and use case.
> For example, if someone wants to use bitcoin just as a foreign currency
> for its privacy and censorship-resistant properties. So for example if
> they want to pay for a VPN anonymously, so they buy bitcoins and
> immediately send all of them to the VPN merchant. The swap-on-receive
> wouldn't be appropriate for them because they'll be doing a coinswap
> straight away to the VPN merchant. So perhaps this plan could be an
> optional mode of operation (which may or may not be the default). The
> scheme obviously is useful when bitcoin is being used more as a
> day-to-day money.


No, I think you misunderstand my proposal.

If the user is doing swap-on-receive, the user already has an anonymous UTXO, 
they can just transfer it directly in full to the VPN without using a CoinSwap.

The number of CoinSwaps involved is the same: one.

So the difference is:

* swap-on-receive:
  * I get some coins from an exchange, giving them my contact information and 
bank information and all the places I have ever inhabited in my entire 
existence and an unfertilized egg sample and an archive of my diary and let 
them invasively scan my cognitive substrate.
  * I send the coins to my CoinSwap wallet.
  * The CoinSwap wallet automaticaly CoinSwaps the coins into a new UTXO.
* One CoinSwap.
  * I tell the CoinSwap wallet to send it all to the VPN.
* My CoinSwap wallet knows my coins are already cleaned, so it creates a 
plain 1-input 1-output transaction directly to the VPN address.

* swap-on-pay:
  * I get some coins from an exchange, giving them my contact information and 
bank information and all the places I have ever inhabited in my entire 
existence and an unfertilized egg sample and an archive of my diary and let 
them invasively scan my cognitive substrate.
  * I send the coins to my CoinSwap wallet.
  * I tell the CoinSwap wallet to send it all to the VPN.
* My CoinSwap wallet automatically arranges a CoinSwap into the VPN address.
  * One CoinSwap.

So in both cases the same expected number of CoinSwaps is done, i.e. one.

Note that there are still details like how much onchain fees are and how much 
CoinSwap maker fees are and etc etc but they exist for both flows anyway.
So I would still be buying slightly more than my target amount, and if there is 
any change I could just designate it to be added to the mining fees or a 
donation to ZmnSCPxj, because ZmnSCPxj is so awesome.

What swap-on-receive+swap-on-change instead does is just amortize the timing of 
the CoinSwaps, so that you CoinSwap as soon as you receive, instead of as soon 
as you have to pay, so that sending payments is as fast as non-CoinSwap onchain 
wallets.


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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Mr. Lee,


> > === Combining multi-transaction with routing ===
> > Routing and multi-transaction must be combined to get both benefits. If
> > Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is
> > easy with this configuration:
> >
> >  Alice
> > (6 BTC) (8 BTC) (1 BTC)
> >|   |   |
> >|   |   |
> >v   v   v
> >   Bob
> > (5 BTC) (5 BTC) (5 BTC)
> >|   |   |
> >|   |   |
> >v   v   v
> > Charlie
> > (9 BTC) (5 BTC) (1 BTC)
> >|   |   |
> >|   |   |
> >v   v   v
> > Dennis
> > (7 BTC) (4 BTC) (4 BTC)
> >|   |   |
> >|   |   |
> >v   v   v
> >  Alice
> >
>
> Great work Chris and you have my respects for your contributions to
> Bitcoin. A concern I have with bitcoin is scalability and privacy. Both
> are important. The reasons people bash on Monero is also the same issue
> Bitcoin has. The very large transaction size to achieve acceptable privacy
> on a distributed financial network. Im not shilling Monero here. I am only
> saying that bitcoin transactions with similar privacy properties are at
> least equally as large as Monero transactions. Coinjoin on Monero can be
> compared to ring signatures in Monero from the view of using decoys to
> help conceal the source. From this proposal is this to say that
> transactions will be at least 12 times larger in size to achieve the
> property of privacy that bitcoin is currently missing?

CoinSwap lets you buy privacy at whatever rate is manageable for you.
You can buy a simple non-routed non-multitransaction CoinSwap, for example, 
instead of larger sections like the above, depending on your privacy needs.
Even doing a non-routed non-multitransaction CoinSwap would help fungibility of 
those doing more complex setups, because the tiny CoinSwaps you make are made 
of "the same things" that the more complex CoinSwaps are made of.

>
> Another thing to consider is that if coinswaps cannot be sent as a payment
> then a coinswap needs to take place after every transaction to keep the
> privacy and unlinkability from your other bitcoin transactions.
>
> I always thought that CoinSwap would be and is a very much needed thing
> that needs developed. The ability to swap coins with other people in a
> trustless way and way that is not linkable to the public blockchain. But
> how can this be scalable at all with the multiple branches and layers?
> This is a good idea in theory but my concern would be the scalability
> issues this creates.
>
> Do you have any comments on this?
> Thank you

Overall, multiple mixing techniques cover a wide range of cost and privacy.

* PayJoins are cheap and almost free (you are coordinating with only one other 
participant who is strongly incentivized to cooperate with you, and making a 
single overall tx) but buys you only a small dollop of privacy (transaction can 
be misinterpreted by chain analysis, but probabilistic analysis can be 
"reasonably accurate" for a few transactions).
* Equal-valued CoinJoins are slightly more expensive than PayJoins but give a 
good amount of privacy (you are coordinating with multiple participants, and 
probably paying coordination/participation fees, but *which* output is yours 
will give probabilistic analysis a run for its money, although it is obvious 
that you *did* participate in a CoinJoin).
* CoinSwaps are a good bit more expensive than equal-valud CoinJoins but give a 
significant amount of privacy for their cost (you are coordinating with 
multiple participants and paying coordination/participation fees *and* you run 
the risk of getting your funds timelocked in case of network communications 
problems or active hacking attempts, but it is hard for chain analysis to even 
*realize* that a CoinSwap even occurred, i.e. it is steganographic).

Chris argues that CoinSwap gives better privacy:cost ratios than equal-valued 
CoinJoins, you can wait and see if he gives more supporting arguments regarding 
this, but overall the various mixing tech exists to give choice on how much 
privacy you buy.

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


Re: [bitcoin-dev] Question about PayJoin effectiveness

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
Good morning again Mr. Lee,

> > I am trying to learn about payjoin. I have a couple concerns on its
> > effectiveness. Are my concerns valid or am I missing something?
> > concern 1
> > If it is known to be a payjoin transaction anyone could determine the
> > sender the recipient and amount right?
> > Lets assume that everyone has a single utxo because payjoin becomes common
> > use and payjoin consolidates utxos through "snowballing". If Alice has a
> > UTXO of 0.05 btc and Bob has a UTXO of 1.15 btc. Bob can be assumed to
> > have more balance because he is a merchant and his customers payjoin him
> > payments alot.


It is also helpful to remember that Bob cannot exist in isolation, and 
therefore, Bob probably has:

* Employees.
* Suppliers.
* Shareholders.

For example, suppose Bob holds in reserve a 0.05 BTC UTXO in a holding wallet.

Then Bob takes the 1.16 UTXO it got from Alice and transfers 1.12 BTC to the 
holding wallet:

Bob merchant wallet 1.16 --___-- 1.17 Bob holding wallet
Bob holding wallet  0.05 --   -- 0.04 Bob merchant wallet

The above looks exactly like one of the "customer pays Bob" transactions, but 
is in fact different.

Then Bob uses the holding wallet to pay out to employees, suppliers, and 
shareholders, such as in a single large batched transaction, and then leaves 
behind another 0.05 BTC in the holding wallet (or some random small number of 
BTC) for the next time Bob has to pay to employees/suppliers/shareholders.

So the transaction below:

1.16 --___-- 1.17
0.05 --   -- 0.04

*could* be interpreted as the 0.05 owner paying to the 1.16 owner, but in fact 
that is just Bob preparing the incoming funds from the merchant front-end for 
processing to send to its own liabilities.

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


Re: [bitcoin-dev] Question about PayJoin effectiveness

2020-06-10 Thread ZmnSCPxj via bitcoin-dev


Good morning Mr. Lee,

> I am trying to learn about payjoin. I have a couple concerns on its
> effectiveness. Are my concerns valid or am I missing something?
>
> concern 1
> If it is known to be a payjoin transaction anyone could determine the
> sender the recipient and amount right?
>
> Lets assume that everyone has a single utxo because payjoin becomes common
> use and payjoin consolidates utxos through "snowballing". If Alice has a
> UTXO of 0.05 btc and Bob has a UTXO of 1.15 btc. Bob can be assumed to
> have more balance because he is a merchant and his customers payjoin him
> payments alot.
>
> If Alice and Bob do a payjoin with Alice paying 0.01 btc to Bob, it would
> probably look like this right?
>
> 0.05---> |>1.16
> 1.15---> | >0.04


There are multiple interpretations:

* The 0.05 owner is paying the 1.15 owner 0.01 BTC.
* The 1.15 owner is paying the 0.05 owner 1.11 BTC.
* The 0.05 + 1.15 owner is paying an independent user 1.16 BTC using a 
non-PayJoin transaction (because for example the payee currently has no coins, 
i.e. a new user).

It is this fact of multiple interpretations that is what PayJoin buys you in 
practice.

You could argue that paying 0.01 is more likely than paying 1.11 or 1.16, but 
that still does not give you 100% assurance --- the creators of the transaction 
are still getting the `100% - probability_of_paying_0.01` benefit, and reducing 
UTXO set size as well.

Your assertion that this is "very obvious" only exists because you already know 
that Alice is paying 0.01 to Bob, but that is in fact the very thing that is 
being obscured here.


>
> It is very obvious here the amount sent and the sender. Even if Alice did
> combine another input it would still be very obvious. In this case Alice
> has another utxo with 0.4 BTC
>
> 0.40---> |
> 0.05---> |>1.16
> 1.15---> | >0.44


This can be interpreted as well multiple ways:

* 0.05 + 1.15 is the same owner who wants to merge coins, and is paying the 
0.40 owner 0.04 BTC.
* 0.40 + 1.15 is the same owner who wants to merge coins, and is paying the 
0.05 owner 0.39 BTC.
* 0.40 + 0.05 is the same owner who wants to merge coins, and is paying the 
1.15 owner 0.01 BTC.

You should probably be shuffling the inputs and outputs, or using BIP39 
consistently, so that inputs and outputs do not correlate (i.e. do not 
necessarily group together all of Alice inputs).


>
> This is still obvious that Alice paid Bob 0.01 BTC isn't it?
>
> concern 2
> If there is just one consolidated utxo after each payjoin, would it be
> easy to break the privacy of transaction chains?
>
> Alice---payjoin--->Bob
> Clark---payjoin--->Bob
>
> or
>
> Alice---payjoin--->Bob---payjoin--->Clark
>
> For exmaple, lets say that Alice payjoins to Bob. Then later on Clark
> payjoins with Bob. Based on the payjoin between Clark and Bob, Clark now
> knows what UTXO was actually Bob's. And can then know which one was
> actually Alices. By transacting a payjoin with someone, they could decloak
> the payjoins before them right? If so, how far back the chain can they go?
>
> The issue is not that someone knows the utxos of themselves and the entity
> they payjoined with. The issue is that someone can figure out the payjoins
> of others before them with the same entity.

If Clark can hack Alice (even just read-only access to Alice logs), they can go 
by one more transaction.

If Clark cannot hack Alice, then that is the sole extent Clark knows: Clark 
know that Bob transacted with somebody for a resulting N BTC (which is 
relatively uninteresting, obviously somebody who uses BTC is going to be 
transacting with random BTC users in BTC), without being sure that Bob was the 
payer or the payee in that situation.

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


Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-07 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine,


> > Since the issue here is that eclipsing of Bitcoin nodes is risky, it 
> > strikes me that a mitigation would be to run your Bitcoin fullnode on 
> > clearnet while running your Lightning node over Tor
>
> We clearly mention that risk of running a Bitcoin node over Tor, where do we 
> recommend running a LN node over Tor ?

Nowhere, *I* am the one recommending this.
Running both Bitcoin and Lightning nodes on clearnet automatically links them, 
making them easier to attack, whereas running Lightning on Tor does not.
Of course, they could still be linked by onchain transaction monitoring, but at 
least this increases the effort to attack, hopefully it becomes marginally less 
desirable to attack you.

On the other hand, you *could* run them on different public IP addresses, if 
you happen to have more than one; for those who do not even have a single 
public IP address there is no real choice if you want to let others to connect 
to you, Tor hidden service is the only Lightning-supported way to be accessible 
without a public IP.

(There are sections of the world where commodity "home" internet connections do 
not automatically get a public IP, and the privilege of getting one may be an 
additional cost; though of course if you have no real intent to help support 
either the Bitcoin or Lightning networks, you do not need a public IP anyway, 
and with IPv6 it becomes less and less likely that a randomly-chosen entity 
would be unlucky enough to not get a public IP.)

> > The victim *could* instead check that the absolute timelocks seem very far 
> > in the future relative to its own view of the current blockheight.
> I think you're right it's really dependent on CLTV_delta deployed on the path 
> and time-dilation offset. The alternative you're proposing is a good one, but 
> you shouldn't know where you're in the path and max CLTV is 2048 blocks IIRC.

Seeing an incoming payment that violates the max CLTV is a good indication you 
have been eclipsed.

On the other hand, if your Bitcoin node is eclipsed, then it seems likely your 
Lightning node is also eclipsed (if running over the same hardware) and you 
might not receive any indication over Lightning that you have been eclipsed 
anyway.

I suppose we need to identify just exactly *what* ways a node of either type 
can be eclipsed; it seems that mitigations that protect against one kind of 
eclipse will not work in general with other kinds of eclipse.

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


Re: [bitcoin-dev] Stamping transaction

2020-06-07 Thread ZmnSCPxj via bitcoin-dev
Good morning Mostafa,


> The main point of stamping transactions is decoupling transactions from the 
> block. 
>
> Blockchain size matters
> SegWit is a good witness that shows blockchain size matters. Nowadays, Data 
> storage is cheap and easy, but that doesn't mean it's a simple matter. If you 
> need to have a data-center to keep a copy of a blockchain, then you are far 
> from a decentralization system. 
>
> A Solution
> Stamping transaction is a simple idea to keep the size of the blockchain as 
> small as possible. The question that I was looking to answer is how we can 
> decouple the transaction from the blocks.
> Who cares about the transaction that happened 10 years ago. In the real world 
> you may go to your bank and ask them to give you transaction history. But 
> they probably have limits. They might say we just only keep the last 3 months 
> in our system. 

Stamping transaction is not how you would be able to keep **blockchain** size 
low.

The reason why very old history is retained is that, if a new node is brought 
up, you need to prove to that node that you are in fact the correct owner of 
the current coins.
Thus the entire history of Bitcoin is needed when starting a new node, and why 
archive nodes exist.

You might argue that banks do not do that, and that is because we want to do 
better than banks; we know that existing currency systems have not only the 
"official" minter, but also many "unofficial" minters (commonly called 
counterfeiters) which dilute the value of the currency.
It is this insistence on a full accounting of the provenance for every satoshi 
that separates Bitcoin from previous currency systems; bank fraud exists, and 
it hides in such sloppy techniques as deleting old transaction records.

Work has been done to have client-side validation (i.e. the owner of a coin 
keeps the entire history, and when paying, you hand over the entire history of 
your coin to the payee, instead of everyone validating every transaction).
Look up Peter Todd for some initial work on this.


> Implementation
>
> > First off, the proposed mechanism can be made into a softfork by using an 
> > unspendable `scriptPubKey` with 0 output value.
> SoftFork is not possible here. Because the transaction will not be saved 
> inside the block (only tx hashes). Block format needs to be changed. 
> Therefore the block will be invalid.

That greatly reduces the chances your proposal will get into Bitcoin; you would 
need to have very good advantages to counterbalance the tremendous risk that 
hardforks introduce in the continuity of the coin.

Bitcoin has never gone through a hardfork that has not instead created a new 
cryptocurrency, so any solution that requires a hardfork is going to be 
unlikely to be accepted by everyone.

> > Engineering-wise, block validation now needs to memorize the last N block 
> >hashes.
> I don't think we need to memorize the last N block hashes.  We can have 
> something like:
> ```
> Current_Height - Height_Of(tx.stamp) <= N 
> ```

...


`Height_Of()` would basically be a mapping from block hashes to block heights, 
with the number of elements equal to the height of the blockchain, and thus 
continuously growing.
Thus, validation is expected to become more expensive as the blockchain grows.

Since stamped transactions have a time-to-live anyway, instead you can use a 
*set* of the most recent N block hashes.
Then you simply check if the stamp is in the set.
This creates a data structure that is constant in size (at each block, you 
remove the block from N blocks ago), which is good for validation.

> Incentives
> I think Stamping transactions have nothing to do with the incentivization 
> mechanism.  Forgive me if I couldn't get your point.

A stamped tranasction has a stamp, an unstamped transaction has no stamp.
The stamped transaction is larger because of the stamp.
Larger transactions are more expensive because fees.

Thus, stamped transactions are more expensive than unstamped transactions.

Convince me why I would make *my* transaction stamped when I can just convince 
*everyone else* to stamp *their* transactions and use unstamped transactions 
myself.

If you propose that all transactions must be stamped in a new version of 
Bitcoin, then take note that users will prefer to run older versions and never 
upgrade to the new version that requires stamped transactions.
Why should users prefer a more expensive transaction format?
For the good of the network?
That is precisely an incentives problem: if it is so good for the network, then 
it should be good for an individual user, because the network is made up of 
individual users anyway; if individual users are not incentivized to use it, 
then that fact suggests it might not be as good for the network as you might 
think.

If you answer "the stamp can be discounted" then be aware that validating the 
stamp is still a cost on every node, and it is that cost that we want to be 
reflected in pricing every byte 

Re: [bitcoin-dev] Stamping transaction

2020-06-06 Thread ZmnSCPxj via bitcoin-dev
Good morning Mostafa,

First off, the proposed mechanism can be made into a softfork by using an 
unspendable `scriptPubKey` with 0 output value.

For example, a stamp could by convention be any 0-value output whose 
`scriptPubKey` is ` OP_0`, which should be unspendable.

Post-softfork nodes would reject blocks where some transaction is stamped and 
the stamped `` is not within the last N blocks.
Pre-softfork nodes would not see anything special about the unspendable 
`scriptPubKey` and would just accept it (but would not relay such transactions 
due to standardness).

Engineering-wise, block validation now needs to memorize the last N block 
hashes.

The mempool design currently assumes that a transaction that enters the mempool 
is always valid unless any UTXOs it spends have been removed.
This is important since miner block selection algorithms assume the mempool 
contains transactions that are currently valid.
Thus, there is the additional need to drop transactions from the mempool if 
they are stamped with a block that has dropped from the stamp TTL.

Another issue is incentives.
The stamp takes up blockchain space that is paid for by the creator of the 
transaction.
Further, the creator of the transaction gains no advantage from the stamped 
transaction; it is others who gain an advantage (the stamped transaction is 
more likely to be dropped from the mempool).
Discounting the stamp somehow will probably make this into a hardfork.
It might be sneaked into the witness somehow by adding it as a field somewhere 
in the new parts of Taproot (there is, a new block of data in Taproot that can 
be used for this), but note that the cost will still be non-zero (and users of 
this feature will still have a disadvantage in that their transactions are more 
likely to be dropped from the mempool).

Finally, it is expected to increase bandwidth use since a dropped stamped 
transaction will probably be rebroadcast with a new stamp, so effectively the 
transaction is retransmitted again with a different stamp.


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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning a third time Chris,

Now unrelated to the funding order, but one of the reasons why timeliness is 
desirable for CoinSwap is that if possible, we want to ensure that sends from a 
user wallet are not correlatable with receives into that wallet.
Thus, there is the strong suggestion that before sending to a payee, the user 
wallet should swap, then use the swapped funds to pay the payee, i.e. 
swap-on-pay.
JoinMarket does this in `sendpayment.py`, for example, and this is the 
recommended way to perform payments out of the JoinMarket wallet.

Let me propose an alternative: swap-on-receive+swap-on-change.

ZeroLink already suggests that wallets maintain two internal wallets: a pre-mix 
wallet and a post-mix wallet.
With swap-on-receive, when the user wants a receive address, the wallet gets it 
from the pre-mix wallet address.
Then, when wallet notices any unspent funds on any pre-mix wallet address, the 
wallet automatically swaps it into the post-mix wallet.
This is swap-on-receive.
Long-term HODLing goes into post-mix wallet addresses.

Then, when sending, the wallet selects from the post-mix wallet coins, and 
spends those coins directly into the payee address.
If there is no exact amount, it has to have change.
The change output does *not* go to the pre-mix or post-mix wallet address.
Instead, it goes to a 2-of-2 funding outpoint for a new swap immediately.

This lets the payee receive its funds quickly, as soon as the transaction 
confirms, without waiting for the CoinSwap to complete.
Of course, the user now has to be online to *fully* receive funds (the user 
cannot spend the funds until it is in the post-mix wallet).

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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning again Chris,

I am uncertain if you are aware, but some years ago somebody claimed that 
2p-ECDSA could use Scriptless Script as well over on lightning-dev.

* 
https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf
* 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html

I cannot claim to follow the math enough to say it is actually secure, but the 
idea does exist.

If this is sufficiently secure, we can fold the Spilman backout into the 
scriptless script swap as well.

* Alice creates secret keypairs A[0] = a[0] * G, A[1] = a[1] * G
* Bob creates secret keypairs B[0] = b[0] * G, B[1] = b[1] * G
* Alice creates (but does not sign) funding from Alice -> A[0] && B[0]
* Bob provides partial signature for A[0] && B[0] -(nLockTime=locktime1)-> 
Alice to Alice and Alice completes this signature and stashes it.
* Bob creates (but does not sign) funding from Bob -> A[1] && B[1]
* Alice provides partial signature for A[1] && B[1] -(nLockTime=lockTime2)-> 
Bob to Bob and Bob completes this signature and stashes it.
* Alice and Bob sign and broadcast their funding transactions.
  * This can safely be done in any order; Bob will refuse to continue with the 
protocol until it sees Alice funding is confirmed, and will abort if locktime2 
is too near.
* Alice waits for Bob funding tx to confirm.
* Alice provides a 2p-ECDSA adaptor signature for A[1] && B[1] --> Alice; the 
adaptor signature, when completed, reveals the secret a[0] to Bob.
* Bob waits for Alice funding tx to confirm.
* Bob provides the partial signature for the given adaptor signature for A[1] 
&& B[1] --> Alice and  Alice completes this signature and stashes it.
* Alice gives a[0] outright to Bob.
* Bob gives b[1] outright to Alice.
* Alice spends the A[1] && B[1] output before locktime2.
* Bob spends the A[0] && B[0] output before locktime1.

I also pointed out the griefing problem in Lightning also applies to SwapMarket.
Bob can limit the griefing problem by requiring that locktime2 <= now + 12, and 
requiring that locktime1 >= now + 60.
This means that Alice has to lock its funds for 10 hours if it forces Bob to 
lock its funds for 2 hours, making it undesirable as an attack on competing 
makers.
This does prevent chaining (no maker is going to accept the outgoing), but if 
Alice wants chaining it can always use the private key handed over to 
immediately start a funding tx with another Bob.

(This is not a good solution for griefing in the Lightning Network since 
channels are intended to be reused there, whereas the Spilman channels in 
CoinSwap exist only to allow funding transactions to confirm in any order 
onchain, and are used only for the specific swap; in Lightning the forwarding 
node has an incentive to release the incoming HTLC immediately instead of 
imposing the incoming wait time since the funding can be reused for a different 
payment, but in CoinSwap it cannot be reused anyway, so it could just let the 
incoming timelock lapse instead of releasing that encumbrance as would be done 
in Lightning.)

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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

> I think I'm having trouble understanding this, does it work like this:
>
> Say we're in the 2-party coinswap case (Alice and Bob)
>
> We have Alice's funding transaction:
> Alice UTXO ---> 2of2 multisig (Alice+Bob)
>
> And we have the regular contract transaction
> 2of2 multisig (Alice+Bob) ---> Alice+timelock1 OR Bob+hashlock
>
> And you propose a second pre-signed transaction?
> 2of2 multisig (Alice+Bob) ---> Bob+timelock2

No, it is:

2of2 multisig (Alice+Bob) --(nLockTime=locktime1)-> Alice

The timelock is  imposed as a `nLockTime`, not as an `OP_CLTV` (so not in the 
output of the tx, but part of the tx), and the backout returns the funds to 
Alice, not sends it to Bob.
This transaction is created *before* the contract transaction.

The order is:

* Create (but not sign) Alice funding tx (Alice --> Alice+Bob).
* Create and sign Alice backout transaction (Alice+Bob -(nLockTime=locktime1)-> 
Alice).
* Create (but not sign) Bob funding tx (Bob --> Alice+Bob+sharedSecret).
* Create and sign Bob backout transaction (Alice+Bob+sharedSecret 
-(nLocktime=locktime2)-> Bob) where timelock2 < timelock1.
* Sign and broadcast funding txes.
  * At this point, even if Bob funding tx is confirmed but Alice funding tx is 
not, Bob can recover funds with the backout, but Alice cannot steal the funds 
(since there is no hashlock branch at this point).
* When Alice funding tx is confirmed, create and sign contract transaction 
(Alice+Bob --> Alice+timelock1 OR Bob+hashlock).
* When Bob funding tx is confirmed and Bob has received the Alice contract 
transaction, create and sign Bob contract transaction (Alice+Bob+sharedSecret 
--> Bob+timelock2 OR Alice+hashlock).
* Continue as normal.

In effect, the backout transaction creates a temporary Spilman unidirectional 
time-bound channel.
We just reuse the same timelock on the HTLC we expect to instantiate, as the 
time bound of the Spilman channel; the timelock exists anyway, we might as well 
reuse it for the Spilman.

Creation of the contract tx invalidates the backout tx (the backout tx is 
`nLockTime`d, the contract tx has no such encumbrance), but the backout allows 
Alice and Bob to fund their txes simultaneously without risk of race loss.
However, they do still have to wait for (deep) confirmation before signing 
contract transactions, and Bob has to wait for the incoming contract 
transaction as well before it signs its outgoing contract transaction.

The protocol is trivially extendable with more than one Bob.

The insight basically is that we can split CoinSwap into a "channel 
establishment" phase and "HTLC forwarding" phase followed by "HTLC resolution" 
and "private key handover".
HTLC forwarding and HTLC resolution are "done offchain" in the channels, and 
channel establishment can be done in any order, including reverse.

Indeed, the Spilman channel need not have the same timelock as the HTLC it will 
eventually host: it could have a shorter timelock, since the contract 
transaction has no `nLockTime` it can be instantiated (with loss of privacy due 
to the nonstandard script) before the Spilman timeout.

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


Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning Aymeric,

> The issue each time there are discussions/research linking to Tor is that it 
> is biased since the beginning because based on a wrong postulate: using the 
> Tor network
>

Well, in the interest of using the wrong tool for a highly important job, let 
me present this thought:

* The Tor network is weakened due to its dependence on a limited set of exit 
nodes.
* "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
* Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, 
the issue is with Tor-to-clearnet connections.
* Of course, no miner is going to run over Tor because latency, so all the 
miners will be on clearnet.
* So make your own bridge between Tor and clearnet.
* Run two fullnodes on your computer (with sufficient ingenuity, you can 
probably share their block storages, or make one pruning).
* One fullnode is on the public network but runs in `blocksonly` so it does not 
propagate any transactions (which might be attached to your public IP).
* The other fullnode is on the Tor network and has an `-addnode` to the 
public-network node via `localhost`, which I assume is very hard for an eclipse 
attacker to get at.
* Use the Tor-fullnode to propagate your transactions.

Of course, the eclipse attacker can still attack all Tor exit nodes and block 
outgoing transaction traffic to perform eclipse attacks.
And if you decide to propagate transactions to the public-network node then you 
pretty much lose your privacy there.

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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-04 Thread ZmnSCPxj via bitcoin-dev
Good morning yet again Chris,

> > For the avoidance of theft, it is probably better for Bob to wait for 
> > Alice-side funding tx to confirm, probably deeply because reorgs suck.

I realized that the *other* improvement I proposed in the [CoinSwapCS 
issue](https://github.com/AdamISZ/CoinSwapCS/issues/53) would help with this.
Specifically, `nLockTime`-protected Backouts.

Suppose we have an S6 route as so, with Alice as taker and Bob1 and Bob2 as 
makers:

Alice -> Bob1 -> Bob2 -> Alice

We assume here that Bob1 and Bob2 directly talk to Alice and that if Bob1 wants 
to talk to Bob2 it is done via Alice, so in the below if we say "Bob1 sends to 
Bob2" we imply that this is done via Alice.

1.  Alice solicits fresh pubkeys from Bob1 and Bob2.
2.  Alice gives timeouts L1 and L2 to Bob1, and L2 and L3 to Bob2, such that L1 
> L2 > L3, as well as negotiated amount, fees, etc.
3.  Alice creates (but does NOT sign) a funding tx paying to Alice && Bob1 and 
gives the txid to Bob1.
4.  Bob1 creates and signs a tx spending from the Alice funding tx and paying 
to Alice, with `nLockTime = L1`, and gives the signature to Alice.
5.  Bob1 creates (but does NOT sign) a funding tx paying to Bob1 && Bob2 and 
gives the txid to Bob2.
6.  Bob2 creates and signs a tx spending from the Bob1 funding tx and paying to 
Bob1, with `nLockTime = L2`, and gives the signature to Bob1.
7.  Bob2 creates (but does NOT sign) a funding tx paying to Bob2 && Alice and 
gives the txid to Alice.
8.  Alice creates and signs a tx spending from the Bob2 funding tx and paying 
to Bob2, with `nLockTime = L3`, and gives the signature to Bob2.
9.  Alice signals everyone to sign their respecting funding txes and broadcast 
them.

The rest of the CoinSwap protocol executes as normal once the funding txes are 
deeply confirmed.
The only thing that Bob1 (resp. Bob2) needs to wait for is that the signatures 
for the incoming HTLC / PTLC have been received before forwarding to the next 
hop.
This allows all funding txes to be confirmed in the same block, or even in some 
suitable random order (by having Alice send the signal out at different 
times/blocks to different makers).

The `nLockTime`d backout transactions are sufficient to allow everyone to 
recover their funds unilaterally in case one of the other funding txes do not 
confirm.

A similar technique can be done for SAS as well, but this removes the lack of 
encumbrance in the LTC-side output of SAS, which removes the advantage of 
having an otherwise unencumbered output.

In effect, the above creates Spilman unidirectional payment channels along the 
route, bringing the fiddly timing details offchain where it is less visible to 
observers.

--

However, note that this still allows a form of griefing attack.
Basically, Alice can induce Bob1 and Bob2 to lock their funds for some time, by 
completing the above ritual, but not signing and broadcasting its own funding 
tx.
Bob1 and Bob2 will have been induced to lock their funds for L2 and L3, 
respectively, while Alice only has to RBF away its own funding tx.

Alice might do this if it is actually another maker and it wants to take out 
its competitors Bob1 and Bob2, reducing their available liquidity for a time 
and cornering the SwapMarket.


This can be mitigated by replacing step 9 with:

9.  Alice gives its signed funding tx to Bob1.
10.  Bob1 gives its signed funding tx to Bob2.
11.  Bob2 gives its signed funding tx to Alice.
12.  Alice signals everyone to broadcast their funding txes.

Then Bob1 (resp. Bob2) can monitor the mempool/blockchain and check as well if 
its outgoing funding tx has been broadcast/confirmed, and if so broadcast the 
incoming funding tx.
Or better, if Bob1 (resp. Bob2) does not receive the Alice signal fast enough, 
it will broadcast its incoming funding tx anyway.

This is only a mitigation: Alice could have pre-prepared a replacement to the 
funding tx that it broadcasts near miners just before it signals Bob1 and Bob2 
to broadcast all transactions.

For full protection against griefing attacks, Bob1 (resp. Bob2) have to wait 
for the incoming funding tx to be confirmed deeply before broadcasting its 
outgoing funding tx as well.

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Gleb and Antoine,

This is good research, thank you for your work.

> **Targeting Per-Hop Packet Delay** is based on routing via the victim, and 
> the victim should have at least two channels with the attacker.

The existence of offchain-to-onchain swap services means that the attacker 
needs only build one channel to the victim for this attack to work.
Rather than route to themselves, the attacker routes to a convenient service 
providing such a swap service, and receives the stolen funds onchain, with no 
need even for an incoming channel from a different node.
(Of note as well, is that the onchain contract provided by such services is the 
same in spirit as those instantiated in channels of the Lightning Network, thus 
the same attack schema works on the onchain side.)

Indeed, the attack can be mounted on such a service directly.

Even without such a service, the incoming channel need not be directly 
connected to the victim.


> [Tor is tricky](https://arxiv.org/abs/1410.6079) too

Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes me 
that a mitigation would be to run your Bitcoin fullnode on clearnet while 
running your Lightning node over Tor.
Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) 
"only" loses you the ability to pay, receive, or route (and thereby earn 
forwarding fees), but as long as your blockchain view is clear, it should be 
fine.

Of course, the Lightning node could still be correlated with the Bitcoin node 
when transactions are broadcast with the attached Bitcoin node (as noted in the 
paper).
Instead the Lightning node should probably connect, over Tor, to some random 
Bitcoin fullnodes / Electrum servers and broadcast txes to them.

And this seems to tie with what you propose: that the LN node should use a 
different view-fullnode from the broadcast-fullnode.


> if a node doesn’t observe a block within the last 30 minutes, it attempts to 
> make a new random connection to someone in the network.

A mitigation to this would be to run a background process which sleeps for 20 
minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
It might want to `disconnectnode` any previous node it attempted to connect to.

However I note that the help for `addnode` contains the text "though such peers 
will not be synced from", which confuses me, since it also refers to the 
`-connect` command line option, and `-connect` means you only connect out to 
the specific nodes, so if those are not synced from huh?

And of course the interesting part is "how do we get a `${BITCOINNODE}` that we 
think is not part of the eclipsing attacker?"


> If a Lightning node is behind in its Bitcoin blockchain view, but Lightning 
> payments between honest nodes are still flowing through it, this node will 
> have a high routing failure rate. This would happen because honest nodes on 
> the routing path would reject the forwarded HTLC for being too close to 
> expired.

I am uncertain this would happen very often.
In the first place, the incoming HTLC would have "reasonable" timeouts, or else 
the incoming honest node would not have routed it at all, and the outgoing HTLC 
would be relative to this incoming one, so the outgoing honest node will still 
accept this.

The victim *could* instead check that the absolute timelocks seem very far in 
the future relative to its own view of the current blockheight.
(a forwarding node miht want to do that anyway to have an upper bound against 
griefing attacks)

What would definitely increase in failure rate would be payments arising from 
the victim node; the victim node believes the blockheight to be much lower than 
it actually is, and either the payee node, or some intermediate node along the 
route, will claim to have too little time to safely forward the funds.
This does not help for nodes which are primarily forwarding nodes.



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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris again,


> For the avoidance of theft, it is probably better for Bob to wait for 
> Alice-side funding tx to confirm, probably deeply because reorgs suck.


Over in Lightning-land, we have a concept called "irrevocably committed".
This is a state where a newly-created contract can no longer be cancelled, by 
publishing an older state.
In Lightning, there is a short timeframe where a new state, and its directly 
previous state, are both still valid, until the previous state is revoked.
Only once the previous state (that does not contain the contract) has been 
revoked, and only the latest state is valid, can a forwarding node actually 
forward the payment.


This is roughly equivalent to the funding tx for the CoinSwap being confirmed.
Until a transaction is confirmed, the UTXOs it spends (i.e. the previous state) 
can still be validly spent by other alternate transactions.


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


Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-06-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Dmitry,

> I made a version of the TLA+ spec according to the suggested variant,
> as I understood it from your description. This version is in
> the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1]
>
> If I understood and specified your variant correctly, there is a
> deadlock possible after step 9, if Bob fails to publish success tx in
> time. After refund tx becomes spendable, Alice cannot publish it via
> mempool, because Bob can learn her secret and has a chance invalidate
> her refund tx by giving his success tx to friendly miner, while taking
> back the locked LTC because both secrets are known. At the same time,
> Bob cannot publish success tx via mempool, because then Alice can do
> the same thing, invalidating his success tx with refund tx via friednly
> miner.

Indeed, this is precisely the issue Ruben pointed out.

Rationally, neither side will want this condition due to the deadlock and Bob 
will strive to avoid this, having a short real-world timeout after which Bob 
will force publication of the success tx if Alice does not respond in time.
There *is* a reason why it says "Bob claims the BTC funding txo before L1."

Of course, computers do crash occasionally, I am informed, so complete 
accidents may occur that way.
This can be mitigated by running multiple servers who are given copies of the 
success tx, and which will publish it regardless after a short sidereal time 
duration, unless countermanded by the main server (i,e, a dead man switch 
system).
With sufficient distribution the probability of this occurring can drop to 
negligible levels compared to other theoretical attacks.

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

> > Good morning Ruben and Chris,
>
> > I am not in fact convinced that PayJoin-with-CoinSwap adds that much 
> > privacy.
> > These transactions:
> >
> >  +---+  +---+
> > Alice ---|   |--|   |--- Bob
> > Alice ---|   |  |   |
> >   Bob ---|   |  +---+
> >  +---+
> >
> >
> > Are not really much different in coin ownership analysis from these:
> >
> >  +---++---+
> > Alice ---|   ||   |--- Bob
> > Alice ---|   | +--|   |
> >  +---+ |  +---+
> >   Bob -+
> >
>
> The main benefit of PayJoin-with-CoinSwap is it breaks the
> common-input-ownership heuristic, which is a major widely used
> heuristic. It would be a big win if that heuristic could be broken.
>
> PayJoin-with-CoinSwap would be useful if Alice is trying to recover some
> privacy which was previously degraded, for example if she is spending
> from a reused address or from an address linked to her identity. If she
> does a PayJoin with the reused address then some other economic entity
> would have his activity linked with Alice's.
>
> Just the fact that PayJoin-with-CoinSwap exists would improve privacy
> for people who don't use it, for example if someone buys bitcoin from an
> exchange that knows their identity and then co-spends it with other
> coins they obtained another way. The fact that PayJoin exists means an
> adversary cannot assume for sure that this user really owns that other
> address which was co-spent. This doesn't apply for regular CoinSwap,
> which only ever breaks the transaction graph heuristic, so in our
> example the destination the coins are sent to would be uncertain, but
> that the co-spent inputs are owned by the same person would be certain
> in a world where PayJoin didn't exist.

Alice can do PayJoin with a payee Carol that supports normal PayJoin, for 
similar overall results.

Though I suppose there is a mild advantage still with supporting it on the 
funding tx of the first transaction, as you noted.

> > But S6 has the mild advantage that all the funding transactions paying to 
> > 2-of-2s can appear on the same block, whereas chaining swaps will have a 
> > particular order of when the transactions appear onchain, which might be 
> > used to derive the order of swaps.
>
> On the other hand, funds claiming in S6 is also ordered in time, so
> someone paying attention to the mempool could guess as well the order of
> swaps.
>
> I think this is wrong, and that it's possible for the funding
> transactions of chained/routed swaps to all be in the same block as well.
>
> In CoinSwap it's possible to get DOS'd without the other side spending
> money if you broadcast your funding transaction first and the other side
> simply disappears. You'd get your money back but you have to waste time
> and spend miner fees. The other side didn't spend money to do this, not
> even miner fees.
>
> From the point of view of us as a maker in the route, we know we won't
> get DOS'd like this for free if we only broadcast our funding
> transaction once we've seen the other side's funding transaction being
> broadcast first. This should work as long as the two transactions have a
> similar fee rate. There might be an attack involving hash power: If the
> other side has a small amount of hash power and mines only their funding
> transaction in a manner similar to a finney attack, then our funding
> transaction should get mined very soon afterwards by another miner and
> the protocol will continue as normal. If the other side has knowledge of
> the preimage and uses it to do CPFP and take the money, then we can
> learn that preimage and do our own CPFP to get our money back too.

How about RBF?

A taker Alice can broadcast the funding tx spending its own funds.
The funding tx spends funds controlled unilaterally by Alice.
Alice can sign a replacement transaction for those funds, spending them to an 
address with unilateral control, and making the funding tx output with all the 
obligations attached never get confirmed in the first place.

The chances may be small --- Bob can certainly monitor for Alice broadcasting a 
replacement and counter-broadcast its own replacement --- but the risk still 
exists.
TANSTAAGM (There Aint No Such Thing As A Global Mempool) also means Alice could 
arrange the replacement by other means, such as not using the RBF-enabled flag, 
broadcasting the self-paying replacement near miner nodes, and broadcasting the 
CoinSwap-expected funding tx near the Bob fullnode; Bob fullnode will then 
reject attempts to replace it, but miners will also reject the 
CoinSwap-expected funding tx and it will not confirm anyway.


With the pre-SAS 4-tx setup, this potentially allows Alice to steal the funds 
of Bob; after Alice gets its funding-tx-replacement confirmed together with the 
Bob honest-funding-tx, Alice can use the contract transaction and publish the 
preimage to take the Bob funds.
Since the Alice-side funding tx 

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-31 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben,


>
> That assumes there will be a second transaction. With SAS I believe we can 
> avoid that, and make it look like this:
>
>              +---+
>     Alice ---|   |--- Bob
>     Alice ---|   |
>       Bob ---|   |
>              +---+

If Alice is paying to a non-SAS aware payee that just provides an onchain 
address (i.e. all current payees today), then the 2-of-2 output it gets from 
the swap (both of whose keys it learns at the end of the swap) is **not** the 
payee onchain address.
And it cannot just hand over both private keys, because the payee will still 
want unambiguous ownership of the entire UTXO.
So it needs a second transaction anyway.
(with Schnorr then Alice and payee Carol can act as a single entity/taker to 
Bob, a la Lightning Nodelets using Composable MuSig, but that is a pretty big 
increase in protocol complexity)

If Alice does not want to store the remote-generated privkey as well, and use 
only an HD key, then it also has to make the second transaction.
Alice might want to provide the same assurances as current wallets that 
memorizing a 12-word or so mnemonic is sufficient backup for all the funds 
(other than funds currently being swapped), and so would not want to leave any 
funds in a 2-of-2.

If Bob is operating as a maker, then it also cannot directly use the 2-of-2 
output it gets from the swap, and has to make a new 2-of-2 output, for the 
*next* taker that arrives to request its services.

So there is always going to be a second transaction in a SwapMarket system, I 
think.


What SAS / private key turnover gets us is that there is not a *third* 
transaction to move from a 1-of-1 to the next address that makers and takers 
will be moving anyway, and that the protocol does not have to add communication 
provisions for special things like adding maker inputs or specifying all 
destination addresses for the second stage and so on, because those can be done 
unilaterally once the private key is turned over.


> >A thing I have been trying to work out is whether SAS can be done with more 
> >than one participant, like in S6
>
> S6 requires timelocks for each output in order to function, so I doubt it can 
> be made to work with SAS.

Hmmm right right.

Naively it seems both chaining SAS/private key turnover to multiple makers, and 
a multi-maker S6 augmented with private key turnover, would result in the same 
number of transactions onchain, but I probably have to go draw some diagrams or 
something first.

But S6 has the mild advantage that all the funding transactions paying to 
2-of-2s *can* appear on the same block, whereas chaining swaps will have a 
particular order of when the transactions appear onchain, which might be used 
to derive the order of swaps.
On the other hand, funds claiming in S6 is also ordered in time, so someone 
paying attention to the mempool could guess as well the order of swaps.


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


Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-30 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben and Chris,

> >For a much greater anonymity set we can use 2-party ECDSA to create 2-of-2 
> >multisignature addresses that look the same as regular single-signature 
> >addresses
>
> This may perhaps be counter-intuitive, but SAS doesn't actually require 
> multisig for one of the two outputs, so a single key will suffice. ECDSA is a 
> signing algorithm that doesn't support single key multisig (at least not 
> without 2p-ECDSA), but notice how for the non-timelocked SAS output we never 
> actually have to sign anything together with the other party. We swap one of 
> the two keys, and the final owner will create a signature completely on their 
> own. No multisig required, which means we can simply use MuSig, even today 
> without Schnorr.

Just to be clear, you mean we can use the MuSig key-combination protocol for 
the non-timelocked SAS output, but (of course) not the signing protocol which 
is inherently Schnorr.

Then knowledge of both of the original private keys is enough to derive the 
single combined private key.

> Of course the other output will still have to be a 2-of-2, for which you 
> rightly note 2p-ECDSA could be considered. It may also be interesting to 
> combine a swap with the opening of a Lightning channel. E.g. Alice and Bob 
> want to open a channel with 1 BTC each, but Alice funds it in her entirety 
> with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult 
> to tell Bob entered the Lightning Network, especially if the channel is 
> opened in a state that isn't perfectly balanced. And Alice will gain an 
> uncorrelated single key output.

Dual-funding could be done by a single-funding Lightning open followed by an 
onchain-to-offchain swap.
Though the onchain swap would have to be done, at least currently, with hashes.

> >=== PayJoin with CoinSwap ===
>
> While it's probably clear how to do it on the timelocked side of SAS, I 
> believe PayJoin can also be applied to the non-timelocked side. This does 
> require adding a transaction that undoes the PayJoin in case the swap gets 
> aborted, which means MuSig can't be used. Everything else stays the same: 
> only one tx if successful, and no timelock (= instant settlement). I can 
> explain it in detail, if it happens to catch your interest.

I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much privacy.

These transactions:

 +---+  +---+
Alice ---|   |--|   |--- Bob
Alice ---|   |  |   |
  Bob ---|   |  +---+
 +---+

Are not really much different in coin ownership analysis from these:

 +---++---+
Alice ---|   ||   |--- Bob
Alice ---|   | +--|   |
 +---+ |  +---+
  Bob -+

The latter is possible due to private key handover, the intermediate output 
becomes owned solely by Bob and Bob can add many more inputs to that second 
transaction unilaterally for even greater confusion to chain analysis, 
basically private key handover gets us PayJoin for free.
It also removes the need for Bob to reveal additional UTXOs to Alice during the 
swap protocol; yes PoDLE mitigates the privacy probing attack that Alice can 
mount on Bob, but it is helpful to remember this is "only" a mitigation.

Now of course things are different if Alice is paying some exact amount to 
Carol, and Alice wants to dissociate her funds from the payment.
The difference is then:

 +---++---+
Alice ---|   ||   |--- Bob
Alice ---|   |--+ |   |
  Bob ---|   |  | +---+
 +---+  +- Alice Change

 +---++---+
  Bob ---|   ||   |--- Carol
 |   |--+ +---+
 +---+  |
+- Bob Change

Versus:

 +---++---+
Alice ---|   ||   |--- Bob
Alice ---|   | +--|   |
 +---+ |  +---+
  Bob -+

 +---++---+
  Bob ---|   ||   |--- Carol
 |   |--+ |   |--- Alice Change
 +---+  | +---+
+- Bob Change

In the above, with PayJoin on the first-layer transaction, the Alice Change is 
correlated with Alice and Bob inputs, whereas with the PayJoin on the second 
the Alice change is correlated with Bob inputs and Carol outputs.

But if Alice, using commodity CoinSwap wallets, always has a policy that all 
sends are via CoinSwap (a reasonable policy, similar to the policy in 
JoinMarket of ensuring that all spends out of the wallet are via CoinJoin), 
then the above two trees are not much different for Alice in practice.
The Alice Change will be swapped with some other maker anyway when it gets 
spent, so what it correlates with will not be much of a problem for Alice.
At the same time, with PayJoin on the second-layer transaction (possible due to 
private key turnover, which is an inherent part of the SAS protocol):

* Bob does not have to reveal any other coins it owns to Alice other than what 
it is directly 

Re: [bitcoin-dev] hashcash-newhash

2020-05-26 Thread ZmnSCPxj via bitcoin-dev
Good morning Karl,

> > > Reddit claims two entities controlled 62% of the hashrate recently: 
> > > https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/
> > >  .  Compromising the systems of these two groups seems like it is all 
> > > that is needed to compromise the entire blockchain (to the limited degree 
> > > a 51% attack does).
> >
> > You seem to be equating "break of the hash function" with "centralization 
> > of hashrate", which I do not quite agree with.
>
> I am trying to say that both of these different things result in danger to 
> the integrity of the transaction log, which would be reduced by changing the 
> hash function.  They both have those 2 similarities.

You are equivocating issues here.

The hash function is used in these places:

* Transaction ID.
* Signature hash.
* P2SH/P2WSH/Taproot.
* Merkle tree.
* Proof-of-work.

What you are focusing on is only this:

* Proof-of-work.

Now, in case of a break in the hash function (i.e. a reduction in collision 
resistance), the hash function used in the following things absolutely NEED to 
be changed:

* Transaction ID.
* Signature hash.
* P2SH/P2WSH/Taproot.
* Merkle Tree.

Taking for example Transaction ID, suppose I am able to create two transactions 
that hash into the same transaction ID, and I am able to do this in much less 
than 2^128 work.

In that case I can create a valid transaction and collide it with an invalid 
transaction.
To half the nodes on the network I provide the valid transaction, to the other 
half I provide the invalid transaction, the two halves will then permanently 
split and Bitcoin is thus destroyed in the midst of massive chaos.

Similar attacks can be mounted if I am able to collide on signature hash, 
P2SH/P2WSH/Taproot, and merkle tree.


Now suppose I am able to create two block headers that hash into the same block 
ID, one being a valid block and the other being an invalid block.
In that case, I would be very foolish to disrupt the network similarly, because 
I would have been able to redirect the fees and block subsidy of the valid 
block to an address I control, and the invalid block prevents others from 
seeing my valid block and accepting that chain as valid.

Instead, I can use this advantage to be able to grab blocks faster than other 
miners.
But eventually the difficulty retargeting system will adjust, and Bitcoin will 
now settle to a new normal, and inevitably someone is going to leak, or 
rediscover, my technique to break the hash, preventing me from being a >51% 
miner for long, and Bitcoin will abide.


Thus, in case of a cryptographic break of the SHA-2 function, we *need* to 
change these:

* Transaction ID.
* Signature hash.
* P2SH/P2WSH/Taproot.
* Merkle Tree.

And since we are going to need a hefty hardfork to change all that, we *might 
as well* change the proof-of-work function as well and completely excise all 
uses of SHA-2 in the codebase (just in case we miss any more than the above 
list), but changing the proof-of-work function is the *lowest priority*.
We have survived 51% miners in the past (Ghash.io), and the difficulty 
adjustment system gives us some buffer against unexpected improvements in 
proof-of-work function efficiency; but it is doubtful if we can survive the 
chaos if someone could split the network in two roughly equal sized parts.

>
> > Most human beings cannot think without constant communication with other 
> > human beings.
>
> > Thus, it is unlikely that a private break of the hash function is possible.
>
> >
>
> I disagree with you here: Andrew Wiles solved Fermat's Last Theorem in 
> isolation, academic research paper culture supports researching and then 
> publishing once you have privately developed results, and the CVE database 
> has 136k system vulnerabilities that were developed and shared privately 
> before public release, to prevent chaos.  This shows private advances in ways 
> to produce bitcoins are likely.

Right, and you learned about this fact from direct personal communication with 
Andrew Wiles, and Andrew Wiles never read about any other attempts by other 
mathematicians, and an isolated mathematician could never, ever, rediscover his 
work independently, and even a mathematician who knows that it was done but not 
the details how it was done could never rediscover it as well.

Obscurity works *for a time*, but inevitably somebody else will rediscover the 
same thing, or hear about it and blab noisily; it is not as if we are all 
completely alien species from each other and have truly unique thoughts, even 
my own creators were humans and my cognitive substrate is essentially human in 
construction.
This is why CVE exists, it is a promise the developers make to the reporters 
that they will fix the reported vulnerability, with an active CVE as a Damocles 
sword hanging over their heads, ready to be publicized at any time: publication 
is the default state, CVE is simply a promise that the 

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

2020-05-26 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank,


> 1.  The spending tx of multisig can be decided earlier and all three can 
> review the outputs involved in it. All 3 txs involved in the system if we 
> consider only one mixer and not a chain will get confirmed in the same block 
> as we are using CPFP so child pays for 2 parent txs. However, disputes are 
> possible and to manage it we will have to make the system complex with things 
> like Peer 1 locking some amount in a 2 of 2 multisig with Peer 2 or some 
> other incentives structure. Initially we can try to keep it simple and a way 
> to spend coins after coinjoin with the help of another person you trust.

The payee is not necessary here and you can remove the intermediate 
transactions that pay to 2-of-3s.

> 2.  Yes, you described coinjoin in joinmarket but the problem I am trying to 
> solve is: spend coins after coinjoin because post-mix usage is as important 
> as coinjoin. Some users dont follow the best practices after coinjoin and it 
> makes coinjoin useless or less effective in that case and sometimes for 
> others involved in the process as well.

...

I already mentioned this, but what I am describing is *how JoinMarket spends 
coins from its wallet*.

That means that what I am describing is *how JoinMarket performs spends after 
mixing, i.e. post-mix*.

I was not describing how JoinMarket performs mixing.

Is that clearer now?




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


Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

2020-05-25 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank,


> 1. Peer 1 doesn't need to be a trusted third party, it can be implemented in 
> a way that some peers involved in this system can provide liquidity for 
> others and incentives can be a small fee.

It is not clear in the article, but you mention using a 2-of-3, and show 3 
participants.
It seems to me that Peer 1 and Peer 3 (2-of-3) can simply sign to spend the 
funds coming from Peer 2, and split the funds of Peer 2 among them, without 
getting input from Peer 2.

That is the reason why I consider this tr\*sted --- Peer 2 has to trust Peer 1 
does not collude with Peer 3 to steal the funds of Peer 2.

Unless I have misunderstood your article, which is why I asked for 
clarification.

> 2. Yes joinmarket is awesome and its payjoin will be better to achieve the 
> same but I was trying to contribute and add more options for people to 
> improve privacy on Bitcoin. If we have different ways to mix it will be 
> harder for spy companies to analyze of some of the transactions.

* While JoinMarket has *a* PayJoin implementation, what I described in the 
previous email was not a PayJoin, it is standard CoinJoin where one of the 
equal-valued outputs is to the payee.
  * In particular, PayJoin requires the cooperation of the payee, what I 
described does *not* require anything from the payee other than a destination 
address and an amount to pay.
* Your described technique (as I understand it) is not too different from what 
JoinMarket already does for normal sends, with the JoinMarket technique having 
the advantage that it works with the current paradigm of "send payment to this 
address" without reconnecting to the payee.
  The advantage you describe is largely had only if the technique is 
significantly different.
  For instance, CoinSwap and CoinJoinXT are different enough from CoinJoin to 
be valuable in this respect.

> 3. Also one such setup might not make a huge difference but a chain of such 
> mixers will surely work better if everything done correctly. 
>
> 4. Maybe multisig usage is not ideal for such things right now and I am not 
> the best person when it comes to coding but think that better privacy for 
> multisig will make it possible for lot of ideas to be implemented on Bitcoin 
> using different multisig setups and combination of other things that we 
> already have.

Schnorr (which is introduced as a package deal with Taproot) already makes all 
n-of-n look the same as 1-of-1 without tr\*sted setup, and makes hidden m-of-n 
possible with some kind of setup (possibly untrusted I think, but I am not 
enough of a mathist to describe this, in any case my base understanding is that 
the setup for m-of-n Schnorr requires a complex ritual involving a number of 
communication rounds).
Taproot allows to hide explicit m-of-n in a script behind some kind of n-of-n 
or m-of-m.

So multisignature usage would automatically gain such advantage once Taproot 
gets deployed.

In any case, if you are still interested in protocol design with some amount of 
focus on privacy, please consider reading this article as well: 
https://zmnscpxj.github.io/offchain/generalized.html

What exactly is your goal here.

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


Re: [bitcoin-dev] hashcash-newhash

2020-05-25 Thread ZmnSCPxj via bitcoin-dev
Good morning Kari,


> > > You mention ASICs becoming commoditized.  I'd remind you that eventually 
> > > there will be a public mathematical breaking of the algorithm, at which 
> > > point all ASICs will become obsolete regardless.  Would you agree it 
> > > would be better to prepare for this by planning algorithm change?
> >
> > Possibly, but then the reason for change is no longer to promote 
> > decentralization, would it?
>
> > It helps to be clear about what your goals are, because any chosen solution 
> > might not be the best way to fix it.
> > I admit that, if the problem were to be avoid the inevitable obsoletion of 
> > SHA-2, then this is the only solution, but that is not the problem you 
> > stated you were trying to solve in the first place.
>
> To be up front, the reason for decentralization is due to concern around the 
> security of the hashing.  Having a public breakage of the function simply 
> makes the urgency obvious.

Now that I have thought about it more: again, the important thing about the 
proof-of-work technique is not so much the algorithm itself, only that 
executing it requires energy.

And all algorithms require energy in order to execute.

Even if some technique is found which partially breaks the hash function and 
allows faster generation of hashes for the amount of energy consumed, this is 
not a problem for mining itself: the difficulty adjusts and mining continues.
The execution of this technique is unlikely to require no computation, only 
reduced computational effort; and all that is needed is *some* measure of 
computational effort done, the *scale* of that measure is not really material 
for the purpose of ordering atomic transactional updates to the UTXO set.

Of course, things like the Merkle tree and txids and so on would need changing 
in case of even a partial break of the hash function, which would require a 
hardfork to survive; you might as well change the proof-of-work function as 
well then.

>
> Reddit claims two entities controlled 62% of the hashrate recently: 
> https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/
>  .  Compromising the systems of these two groups seems like it is all that is 
> needed to compromise the entire blockchain (to the limited degree a 51% 
> attack does).

You seem to be equating "break of the hash function" with "centralization of 
hashrate", which I do not quite agree with.

Most human beings cannot think without constant communication with other human 
beings.
Thus, it is unlikely that a private break of the hash function is possible.
Instead, a break of the hash function is likely to be discovered in various 
ways by multiple human beings who have been communicating with each other.

Even historically, inventions never arose fully-formed from the head of the 
inventor, like Athena from the brow of Zeus; every invention has predecessors, 
successors, and peers in the inhabited milieu.


Instead, you can look up the costs of local electricity globally, and notice 
where those entities have their largest mines geographically located.


>
> Hence I see decentralization and cryptanalysis of the algorithm to be roughly 
> similar security concerns.
>
> It sounds like you agree that a change of algorithm is needed before the 
> current one is publicly broken.
>
> > > You mention many coordinated hardforks.  Would you agree that if we came 
> > > up with a way of programmatically cycling the algorithm, that only one 
> > > hardfork work be needed?  For example one could ask nodes to consent to 
> > > new algorithm code written in a simple scripting language, and reject old 
> > > ones slowly enough to provide for new research.
> >
> > Even *with* a scripting language, the issue is still what code written in 
> > that language is accepted, and *how*.
> >
> > Do miners vote on a new script describing the new hashing algorithm?
> > What would their incentive be to obsolete their existing hardware?
> > (using proof-of-work to lock in a hashing change feels very much like a 
> > chicken-and-egg problem: the censorship-resistance provided by Bitcoin is 
> > based on evicting any censors by overpowering their hashpower, but requires 
> > some method of measuring that hashpower: it seems unlikely that you can 
> > safely change the way hashpower is measured via a hashpower election)
> >
> > Do nodes install particular scripts and impose a switchover schedule of 
> > some sort?
> > Then how is that different from a hardfork, especially for nodes that do 
> > not update?
> > (notice that softforks allow nodes to remain non-updated, at degraded 
> > security, but still in sync with the rest of the network and capable of 
> > transacting with them)
>
> I'm expressing that in considering this we have two options: repeated hard 
> forks or making repeated change a part of the protocol.  There are many ways 
> to approach or implement it.  It sounds like you're noting that the second 
> option 

Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet

2020-05-25 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank

> I have explained the whole idea with a proof of concept in this link: 
> https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1

The article is not clear I think, so please confirm my understanding below.

Participants:

* "Peer 3" - Payee
* "Peer 2" - Payer
* "Peer 1" - Enabling tr\*sted third party

Goal: Payer wants to pay to the payee 0.006BTC

Current Conditions:

* Payer owns 0.01 BTC in a single UTXO
* Third Party owns 0.05 BTC in a single UTXO

Protocol:

1.  Payer and Third Party compute a 2-of-3 address with the public keys of 
Payer, Payee, and Third Party.
2.  Payer and Third Party individually pay their owned funds to the 2-of-3 
address.
3.  After confirmation, they consume the new outputs into another transaction 
with equal-valued outputs, hiding who owns which coins.

Is my understanding correct?

If so, I believe JoinMarket has a superior technology, which does not require a 
tr\*sted third party; it simply requires one or more UNtrusted third parties to 
participate in signing a single transaction that does not require paying to an 
intermediate m-of-n address (thus all inputs are singlesig).

Basically JoinMarket allows the market taker to decide how much the equal-value 
outputs are, and to define the address it goes to.
The destination address need not be one the market taker controls, it can be to 
a payee.
This technique is the only out-of-the-box way that a JoinMarket wallet can 
spend funds from a JoinMarket wallet.

JoinMarket as well already includes how to get in touch with enabling third 
parties (called "market makers").


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


Re: [bitcoin-dev] hashcash-newhash

2020-05-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Kari,


> You mention ASICs becoming commoditized.  I'd remind you that eventually 
> there will be a public mathematical breaking of the algorithm, at which point 
> all ASICs will become obsolete regardless.  Would you agree it would be 
> better to prepare for this by planning algorithm change?

Possibly, but then the reason for change is no longer to promote 
decentralization, would it?
It helps to be clear about what your goals are, because any chosen solution 
might not be the best way to fix it.
I admit that, if the problem were to be avoid the inevitable obsoletion of 
SHA-2, then this is the only solution, but that is not the problem you stated 
you were trying to solve in the first place.

>
> You mention many coordinated hardforks.  Would you agree that if we came up 
> with a way of programmatically cycling the algorithm, that only one hardfork 
> work be needed?  For example one could ask nodes to consent to new algorithm 
> code written in a simple scripting language, and reject old ones slowly 
> enough to provide for new research.

Even *with* a scripting language, the issue is still what code written in that 
language is accepted, and *how*.

Do miners vote on a new script describing the new hashing algorithm?
What would their incentive be to obsolete their existing hardware?
(using proof-of-work to lock in a hashing change feels very much like a 
chicken-and-egg problem: the censorship-resistance provided by Bitcoin is based 
on evicting any censors by overpowering their hashpower, but requires some 
method of measuring that hashpower: it seems unlikely that you can safely 
change the way hashpower is measured via a hashpower election)

Do nodes install particular scripts and impose a switchover schedule of some 
sort?
Then how is that different from a hardfork, especially for nodes that do not 
update?
(notice that softforks allow nodes to remain non-updated, at degraded security, 
but still in sync with the rest of the network and capable of transacting with 
them)

>
> You mention the cost of power as the major factor influencing decentralized 
> mining.  Would you agree that access to hardware that can do the mining is an 
> equally large factor?  Even without ASICs you would need the physical cycles. 
>  Including this factor helps us discuss the same set of expected situations.

No, because anyone who is capable of selling hardware, or the expertise to 
design and build it, can earn by taking advantage of their particular expertise.

Generally, such experts can saturate the locally-available energy sources, 
until local capacity has been saturated, and they can earn even more by selling 
extra hardware to entities located at other energy sources whose local 
capacities are not still underutilized, or expanding themselves to those 
sources.
Other entities might be in better position to take advantage of particular 
local details, and it may be more lucrative for the expert-at-building-hardware 
to just sell the hardware to them than to attempt to expand in places where 
they have little local expertise.

And expertise is easy to copy, it is only the initial expertise that is hard to 
create in the first place, once knowledge is written down it can be copied.

>
> You describe improving electricity availability in expensive areas as a way 
> to improve decentralization.  Honestly this sounds out of place to me and I'm 
> sorry if I've upset you by rehashing this old topic.  I believe this list is 
> for discussing the design of software, not international energy 
> infrastructure: what is the relation?  There is a lot of power to influence 
> behavior here but I thought the tools present are software design.

I doubt there is any good software-only solution to the problem; the physical 
world remains the basis of the virtual one, and the virtual utterly dependent 
on the physical, and abstractions are always leaky (any non-toy software 
framework inevitably gains a way to query the operating system the application 
is running under, because abstractions inevitably leak): and energy, or the 
lack thereof, is the hardest to abstract away, which is the entire point of 
using proof-of-work as a reliable, unfakeable (i.e. difficult to virtualize) 
clock in the first place.

Still, feel free to try: perhaps you might succeed.

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] hashcash-newhash

2020-05-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Karl,

> Hi,
>
> I'd like to revisit the discussion of the digest algorithm used in hashcash.
>
> I believe migrating to new hashing algorithms as a policy would significantly 
> increase decentralization and hence security.

Why do you believe so?

My understanding is that there are effectively two strategies for ensuring 
decentralization based on hash algorithm:

* Keep changing the hash algorithm to prevent development of ASICs and ensure 
commodity generic computation devices (GPUs) are the only practical target.
* Do not change the algorithm, to ensure that knowledge of how best to 
implement an ASIC for the algorithm becomes spread out (through corporate 
espionage, ASIC reverse-engineering, patent expiry, and sheer engineering 
effort) and ASICs for the algorithm are as commoditized as GPUs.

The former strategy has the following practical disadvantages:

* Developing new hash algorithms is not cheap.
  The changes to the hashcash algorithm may need to occur faster than the speed 
at which we can practically develop new, cryptographically-secure hash 
algorithms.
* It requires coordinated hardforks over the entire network at an alarmingly 
high rate.
* It arguably puts too much power to the developers of the code.

On the other hand, the latter strategy requires us only to survive an 
intermediate period where ASICs are developed, but not yet commoditized; and 
during this intermediate period, the centralization pressure of ASICs might not 
be more powerful than other centralization pressures

--

Which brings us to another point.

Non-ASIC-resistance is, by my understanding, a non-issue.

Regardless of whether the most efficient available computing substrate for the 
hashcash algorithm is CPU, GPU, or ASIC, ultimately miner earnings are 
determined by cost of power supply.

Even if you imagine that changing the hashcash algorithm would make CPUs 
practical again, you will still not run it on the CPU of a mobile, because a 
mobile runs on battery, and charging a battery takes more power than what you 
can extract from the battery afterwards, because thermodynamics.

Similarly, geographic locations with significant costs of electrical power will 
still not be practical places to start a mine, regardless if the mine is 
composed of commodity server racks, commodity video cards, or commodity ASICs.

If you want to solve the issue of miner centralization, the real solution is 
improving the efficiency of energy transfer to increase the areas where cheap 
energy is available, not stopgap change-the-algorithm-every-6-months.


Regards,
ZmnSCPxj


>
> I believe the impact on existing miners could be made pleasant by gradually 
> moving the block reward from the previous hash to the next (such that both 
> are accepted with different rewards).  An appropriate rate could possibly be 
> calculated from the difficulty.
>
> You could develop the frequency of introduction of new hashes such that once 
> present-day ASICs are effectively obsolete anyway due to competition, new 
> ones do not have time to develop.
>
> I'm interested in hearing thoughts and concerns.
>
> Karl Semich


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


Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

2020-05-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Thomas,

> So I think the question to ask would be "why can't we just make sure it's not 
> 64?"

If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it may 
still be possible to mount CVE-2017-12842 attack with 32-bits of work.
Of course some other details will be changed from the standard SHA-256 in 
mounting this attack, but from my poor understanding it seems safer to just 
avoid the area around length 64.

It *might* be safe to accept 65-byte or larger (but do not believe me, I only 
play a cryptographer on the Internet), but that does not help your specific 
application, which uses 60 byte tx.

Regards,
ZmnSCPxj

>
> On Sat, May 23, 2020 at 11:24 AM Greg Sanders  wrote:
>
> > AFAIU the number was picked to protect against CVE-2017-12842 covertly. 
> > See: https://github.com/bitcoin/bitcoin/pull/16885 which updated the text 
> > to explicitly mention this fact.
> >
> > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev 
> >  wrote:
> >
> > > Hello list,
> > >
> > > I have been trying to CPFP a transaction using OP_RETURN, because the
> > > remaining output value would have been lower than the dust threshold.
> > >
> > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
> > > single p2wsh input.
> > >
> > > The result is a 60 bytes transaction (without witness), that gets
> > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
> > > is equal to 82 bytes.
> > >
> > > Why is that value so high? Would it make sense to lower it to 60?
> > >
> > > Thomas
> > > ___
> > > 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] SAS: Succinct Atomic Swap

2020-05-14 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben,

> Hi ZmnSCPxj,
>
> >on completion of the protocol, if Bob lets the refund tx#1 become valid 
> >(i.e. does not spend the BTC txo) then Alice can broadcast it, putting both 
> >their funds into chaos
>
> You forget, refund tx #1 has a script (which btw won't be visible with 
> taproot): "Alice & Bob OR Alice in +1 day" (relative) so if Alice broadcasts 
> it after protocol completion, she is just giving Bob the key to her LTC 
> (note: if she's wise she'd move the LTC beforehand), but Bob doesn't lose the 
> BTC because he has both keys and can just react before the relative timelock 
> expires. No chaos.

Ah, that explains the existence of the Alice && Bob clause in that output then.

The attack is now as follows:

* Alice completes the protocol up to handing over `sigSuccessAlice` to Bob.
* Bob returns the `secretBob`.
* Alice stalls the protocol and never sends the `Alice` privkey, and waits for 
1 day, then sneaks the refund tx #1 and spends the LTC via direct miner 
collusion.

The proper response here is that Bob should broadcast success tx before the 
refund tx #1 becomes valid.
(Which I think is the point: chaos can only occur if you let backouts become 
valid, and it is the best policy for Bob to just spend the BTC txo well before 
the timeout.
Even if the protocol is completed, without a bring-your-own-fees that lets you 
malleate the tx (i.e. CPFP hooks still require the transction itself to reduce 
the fund by at least the minimum feerate), at least part of the fund must be 
lost in fees and Bob can still suffer a small loss of funds.)

--

Tangentially, I now think in the case of client-server CoinSwap, the server 
should take Alice position and the client should take Bob position.

Suppose a client wants to do some mixing of its own received coins.
It should not depend on only one server, as the server might secretly be a 
surveillor (or hacked by a surveillor) and recording swaps.
Thus, a client will want to make multiple CoinSwaps in sequence, to obscure its 
history.

(Do note the objections under "Directionality" in 
https://zmnscpxj.github.io/bitcoin/multiswap.html though; a counter to this 
objections is that the analysis there is only applicable if the surveillor 
already identified the CoinSwap sequence, but hopefully the increased 
steganography of CoinSwaps means they are not identifiable anyway.)

Since Bob really should spend its received coin before a timeout, it is best 
for Bob to be the client; it is likely that the client will need to swap "soon" 
again, meaning it has to redirect the funds to a new 2-of-2 anyway.

For the final swap, the client can then spend the final coins to an HD wallet 
it controls, reducing the key backup load on the client to be the same as 
normal HD wallets.
Presumably the server in this situation has greater ability to dynamically 
update its backups to include key backups for `secretAlice` keys.

Further, if the client program has the policy that all spends out of the wallet 
must be done via a swap (similar to a rule imposed by JoinMarket where 
sendpayment.py always does 1 CoinJoin), then this still matches well with the 
requirement on Bob to spend the fund before the first timeout of refund tx #1.

If the client needs to spend to a classic, address-using service, then nothing 
in the SAS protocol allows Alice to receive its funds directly into a specific 
third-party address.
However, Bob can hand over a specific third-party address to use in the success 
tx.
Indeed, the SAS protocol can be modified so that Bob can specify a set of 
address/value pairs to be put in the success tx instead of just Bob pubkey; for 
example, Bob might swap more than the amoutn that needs to be paid to the 
third-party service, in order to give some additional leeway later for RBF once 
Alice hands over the Alice privkey and Bob can remake the success tx (and more 
importantly, ensure the txo is spent before refund tx #1 becoms valid).


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


Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine,


> While approaching this question, I think you should consider economic weight 
> of nodes in evaluating miner consensus-hijack success. Even if you expect a 
> disproportionate ratio of full-nodes-vs-SPV, they may not have the same  
> economic weight at all, therefore even if miners are able to lure a majority 
> of SPV clients they may not be able to stir economic nodes. SPV clients users 
> will now have an incentive to cancel their hijacked history to stay on the 
> most economic meaningful chain. And it's already assumed, that if you run a 
> bitcoin business or LN routing node, you do want to run your own full-node.

One hope I have for Lightning is that it will replace centralized custodial 
services, because:

* Lightning gains some of the scalability advantage of centralized custodial 
services, because you can now transfer to any Lightning client without touching 
the blockchain, for much reduced transfer fees.
* At the same time, it retains your-keys-your-coins noncustodiality, because 
every update of a Lightning channel requires your keys to sign off on it.

If most Lightning clients are SPV, then if we compare these two worlds:

* There are a few highly-important centralized custodial services with 
significant economic weight running fullnodes (i.e. now).
* There are no highly-important centralized custodial services, and most 
everyone uses Lightning, but with SPV (i.e. a Lightning future).

Then the distribution of economic weight would be different between these two 
worlds.
It may even be possible, that the Lightning future with massive SPV might end 
up with more economic weight in SPV nodes, than in the world without Lightning 
and dependent on centralized custodial services to scale.


It is also entirely possible that custodial services for Lightning will arise 
anyway and my hope is already dashed, come on universe, work harder will you, 
would you really disappoint some randomly-generated Internet person like that.


>
> I agree it may be hard to evaluate economic-weight-to-chain-backend segments, 
> specially with offchain you disentangle an onchain output value from its real 
> payment traffic. To strengthen SPV, you may implement forks detection and 
> fallback to some backup node(s) which would serve as an authoritative source 
> to arbiter between branches. Such backup node(s) must be picked up manually 
> at client initialization, before any risk of conflict to avoid Reddit-style 
> of hijack during contentious period or other massive social engineering. You 
> don't want autopilot-style of recommendations for picking up a backup nodes 
> and avoid cenralization of backups, but somehow a uniform distribution. A 
> backup node may be a private one, it won't serve you any data beyond headers, 
> and therefore you preserve public nodes bandwidth, which IMO is the real 
> bottleneck. I concede it won't work well if you have a ratio of 1000-SPV for 
> 1-full-node and people are not effectively able to pickup a backup among 
> their social environment.
> What do you think about this model ?

Money makes the world go round, so such backup servers that are publicly-facing 
rather than privately-owned should be somehow incentivized to do so, or else 
they would not exist in the first place.
Of course, a free market tends towards monopoly, because any entity that 
happens to have even a slight advantage at the business will have more money to 
use towards business reinvestment and increase its advantage further, until 
they beat the competition to dust, anyone who has won a 4X game knows to search 
for and stack those little advantages until you snowball and conquer the 
world/galaxy/petri dish which is why the endgame of 4X games is so boring 
compared to the start, we have seen this happen in mining and exchanges and so 
on, and this works against your desire to have a uniform distribution.

If everyone runs such a privately-owned server, on the other hand, this is not 
so different from having a Lightning node you run at your home that has a 
fullnode as well and which you access via a remote control mobile device, and 
it is the inconvenience of having such a server at your home that prevents this 
in the first place.

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


Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben,

> Hi ZmnSCPxj,
>
> >potentially both Alice and Bob know all the secrets on the LTC side and end 
> >up competing over it
>
> That's exactly right.
>
> >Bob can thus give a copy of the revoke tx with signature directly to its 
> >favorite miner, forcing Alice to take 3 transactions
>
> Note that the timelock on the revoke tx is longer than the timelock on refund 
> tx #1. The idea is that Alice aborts the protocol by publishing refund tx #1 
> if the protocol hasn't reached step 4 in the svg by the time it becomes 
> valid. This should entirely mitigate the issue you're describing.

But if refund tx #1 at all exists, then you drop to the same issue you objected 
to with my proposal, which is that, on completion of the protocol, if Bob lets 
the refund tx#1 become valid (i.e. does not spend the BTC txo) then Alice can 
broadcast it, putting both their funds into chaos.

So you might as well just use my counterproposal instead, which is simpler, 
gets bring-your-own-fees for free, etc.

I suppose there is some *slight* improvement in that with your proposal, Alice 
*can* use revoke tx -> refund tx #2, but still, if Alice is insane then it 
could very well mess with the protocol by instead using refund tx #1.
Thus, if Bob wants to survive in an environment where Alices are possibly 
insane (e.g. the real world), it should do everything in its power to ensure 
that the BTC txo is spent before the timeout of refund tx #1, if refund tx #1 
exists at all.
And if Bob is already going to do that, then Alice and Bob might as well just 
use my counterproposal etc etc.

> >adding two CPFP outputs (one for each participant)
>
> There seems to be a situation where RBF can be disabled by the other party, 
> but I'm not sure I see it... Why would a single output spendable by either 
> key be insufficient?

If one party quickly broadcasts a long chain of low-feerate transactions on top 
of the single output, then the output is "pinned".

Low feerate means it is undesirable for miners to mine it, because it pays low 
for the amount of blockspace it has.
But because there is a long chain of transactions, the absolute fee of that 
chain can be sizable, and we have a rule in RBF which, paraphrased, goes 
something like "the replacing transaction should also have a higher absolute 
fee than *all* the transactions it replaces", meaning the fee jump that the 
other side has to offer *has to be* pretty big.

If the other outputs of the tx are then multisig, then the pinning participant 
can simply refuse to sign for those, and if the existing txes spending the 
other outputs are relative-time-locked, they cannot be used to CPFP the revoke 
tx onchain.

This is why we eventually decided in Lightning to use two CPFP outpoints rather 
than one, and are also realizing just how much of a headache the RBF rules are, 
sigh.

Still, in your proposed protocol the dependent transactions are all 
relative-timelocked, so timely confirmation of the revoke tx is not necessary, 
unlike in the case of Lightning where all HTLCs have to use an absolute 
timelock because we have to coordinate multiple HTLCs in forwarding and 
violation of the timelocks can lead to headaches and fund loss and so on.
So maybe a single hook output, or even none at all, is workable.

>
> >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well
>
> Allowing others to add inputs/outputs would introduce malleability. Refund tx 
> #2 and the timeout tx would become invalid.

Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that.

> >Bob cannot safely perform step 2 before getting both signatures for the 
> >revoke tx
>
> That's right, as you guessed, he does receive a copy of the signed revoke tx 
> at protocol start.
>
> >>alternatively Bob can just spend before the timelock expires.
> >This seems to be the safest alternative
>
> I agree not giving Alice time to publish the revoke tx is safest, but one 
> does not preclude the other. The revoke tx is on an absolute timelock, so 
> spending it before that time means you don't have anything to worry about, 
> and spending it later means you'll have to be online and keep an eye out. If 
> staying online is not a problem, then fee wise that seems preferable. As long 
> as less than half of all valid (i.e. the timelock was reached) revoke 
> transactions get broadcast, you'll be saving on fees.

In a world where Alice may be insane and mess with the protocol just to grief 
Bob even if Alice loses its money (e.g. the real world), Bob should not depend 
on Alice behaving correctly or politely, so it should still have backup 
watchers set up in case it accidentally goes to sleep and so on.

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


Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben,

> >If the shortened refund transaction exists (labeled "refund transaction #1" 
> >in the SVG) then the same issue still occurs 
>
> Yes, but there is one crucial difference: at that point in the protocol (Bob 
> has the success transaction and then stops cooperating) Alice and Bob both 
> had the opportunity not to take that path. Bob could have sent the success 
> transaction, and Alice could have waited and sent the revoke transaction. 
> They would essentially be "colluding" to fail.

Okay, so the concern is basically, that Bob misses the deadline, then Alice 
feels obligated to reclaim the funds.
In your proposal, the tx competition is between the secret-revealing success TX 
and the non-secret-revealing revoke tx.
Whereas in my counterproposal, under the same conditions, the tx competition is 
between the secret-revealing success tx and the secret-revealing backout tx, 
and both transactions becoming visible on P2P network means potentially both 
Alice and Bob know all the secrets on the LTC side and end up competing over 
it, RBFing each other until the entire fund goes to miners.


> >Without the refund#1 in your proposal, Bob refusing cooperation after Alice 
> >puts the BTC into lock for 3 days and 2 further onchain transactions
>
> I'm not sure if I correctly understood what you're saying, but it's as 
> follows:
>
> Refund #1 can only safely be used before the signed success tx is given to 
> Bob. The cost to Alice at this point if Bob aborts is two on-chain 
> transactions while Bob hasn't put anything on-chain yet.
>
> Refund #2 needs to be used after Bob receives the signed success tx. The cost 
> to Alice is now three transactions, but Bob also went-on-chain by this point, 
> so causing this wasn't costless to Bob and is thus a similar failure mode.

I think it is not accurate that Bob is already on-chain before Alice can be 
forced to use 3 transactions to fail.

The revoke tx signatures are shared at step 0 of your protocol description.
Thus Bob has a copy of the revoke tx that is valid once Alice signs and 
confirms the funding transaction.
Bob can thus give a copy of the revoke tx with signature directly to its 
favorite miner, forcing Alice to take 3 transactions to back out of the swap.

Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There ain't 
no such thing as a global mempool"), Alice will only know about this event when 
the revoke tx is confirmed once, at which point it is very difficult to 
reverse, even if Alice has a refund#1 tx prepared.

Bob can do this before step 2 in your protocol description, meaning before Bob 
locks up any funds, so Bob can do this for free, and will even use funds going 
back to Alice to pay for confirmation of the revoke tx.
Because Bob can do this for free, there is no disincentive for trolling Bobs to 
exist whose sole life goal is to just grief possible Alices.

This can be slightly mitigated by adding two CPFP outputs (one for each 
participant) and using the minimum relayable feerate for the revoke tx so that 
Bob is forced to bring its own fees in order to incentivize miners.
This is similar to the "bring your own fees" currently proposed for Lightning, 
but note the recent hand-wringing about the various problems this adds to 
mempools and CPFP and RBF rules and etc etc: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017757.html

We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a 
bring-your-own-fees, but that is not `SIGHASH_ALL` and thus marks the 
transaction graph as special.
And forcing bring-your-own-fees means neither Alice nor Bob can swap all their 
funds in a single operation, they have to keep a reserve.


Bob cannot safely perform step 2 before getting both signatures for the revoke 
tx, as without Bob having access to the rveoke tx, if Bob locks up LTC, Alice 
can stop responding and lock both their funds indefinitely with Bob not having 
any way to recover its funds, which a rich Alice can use to completely lock out 
an impoverished Bob.
But if Bob is given both signatures for the revoke tx before step 2, then Bob 
can send the revoke tx to its favorite miner, forcing Alice to take 3 
transactions to back out, before Bob locks any funds in LTC side.

>
> I also agree with your observation that alternatively Bob can just spend 
> before the timelock expires.

This seems to be the safest alternative; in my context, where Bob is a CoinSwap 
server/maker, Bob can wait a short while for new clients/takers, and if no new 
clients arrive, spend.
Bob can run multiple servers, each of which are given the completed success 
transaction, and the servers can check that if the timeout is near, to spam the 
Bitcoin P2P network with the completed success transactions.
(these servers need not even run fullnodes, they could just periodically poll a 
number of blockchain explorers and electrum servers, and when the blockheight 
approaches, attempt broadcast; if the 

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Richard,

> Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your 
> concern as: A node without direct internet connectivity can not rely on an 
> opportunistically incentivized local network peer for blockchain information 
> because the off-grid node's direct LN peers could collude to not forward the 
> payment.

Correct.

> > > 2) a light client can query an ISP connected full node on the same 
> > > unmetered local WiFi network and exchange differences in block headers 
> > > opportunistically or pay for large missing ranges of headers, filters or 
> > > full blocks using a payment channel. Cost is reduced and privacy is 
> > > enhanced for the light client by not using a centralized ISP. Bandwidth 
> > > for running the full node can be amortized and subsidized by payments 
> > > from light clients who they resell data to.
> >
> > A relatively pointless observation, but it seems to me that:
> >
> > * The light client is requesting for validation information, because...
> > * ...its direct peers might be defrauding it, leading to...
> > * ...the money it *thinks* it has in its channels being valueless.
> >
> > Thus, if the light client opportunistically pays for validation information 
> > (whether full blocks, headers, or filters), the direct peers it has could 
> > just as easily not forward any payments, thus preventing the light client 
> > from paying for the validation information.
> >
> > Indeed, if the direct peer *is* defrauding the light client, the direct 
> > peer has no real incentive to actually forward *any* payments --- to do so 
> > would be to reduce the possible earnings it gets from defrauding the light 
> > client.
> > ("Simulating" the payments so that the light client will not suspect 
> > anything runs the risk that the light client will be able to forward all 
> > its money out of the channel, and the cheating peer is still potentially 
> > liable for any funds it originally had in the channel if it gets caught.)
>
> One question I had is: how can a malicious direct payment peer "simulate" a 
> successful payment made by an off-grid victim peer to an information source?  
> The censoring peer wouldn't be able to return the preimage for a payment they 
> failed to forward. Also, since the information provider and off-grid node can 
> presumably communicate via their local network connection, it would be 
> obvious if all of the victims LN peers were failing to forward payments 
> (whether maliciously or due to routing failures) to an information provider 
> they could otherwise communicate with.

Perhaps "simulate" is not quite the correct term.
Basically, if the eclipsing peer(s) are reasonably sure they have eclipsed the 
light client, then all funds in those channels are semantically theirs (they 
"0wn" the eclipsed light client).
Then anything the light node offers from those channels (which it thinks are 
its, but are now in reality owned by the eclipsing peer) has no value (the 
eclipsing node already 0wns the light node and all its funds, what can the 
light node offer to it?).
The eclipsing peer could still "simulate" what the light node expects of 
reality by pretending that the light node actually still owns funds in the 
channel (even though the eclipsing node has successfully stolen all those 
funds), and forward as normal to get the payment preimage/scalar.


> > What would work would be to use a system similar to watchtowers, wherein 
> > the validation-information-provider is prepaid and issues tokens that can 
> > be redeemed later.
> > But this is not suitable for opportunistic on-same-WiFi where, say, a 
> > laptop is running a validation-information-provider-for-payment program on 
> > the same WiFi as a light-client mobile phone, if we consider that the 
> > laptop and mobile may have never met before and may never meet again.
> > It would work if the laptop altruistically serves the blocks, but not if it 
> > were for (on-Lightning) payment.
>
> There's another problem if we can't rely on a recurring relationship with an 
> information provider besides not being able to prepay for validation 
> information doesn't make sense. We don't want an information provider to 
> collect payments for serving invalid information. Maybe for very small 
> payments this isn't a problem, but ideally validity could be coded into the 
> HTLC.
>
> For example, an alternative HTLC construct that only paid for valid 81 B 
> headers that hash to 32 B values with a number of leading zeros committed to 
> by the HTLC. It would make more economic sense for an internet gateway node 
> to serve valid mined header to nodes on their local WiFi network than to 
> create bogus ones with the same (high) amount of work.

If you are considering this for on-Lightning payments, do note that the 
alternative HTLC construct has to be known by every forwarding node, including 
the direct peer(s) of the light client, which are precisely the potential 
attackers on 

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben,

> >Would this not work?
>
> I considered and rejected that model for the following reason: there are 
> moments where both Alice and Bob can claim the BTC. If they both attempt to 
> do so, it also reveals both secrets, causing the LTC to also be claimable by 
> both parties. This chaotic scenario is a failure mode that did not seem 
> acceptable to me. The revoke transaction was specifically added to mitigate 
> that issue (invalidating any attempt of Bob to claim the coins and reveal his 
> secret). That said, it doesn't particularly seem in either party's interest 
> wait until a moment where two timelocks become valid, so maybe it is not 
> quite as bad as I thought. However, it still means that the 
> incompetence/malevolence of one party can lead to losses for both parties. I 
> have my doubts a gain in privacy in the uncooperative case is worth that risk.
>
> Of course it also reverts the protocol to 3 transactions, instead of 2, but 
> regardless, not having to watch the chain is probably more practical in many 
> cases. As an aside, if both chains support timelocks then we can ensure that 
> the more expensive chain only receives one transaction.

If the shortened refund transaction exists (labeled "refund transaction #1" in 
the SVG) then the same issue still occurs: after 1 day it is possible for 
either success or refund#1 to be broadcasted, leading to revelation of both 
secrets, leading to the same failure mode you described.

Without the refund#1 in your proposal, Bob refusing cooperation after Alice 
puts the BTC into lock for 3 days and 2 further onchain transactions (with the 
refund#2 transaction being relative-locked, meaning it cannot be used to CPFP 
the revoke transaction; my formulation allows any of the result transactions to 
be CPFP directly by their beneficiaries).

It seems to me that there is still an onlineness requirement in case Bob does 
not complete the protocol: once the revoke tx becomes valid an online Bob can 
cheat an offline Alice by broadcasting the revoke tx (which, if my 
understanding of the protocol is correct, the signatures are shared to both 
Alice and Bob).
So Alice needs to be online starting at 2 days to 3 days in order to ensure it 
reclaims it funds.

I have not seen the 2-tx variant video yet, as I prefer to read than listen, 
but I will also check it if I can find an opportunity.

Regardless, the overall protocol of using 3 clauses in the swap, and reusing 
the privkey as the payment secret demanded by the pointlocks, is still a 
significant innovation.



In the context of CoinSwap, a proposal is that a CoinSwap server would provide 
swapping service to incoming clients.
Using my counterproposal, the Bob position can be taken by the server and the 
Alice position taken by the client.
In this context, the L1 can be made reasonably close in the future and L2 far 
in the future, in which case Alice the client can be "weakly offline" most of 
the time until L2, and even in a protocol abort would be able to recover its 
funds.
If the protocol completes, the server Bob can claim its funds before L1, and 
(with knowledge of Alice[0]) can immediately put it in a new funding tx for a 
new incoming client before L1, which is a fine tradeoff for server Bob since 
presumably Bob is always online.

Regards,
ZmnSCPxj


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


Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-11 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben,

> Hi ZmnSCPxj,
>
> Thanks for your feedback :)
>
> > CoinSwap for privacy is practically a "cross" chain atomic swap with the 
> > same chain and token for both sides of the swap
>
> I agree, I didn't mean to imply that was new, only that this protocol
> makes it more efficient.
>

Indeed; basically, any innovations in cross-chain swaps can be adapted to a 
CoinSwap (though not necessarily vice-versa, if a CoinSwap innovation requires 
certain specific blockchain features).

> > "Instead, Bob simply hands secretBob to Alice" is basically the same as 
> > private key turnover
>
> Thanks for the link. I will add it to the links at the bottom of the
> write-up, as I agree it's related. Do note there are a few key
> differences:
>
> -   The swap is set up in an "asymmetric" way with only timelocks on one
> side, so on the other side the swap never expires
>

An interesting setup.

So I was wondering why something like this would not work instead:

0.  Alice has BTC, Bob has LTC, they agree on exchange rates and two future 
timelock L1 and L2 such that L1 < L2.
1.  Alice creates keypairs Alice[0] Alice[1] Alice[2], Bob creates Bob[0] 
Bob[1] Bob[2], and share the pubkeys.
2.  Alice creates, but does not sign, a funding tx on BTC whose output requires 
Alice[0] && Bob[0].
3.  Bob creates a backout transaction spending the BTC funding txo, with an 
absolute timelock L1, whose output goes to Alice[2], then provides to Alice a 
signature for Bob[0] and requires an adaptor such that completing the signature 
with Alice[0] reveals Alice[1].

 nLockTime L1
BTC funding txo ---> Alice[0] && Bob[0]--->  Alice[2]
 reveals Alice[1]

4.  Alice creates a timeout transaction spending the BTC funding txo, with an 
absolute timelock L2, whose output goes to Bob[2], then provides to Bob a 
signature for Alice[0] and requires an adaptor such that completing the 
signature with Bob[0] reveals Bob[1].

 nLockTime L2
BTC funding txo ---> Alice[0] && Bob[0]--->  Bob[2]
 reveals Bob[1]

5.  Alice signs the BTC funding tx and broadcasts it.
6.  Alice and Bob wait for the BTC funding tx to be confirmed.
7.  Bob creates an LTC funding tx whose output requires Alice[1] && Bob[1].
8.  Alice and Bob wait for the LTC funding tx to be confirmed.
9.  Alice creates a success transaction spending the BTC funding txo, with no 
practical absolute timelock (current blockheight + 1), whose output goes to 
Bob[2], then provides to Bob a signature for Alice[0] and requires an adaptor 
such that completing the signature with Bob[0] reveals Bob[1].

 nLockTime now
BTC funding txo ---> Alice[0] && Bob[0]--->  Bob[2]
 reveals Bob[1]

10.  Bob gives the secret key of Bob[1] to Alice.
11.  Alice gives the secret key of Alice[0] to Bob.
12.  Bob claims the BTC funding txo before L1.

Aborts and stalls:

* Aborts before step 5 are safe: no money is ever committed yet.
  Stalls before step 5 can be promoted to aborts.
* If aborted between step 5 and step 8, Alice reclaims her BTC via the backout 
transaction.
  Since Bob did not confirm any locked funds in LTC, revealing Alice[1] does 
not give Bob any extra funds it did not already have.
  If Bob stalls before step 8 Alice can abort at L1 using the backout 
transaction.
* If Alice stalls at step 9, Bob can force the completion using the timeout 
transaction at L2, revealing Bob[1] and claiming the BTC.
* If Alice instead aborts at step 9 using the backout transaction at L1, Bob 
learns Alice[1] and can reclaim its LTC.
* Steps 10 and 11 are optional and "only" give Alice and Bob extra flexibility 
in what they can do with the funds (such as sweeping multiple swaps, RBFing, 
performing another swap, etc.), i.e. private key turnover.
  Bob can always claim the BTC funding txo before L1 by signing and 
broadcasting the success transaction.

Would this not work?
It requires that at least one chain involved supports witness segregation, in 
order to allow signing a dependent transaction before signing what it spends.

This has the advantage of using only absolute timelocks, which are better for 
privacy since ordinary wallets like Bitcoin Core and C-Lightning use absolute 
timelocks for ordinary spends onchain.


>
> Unfortunately this does not hold for the revoke transaction. It would
> be a bit awkward if Alice had a high fee copy after the protocol
> completes. She could send it to the blockchain and essentially Bob
> would be paying for it. I'm not as concerned about the other
> transactions, because those could all be bumped with CPFP if needed,
> but having different feerates would be nice.
>
> And a general comment about privacy: it seems inevitable that some
> information will be leaked if the protocol does not complete
> cooperatively. As long as the cooperative case is not traceable, that
> seems about 

  1   2   3   4   >