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

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 

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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,

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

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

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

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

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

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 =

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [bitcoin-dev] MAD-HTLC

2020-07-01 Thread ZmnSCPxj via bitcoin-dev
g 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., > > > > &g

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

[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

[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

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

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

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 >

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

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

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

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,

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

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

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

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 *

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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 *

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

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

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

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 >

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

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

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

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

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.

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

  1   2   3   4   >