Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

>>In my scheme, if you read carefully through the pseudocode, a block list node >>is valid only if its block is valid. > >It seems this is a contradiction against the "blind" part of blind merge >mining. How can a bitcoin blockchain node enforce this without tracking the >sidechain? From:

Re: [bitcoin-dev] [BIP Proposal] Standard address format for timelocked funds

Good morning mailinglist, I am saddened at the lack of attention to this BIP proposal. I know that it is not as interesting as the debates on where Bitcoin will go in the future and what needs to be prepared for even greater mainstream adoption, but I think my BIP proposal does have at least

[bitcoin-dev] [BIP Proposal] Standard address format for timelocked funds

BIP: ? Title: Standard address format for timelocked funds Author: ZmnSCPxj Comments-Summary: ? Comments-URI: ? Status: ? Type: ? Created: 2017-07-01 License: CC0-1.0 == Abstract == OP_CHECKLOCKTIMEVERIFY provides a method of locking funds until a particular time

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

Good Morning Paul, >It seems that, in your version, the "bribers" would react to the scheme >in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie >fee per Kb) is low. > >In short, there would be many bribe-attempts (each of which would take >up space in mainchain blocks), almost

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

Good morning Paul, Chris, and CryptAxe, @Paul >> >Your way is actually very similar to mine. Mine _forces_ the bribe to be >> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t >> >do anything to refund the briber, if the sidechain (but not the >> >mainchain) reorganizes (as

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

Good morning. I still do not see what this does that cannot be done by: OP_RETURN A transaction with such an output would allow sidechain-miners to bribe mainchain-miners by paying a transaction fee if the transaction containing this OP_RETURN is included in a block and committed to by a

Re: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners)

Good morning all, As other explained, your scheme is broken. Unless we have a softfork first (OP_CHECKBIP9VERIFY: payment is valid only if a BIP9 proposal is active), it is not possible to create a softfork bounty in a decentralised way On the other hand, hardfork bounty is very simple. You

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

Good morning, >I do not see why any person would want to pay, and then trust, another >to mine accordingly. Each person can mine and attain their level of >influence. This not only avoids the side payment, but earns the person >money. The problem, is that, the rate of conversion of Bitcoin->

Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees

Good morning Luke, Considering the proposal as a whole, I think, it's a little imperfect. The main problem, is that the end goal is activation, but what the opcode rewards is signalling. Consider a miner who signals only if the number of non-signalling blocks in this retargeting time > 5% of

Re: [bitcoin-dev] Rolling UTXO set hashes

Good morning Pieter, >4. Use cases > >* Replacement for Bitcoin Core's gettxoutsetinfo RPC's hash >computation. This currently requires minutes of I/O and CPU, as it >serializes and hashes the entire UTXO set. A rolling set hash would >make this instant, making the whole RPC much more usable for

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Good morning, >> (What happens if the h* to be put in the coinbase, by chance - even very >> unlikely chance - is 0? Then OP_NOP4 is not the same as >> OP_BRIBE scripts in result - the former will be rejected by old nodes, >> the latter will be accepted by new nodes) > >That would

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Good morning Paul, I read only http://www.truthcoin.info/blog/blind-merged-mining/ From just this document, I can't see a good justification for believing that a main->side locking transaction can be safely spent into a side->main unlocking transaction. Do you have a better explanation?

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Good morning, >What you read is only an introduction of BMM. You may also consult the notes >(at the bottom of the BMM post) or the code, although this is time consuming >of course. Looking over the code, I have a question: Is OP_BRIBE supposed to be softforked in, or hardforked? From my

Re: [bitcoin-dev] [Lightning-dev] [RFC] Lightning invoice/payment format draft

Good morning, >Or do I mistake my understanding of bech32? Looking again at bech32 spec, yes, my understanding is wrong: the character "1" is not allowed in the data part, so the last "1" digit in the bech32 string is unambiguously the separator between the human-readable and data parts,

Re: [bitcoin-dev] [Lightning-dev] [RFC] Lightning invoice/payment format draft

Good morning Rusty, The fact that amount is optional, and the separator character between human-readable and data is the character "1", may mean some trouble with parsing of the optional amount. Currently, the version is 0, which translates to the character "q" appearing after "1". So 1q is

[bitcoin-dev] Fw: Re: Sidechain headers on mainchain (unification of drivechains and spv proofs)

Good morning, I'm re-sending this message below as it appears to have gotten lost before it reached cc: bitcoin-dev. Paul even replied to it and the reply reached on-list, so I'm re-sending it as others might have gotten confused about the discussion. So far I've come to realize that

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

Good morning Dan, My understanding is that it is impossible for soft forks to be prevented. 1. Anyone-can-spend There are a very large number of anyone-can-spend scripts, and it would be very impractical to ban them all. For example, the below output script is anyone-can-spend OP_TRUE So

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

Good Morning Dan, No. Let us suppose that IsStandard is applied to outputs, but we support P2SH. Then we could encode those scripts in P2SH. The softfork could require the script preimageto be put elsewhere, such as an OP_RETURN in the same tx, to determine the script that is anyone can

[bitcoin-dev] Sidechains: Mainstake

Good morning bitcoin-dev, I have yet another sidechain proposal: https://zmnscpxj.github.io/sidechain/mainstake/index.html I make the below outlandish claims in the above link: 1. While a 51% mainchain miner theft is still possible, it will take even longer than in drivechains (either months

Re: [bitcoin-dev] New difficulty algorithm part 2

Good morning, >ZmnSCPxj wrote: >> Thus even if the unwanted chain provides 2 tokens as fee per block, >> whereas the wanted chain provides 1 token as fee per block, if the >> unwanted chain tokens are valued at 1/4 the wanted chain tokens, miners >> will still prefer the wanted chain regardless.

Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)

Good morning Chris, >>Basically, in case of a sidechain fork, the mainchain considers the longest >>chain to be valid if it is longer by the SPV proof required length. In the >>above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E) >>longer than the other sidechain fork that

Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs)

Sent with [ProtonMail](https://protonmail.com) Secure Email. > Original Message > Subject: Re: Fwd: [bitcoin-dev] Sidechain headers on mainchain (unification > of drivechains and spv proofs) > Local Time: September 9, 2017 3:33 PM > UTC Time: September 9, 2017 3:33 PM > From:

Re: [bitcoin-dev] idea post: bitcoin side chain implementation

Good morning Patrick, Your idea seems to focus more on scaling than on what sidechains actually were originally considered for. Sidechains were originally designed to add and prototype new features to Bitcoin. Increasing the effective block size is not what sidechains were expected to do.

Re: [bitcoin-dev] Sidechains: Mainstake

Good morning, >>For each sidechain ID, for each mainchain block, at most one sidechain block >>header may be published. In addition, the sidechain block header >published on the mainchain blocks may only be published by the stake lottery >winner from the end of the previous block. > >What

Re: [bitcoin-dev] idea post: bitcoin side chain implementation

Good morning Patrick, >Non official chains suffer from the fact that few if any miners are going to >mine them so they lack security on par with the main chain. That is why most sidechain proposals use some kind of merge mining, where a commitment to another chain's block is published on the

Re: [bitcoin-dev] idea post: trimming and demurrage

Good morning, This is called "UTXO Set Commitments". Pieter Wuille I think had concrete proposals for the cryptographic primitive to use. Try searching "Rolling UTXO Set Commitments". Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. > Original Message

Re: [bitcoin-dev] idea post: trimming and demurrage

Good morning Patrick, Demurrage is simply impossible. In Bitcoin we already have implemented OP_CHECKLOCKTIMEVERIFY. This opcode requires that a certain block height or date has passed before the output can be spent. It can be used to make an "in trust for" address, where you disallow

[bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)

Good morning all, I have started to consider a unification of drivechains, blind merged mining, and sidechain SPV proofs to form yet another solution for sidechains. Briefly, below are the starting assumptions: 1. SPV proofs are a short chain of sidechain block headers. This is used to

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

Good morning Ben, I am not Mark, and I am nowhere near being a true Core developer yet, but I would like to point out that even under a 51% attack, there is a practical limit to the number of blocks that can be orphaned. It would still take years to rewrite history from the Genesis block, for

Re: [bitcoin-dev] New difficulty algorithm part 2

Good morning, >ZmnSCPxj wrote: >> Hodlers have much greater power in hardfork situations than miners > >Not when hodlers are more evenly split between coins. Miners will prefer >the coin with higher transaction fees which will erode hodler confidence >via longer delays. This means transaction

Re: [bitcoin-dev] Two Drivechain BIPs

Good morning Paul, It seems many blocks have a coinbase that pays out to a P2PKH. The public key hash of a potential Accomplice is then readily visible on-chain on the P2PKH of the coinbase. What is more, the potential Accomplice's hashpower can be judged on-chain also: the more blocks pay

[bitcoin-dev] OP_CHECKHARDFORKVERIFY - replay protection and fork futures on off-chain payment channels

Good morning list, I would like to speculate on the addition of an opcode which would provide replay protection and allow chain-backed trustless creation of hardfork futures payment channels. Note however that in order to work, the hardfork must "cooperate" by changing the operation of

Re: [bitcoin-dev] Centralizing mining by force

Good morning Robert, What you describe is precisely one possible result of a 51% attack. At below the 50% threshold, miners outside the cartel will on average outrace miners inside the cartel, so fullnodes which do not follow cartel rules will reject them as per Nakamoto Consensus. At some

Re: [bitcoin-dev] Two Drivechain BIPs

December 7, 2017 4:51 AM UTC Time: December 6, 2017 8:51 PM From: bitcoin-dev@lists.linuxfoundation.org To: bitcoin-dev@lists.linuxfoundation.org On 12/05/2017 08:49 PM, ZmnSCPxj via bitcoin-dev wrote: ... This vulnerability can be fixed if withdrawals are restricted to simple P2PKH or P2WPKH only,

Re: [bitcoin-dev] Two Drivechain BIPs

Good morning Paul and Chris, >I don't agree with the conclusion (that the optimal policy is "always >downvoting", see above), but even if this analysis turns out to be correct, it >isn't a total disaster. The result (which is in the original Nov >2015 specification) is that miners are the ones

Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks

Good morning Damian, >As I understand it, each node would be aware independently of x transactions >waiting for confirmation, the transaction pool. Each long-running node would have a view that is roughly the same as the view of every other long-running node. However, suppose a node, Sleeping

Re: [bitcoin-dev] Two Drivechain BIPs

Good morning Paul and Chris, >3. Collective Action Problem > >There actually is a collective action problem inherent to fraudulent >withdrawals. > >If miners wish to fraudulently withdraw from the sidechain, they need to >choose the destination addresses (on mainchain Bitcoin Core) months in

Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks

Good morning Damian, The primary problem in your proposal, as I understand it, is that the "transaction pool" is never committed to and is not part of consensus currently. It is unlikely that the transaction pool will ever be part of consensus, as putting the transaction pool into consensus

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Luke, > (Maybe it should be the first output > > instead of the last... Is there any legitimate reason one would have multiple > > such dummy outputs?) None, but how about use of `SIGHASH_SINGLE` flag? If a dummy output is added as the first, would it not require adjustment of

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Olauluwa, I believe P2WSH is larger due to the script hash commitment in the `scriptPubKey` as well as the actual script revelation in the `witnessScript`, whereas, a flat OP_TRUE in the `scriptPubKey` is much smaller and can be spent with an empty `scriptSig`. It seems this is

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

Good morning karl and Segue, Specifically for c-lightning, we are not yet rated for pruned bitcoind use, although if you installed and started running bitcoind before installing the lightningd, caught up to the chain, and then installed lightningd and set things up so that bitcoind will get

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Luke and list, > An OP_TRUE-only script with a low value seems like a good example of where the > > weight doesn't reflect the true cost: it uses a UTXO forever, while only > > costing a weight of 4. > > I like Johnson's idea to have some template (perhaps OP_2-only, to preserve

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Luke and list, > > (Aside, in case it wasn't clear on my previous email, the template-script idea > > would not make it mandatory to spend in the same block, but that the UTXO > > would merely cease to be valid after that block. So the 0-value output does > > not take up a UTXO

Re: [bitcoin-dev] BIP sighash_noinput

Good morning Christian, > ZmnSCPxj zmnsc...@protonmail.com writes: > > > It seems to me, that `SIGHASH_NOINPUT` may help make some protocol > > > > integrate better with existing wallets. > > Depends on which end of a transaction the existing wallet is: existing > > wallets will refuse to

Re: [bitcoin-dev] Making OP_TRUE standard?

Good morning Rusty and list, > Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is interesting, > > but if we want a SF just give us SIGHASH_NOINPUT and we'll not need this > > at all (though others still might). We might still want this in general in Lightning; for instance we could

Re: [bitcoin-dev] Should Graftroot be optional?

Good morning Pieter and list, It seems to me, naively, that it would be better to make Graftroot optional, and to somehow combine Taproot and Graftroot. So I propose that the Taproot equation be modified to the below: Q = P + H(P, g, S) * G Where `g` is the "Graftroot flag", i.e. 0 if

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Good morning Jim, > If my understanding is correct though, this construction would significantly > increase the safe CLTV delta requirements because HTLCs cannot be timed out > immediately on the settlement transaction. Consider a case where node B > receives an HTLC from A and forwards to C.

Re: [bitcoin-dev] [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Good morning Christian, This is very interesting indeed! I have started skimming through the paper. I am uncertain if the below text is correct? > Throughout this paper we will use the terms *input script* to refer to > `witnessProgram` and `scriptPubKey`, and *output script* to refer to the

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

Good morning, >The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing >about what the flag actually does. SIGHASH_NOINPUT_REUSE_VULNERABLE? SIGHASH_NOINPUT_VULNERABLE? Regards, ZmnSCPxj___ bitcoin-dev mailing list

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal (Chaofan Li)

Good Morning Chaofan Li, > The human perception of difference will be eliminated. > Will your bank tell you whether your balance means coins or paper money? > If wallets and exchanges only show the total amount of btc rather than btc.0 > and btc.1, there is no human perception difference. This

[bitcoin-dev] RBF Wallet Algorithms (Was: Transaction Merging (bip125 relaxation))

Good Morning Rhavar, I have been trying to conceptualize an algorithm precisely for RBF, and I agree that "tracking the mess" is a significant issue... > Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) > to do "transaction merging" on the fly. Let's say that I owe

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Good morning Greg, I am probably being exceedingly naive, but I would like to compare Taproot to a generalization of funding transactions. For instance, CoinSwapCS: 1. It uses an HTLC in an off-chain transaction, and a funding transaction TX0 whose output is a "simple" 2-of-2. 2. The HTLC

Re: [bitcoin-dev] BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks

Good morning Damian, I see you have modified your proposal to be purely driven by miners, with fullnodes not actually being able to create a strict "yes-or-no" answer as to block validity under your rules. This implies that your rules cannot be enforced and that rational miners will ignore

Re: [bitcoin-dev] Should Graftroot be optional?

Good morning Greg, > On Wed, Jun 20, 2018 at 12:12 PM, ZmnSCPxj via bitcoin-dev > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > This has the advantage that the Graftroot signature commits to a single > > outpoint and cannot be used to spend all outp

Re: [bitcoin-dev] Should Graftroot be optional?

Good morning Pieter and Tim and all, My understanding is that the idea now being discussed by Pieter and Tim is that the Graftroot signature is not `sign(P, script)` but instead `sign(P, sighash(tx))`, where `tx` is an "ordinary" transaction that spends the outpoint that pays to `P`, and a

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

Good morning DING FENG, While your concern is valid, the general intent is the below: 1. We will use a scary name like SIGHASH_NOINPUT_UNSAFE to explicitly inform to wallet and Bitcoin software developers that the flag is potentially unsafe. 2. SIGHASH_NOINPUT_UNSAFE is intended to be used

Re: [bitcoin-dev] Blockchain Voluntary Fork (Split) Proposal

Good morning Chaofan Li, What enforces that bitcoin A is worth the same as bitcoin B? Or are they allowed to eventually diverge in price? If they diverge in price, how is that different from the current situation with Bitcoin, BCash, Bitcoin Gold, Bitcoin Hardfork-of-the-week, and so on?

Re: [bitcoin-dev] Bulletproof CT as basis for election voting?

Good morning again Jose, Another idea is that with sufficiently high stakes (i.e. control of the government of an entire country) it would be possible for a miner-strong The Party to censor transactions that do not give it non-zero amounts of coins. If The Party has a strong enough power over

Re: [bitcoin-dev] Bulletproof CT as basis for election voting?

Good morning Jose, By my understanding, the sender needs to reveal some secrets to the receiver, and the receiver will then know if it received 0 or 1 coin from that sender. (At least from my understanding of MimbleWimble; it might not be the case for CT, but MW is an extension of CT so...)

Re: [bitcoin-dev] Few questions regarding ListTransaction

Good morning Karl-Johan Alm, To clarify: Nothing prevents a miner from completely ignoring nSequence when putting transactions in blocks. Unconfirmed transactions are, by definition, not recorded in blocks. So if there is a transaction 0xFFF nSequence and fee 1000 satoshi, and another

Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation

Good morning aj, I am probably wrong, but could solution 2 be simplified by using the below opcodes for aggregated signatures? OP_ADD_AGG_PUBKEY - Adds a public key for verification of an aggregated signature. OP_CHECK_AGG_SIG[VERIFY] - Check that the gathered public keys matches the

Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation

Good morning aj, ​Sent with ProtonMail Secure Email.​ ‐‐‐ Original Message ‐‐‐ On March 21, 2018 7:21 PM, Anthony Towns wrote: > On Wed, Mar 21, 2018 at 03:53:59AM -0400, ZmnSCPxj wrote: > > > Good morning aj, > > Good evening Zeeman! > > [pulled from the

Re: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

Good morning kim, This seems to be a specific instance of "covenants". I believe, that there are vague plans to possibly include OP_CHECKSIGFROMSTACK, which would allow covenants much more generally, but with more complex (clever) SCRIPT. The specification of the behavior of the opcode is

Re: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

Good morning kim, An issue with covenants is that the only "good" use case so far is vaults. Indeed, what you originally gave as a usecase in your first email is in fact a vault. Here is gmax original bitcointalk post: https://bitcointalk.org/index.php?topic=278122.0 Since covenants

[bitcoin-dev] Reinterpretations of contracts in different pay-to-contract schemes

Good morning all, I am wondering if there is the possibility of an issue arising when different pay-to-contract schemes are used on Bitcoin. Specifically, I wonder, if it may be possible to reinterpret the byte serialization of a contract under one scheme as the byte serialization of a

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

Good Morning Matt, It seems to me that double signing can be punished by requiring that R be a trivial function on the blockheight of the block being signed on the sidechain network. Then a validator who signs multiple versions of history at a particular blockheight reveals their privkey.

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

Good morning Matt, It seems to me much more interesting if the stakes used to weigh voting power are UTXOs on the Bitcoin blockchain. This idea is what I call "mainstake"; rather than a blockchain having its own token that is self-attesting (which is insecure). It seems to me, naively, that the

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

Good Morning Matt, > ### ZmnSCPxj, > > I'm intrigued by this mechanism of using fixed R values to prevent multiple > signatures, but how do we derive the R values in a way where they are unique for each blockheight but still can be used to create signatures or verify? One possibility is to

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Good morning Johnson, > The proposed solution is that an output must be “tagged” for it to be > spendable with NOINPUT, and the “tag” must be made explicitly by the payer. > There are 2 possible ways to do the tagging: First off, this is a very good idea I think. > While this seems fully

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Good morning Johnson, > Generally speaking, I think walletless protocol is needed only when you want > to rely a third party to open a offchain smart contract. It could be > coinswap, eltoo, or anything similar. I think a third party would be pointless in general, but then I am strongly

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

Good morning, > Could anyone propose a better use case of CODESEPARATOR? Long ago, aj sent an email on Lightning-dev about use of CODESEPARATOR to impose Scriptless Script even without Schnorr. It involved 3 signatures with different CODESEPARATOR places, and forced R reuse so that the

Re: [bitcoin-dev] Safer NOINPUT with output tagging

Good morning Johnson, Indeed, manual operation is risky. However the intent is to reduce the requirements on commodity wallets in order to integrate them into a combined onchain and offchain UI. A boutique protocol would reduce the number of existing onchain wallets that could be integrated

Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

Good morning Bob, Would `SIGHASH_SINGLE` work? Commitment transactions have a single input but multiple outputs. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, December 2, 2018 11:08 PM, Bob McElrath wrote: > I've long thought about using

Re: [bitcoin-dev] Create a BIP to implement Confidential Transactions in Bitcoin Core

Good morning SomberNight, > "Bulletproofs ... are computationally binding. An adversary that could > break the discrete logarithm assumption could generate acceptable range > proofs for a value outside the correct range. ... An adversary that can > break the binding property of the commitment

Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains

Good mornint Peter, > > > Wouldn’t a revealed private key for time locked funds create a race > > > to spend? I imagine miners who are paying attention would have the > > > advantage but it would still just be a race. > > > > If Bitcoin had implemented RBF "properly" (i.e. not have the silly > >

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

Good morning Ryan and Adam, > [UIH2 snipped] Perhaps I am being naive, but I seem, the B2EP and similar do not need to worry about UIH2. >From the github discussion: > "UIH2": one input is larger than any output. . I.e. there exists an input, for all outputs, input > output To avoid this, we

[bitcoin-dev] Smart Contracts Unchained

https://zmnscpxj.github.io/bitcoin/unchained.html Smart contracts have traditionally been implemented as part of the consensus rules of some blokchain. Often this means creating a new blockchain, or at least a sidechain to an existing blockchain. This writeup proposes an alternative method

Re: [bitcoin-dev] Smart Contracts Unchained

Good morning Ariel, > However, consider the situation where a group of participants are playing > poker. One participant loses all their funds and decides to present to the > escrow the contract+an old contract state+a signed message following the > contract rules (eg. an independently signed

Re: [bitcoin-dev] Smart Contracts Unchained

to the new contract. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, April 4, 2019 9:55 AM, ZmnSCPxj via bitcoin-dev wrote: > https://zmnscpxj.github.io/bitcoin/unchained.html > > Smart contracts have traditionally been impleme

Re: [bitcoin-dev] Smart Contracts Unchained

Good morning Aymeric, > What if the smart contract platform(s) disappear? > It is still possible to recover the funds, *if* you can convince all participants of some "fair" distribution of the funds. You do this by all participants simply signing with their participant keys and taking the

Re: [bitcoin-dev] Smart Contracts Unchained

of the smart contract. Of course, more choices, more cognitive effort for you mere humans, so probably not a good idea in general. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, April 4, 2019 9:55 AM, ZmnSCPxj via bitcoin-dev wrote: > ht

Re: [bitcoin-dev] Softfork proposal for minimum price of $50k USD/BTC

Hard NAK. A minimum 5 USD : 1 BTC exchange rate implies that the value of 1 USD = 0.2 BTC at maximum. However, such a USD value in BTC value maximum makes no sense since the true value of 1 USD = 0. BTC. (on Lightning, 1 USD = 0.000 BTC) In particular, the encoding

Re: [bitcoin-dev] new BIP: Self balancing between excessively low/high fees and block size

Good morning simondev1, It seems the algorithm would greatly increase validation time. In particular, if the current limit is removed (as in hardforked proposal) then a 1Tb block can be used to attack the network, since sorting would require looking through the entire block. Thus, validation

Re: [bitcoin-dev] Smart Contracts Unchained

Good morning Aymeric, > Hi, > > Apparently you are not a fan of ethereum, as far as I can tell ethereum > sidechains look like a mess with stupid tokens/transactions flooding the > network while they are completely centralized, but some bitcoin > sidechains can easily compete with this too, like

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

Good morning aj, When reading through your original post I saw you mentioned something about output tagging somehow conflicting with Taproot, so I assumed Taproot is not useable in this case. However, it is probably more likely that I simply misunderstood what you said, so if you can

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

Good morning aj, > > Trying to maximise privacy there has the disadvantage that you have to > do a new signature for every in-flight HTLC every time you update the > state, which could be a lot of signatures for very active channels. If I remember accurately this is already true for current

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

Good morning Alistair, > It won't have escaped notice that the HTLB script can be wholly written > in an > HTLC script: 'HTLB over HTLC', however there are additional reasons to > consider HTLB for a separate BIP: I believe there is indeed an important usecase for HTLB over HTLC,

Re: [bitcoin-dev] BIP proposal, Pay to Contract BIP43 Application

Good morning Omar, BIP32 includes this text: > In case parse_256(I_L) >= n or K_i is the point at infinity, the resulting > key is invalid, and one should proceed with the next value for i. This seems to suggest that it is possible for an attacker with sufficient compute power to find two

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

Good morning aj, First off, I have little to no idea of the issues at the lower-level Bitcoin. In any case --- > - alternatively, we could require every script to have a valid signature > that commits to the input. In that case, you could do eltoo with a > script like either: > >

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

Funding Transaction Pattern is how I name it; I am unaware if this pattern has been named before. I know gmax created Taproot precisely as an optimization of this pattern, so I presume he is aware of it, and might know a proper name for such. It is massively ambiguous to call it "gmax technique"

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

Good morning Alistair, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, March 18, 2019 4:27 AM, Alistair Mann via bitcoin-dev wrote: > This update collects community feedback on my HTLB Pre-BIP > > As reminder, I'm suggesting a BIP for a hitherto poorly

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

Good morning aj, > > Then each update transaction pays out to: > > OP_IF > > OP_CSV OP_DROP > > OP_CHECKSIGVERIFY OP_CHECKSIG > > OP_ELSE > > OP_CHECKLOCKTIMEVERIFY OP_DROP > > OP_CHECKSIGVERIFY OP_CHECKSIG > > OP_ENDIF > > Yeah. > > I think we could potentially make that shorter still: > >

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

Good morning aj, I understand. Looks like that makes sense. It seems possible to use this, then, together with watchtowers. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, March 22, 2019 10:58 AM, Anthony Towns wrote: > On Fri, Mar 22, 2019

Re: [bitcoin-dev] Payjoin privacy with the receiver of the transaction

Good morning, > >There's certainly some interesting about the idea of "pre-fragmenting" your > >wallet utxo so you can make (or in payjoin: receive) payments with better > >privacy aspects.However, it's pretty unlikely to be practical for normal > >users, as it'll generally result in pretty

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

Good morning aj, > > If you are committing to the script code, though, then each settlement > sig is already only usable with the corresponding update tx, so you > don't need to roll the keys. But you do need to make it so that the > update sig requires the CLTV; one way to do that is using

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

Hi aj, Re-reading again, I think perhaps I was massively confused by this: > - alternatively, we could require every script to have a valid signature > that commits to the input. In that case, you could do eltoo with a > script like either: > > CHECKSIGVERIFY CHECKSIG > or CHECKSIGVERIFY

Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

Hi all, > Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse > scenario (as well as the second), I'd be content with that proposal. How would this work with watchtowers? As I understand it, the current plan for eltoo watchtowers would be to store both `SIGHASH_NOINPUT`

Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks

Good morning Kenshiro, > - Soft fork: old nodes see CT transactions as "sendtoany" transactions There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an

Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol

Good morning Adam, > And I'm reminded that a related point is made by belcher in the gist > comment thread iirc (after we discussed it on IRC): over time a > "PayJoin-only" merchant doing the simplest thing - using a single utxo > over and over again, will concentrate more and more funds into it,

Re: [bitcoin-dev] Safer NOINPUT with output tagging

8AM +0000, ZmnSCPxj via bitcoin-dev wrote: > > > A boutique protocol would reduce the number of existing onchain wallets > > that could be integrated in such UI. > > Seems like PSBT would be a sufficient protocol: > > 0) lightning node generates a PSBT for a new channel,

  1   2   3   4   5   6   >