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

2017-07-12 Thread ZmnSCPxj via bitcoin-dev
>>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

2017-07-12 Thread ZmnSCPxj via bitcoin-dev
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

2017-07-07 Thread ZmnSCPxj via bitcoin-dev
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

2017-06-30 Thread ZmnSCPxj via bitcoin-dev
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

2017-07-04 Thread ZmnSCPxj via bitcoin-dev
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

2017-06-28 Thread ZmnSCPxj via bitcoin-dev
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)

2017-04-27 Thread ZmnSCPxj via bitcoin-dev
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

2017-05-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Luke, Minor editorial nitpick, this paragraph is repeated, maybe one of these should be Testnet? For Bitcoin '''mainnet''', the BIP8 '''starttime''' will be TBD (Epoch timestamp TBD) and BIP8 '''timeout''' will be TBD (Epoch timestamp TBD). For Bitcoin '''mainnet''', the BIP8

Re: [bitcoin-dev] Rolling UTXO set hashes

2017-05-16 Thread ZmnSCPxj via bitcoin-dev
>On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev ><bitcoin-dev@lists.linuxfoundation.org> wrote: >> transactions is in the header, which would let lite nodes download a UTXO >> set from any full node and verify it by verifying only block headers >> star

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

2017-05-13 Thread ZmnSCPxj via bitcoin-dev
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

2017-05-15 Thread ZmnSCPxj via bitcoin-dev
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

2017-05-15 Thread ZmnSCPxj via bitcoin-dev
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

2017-05-23 Thread ZmnSCPxj via bitcoin-dev
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

2017-05-22 Thread ZmnSCPxj via bitcoin-dev
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

2017-05-22 Thread ZmnSCPxj via bitcoin-dev
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

2017-05-31 Thread ZmnSCPxj via bitcoin-dev
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

2017-05-31 Thread ZmnSCPxj via bitcoin-dev
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)

2017-09-15 Thread ZmnSCPxj via bitcoin-dev
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?

2017-09-15 Thread ZmnSCPxj via bitcoin-dev
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?

2017-09-16 Thread ZmnSCPxj via bitcoin-dev
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

2017-09-22 Thread ZmnSCPxj via bitcoin-dev
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

2017-10-13 Thread ZmnSCPxj via bitcoin-dev
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)

2017-09-05 Thread ZmnSCPxj via bitcoin-dev
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)

2017-09-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Paul, Thank you for your consideration. >> 1. Unifies merge mining (h* commitment) and WT^ validity voting. >> Merge-mined headers increase the vote on a WT^, by increasing the depth >> of the WT^. > >1. I think it is a mistake for SHOM ("Sidechain Headers on Mainchain") >to "unify

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

2017-09-10 Thread ZmnSCPxj via bitcoin-dev
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

2017-09-25 Thread ZmnSCPxj via bitcoin-dev
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

2017-09-26 Thread ZmnSCPxj via bitcoin-dev
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

2017-09-25 Thread ZmnSCPxj via bitcoin-dev
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

2017-09-26 Thread ZmnSCPxj via bitcoin-dev
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

2017-09-25 Thread ZmnSCPxj via bitcoin-dev
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)

2017-09-05 Thread ZmnSCPxj via bitcoin-dev
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)

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

2017-10-12 Thread ZmnSCPxj via bitcoin-dev
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

2017-12-13 Thread ZmnSCPxj via bitcoin-dev
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

2017-11-10 Thread ZmnSCPxj via bitcoin-dev
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

2017-11-08 Thread ZmnSCPxj via bitcoin-dev
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

2017-12-08 Thread ZmnSCPxj via bitcoin-dev
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

2017-12-07 Thread ZmnSCPxj via bitcoin-dev
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

2017-12-07 Thread ZmnSCPxj via bitcoin-dev
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

2017-12-06 Thread ZmnSCPxj via bitcoin-dev
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

2017-12-06 Thread ZmnSCPxj via bitcoin-dev
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?

2018-05-14 Thread ZmnSCPxj via bitcoin-dev
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?

2018-05-08 Thread ZmnSCPxj via bitcoin-dev
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?

2018-05-10 Thread ZmnSCPxj via bitcoin-dev
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?

2018-05-09 Thread ZmnSCPxj via bitcoin-dev
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?

2018-05-10 Thread ZmnSCPxj via bitcoin-dev
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

2018-05-04 Thread ZmnSCPxj via bitcoin-dev
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?

2018-05-17 Thread ZmnSCPxj via bitcoin-dev
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?

2018-05-23 Thread ZmnSCPxj via bitcoin-dev
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

2018-05-01 Thread ZmnSCPxj via bitcoin-dev
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

2018-05-01 Thread ZmnSCPxj via bitcoin-dev
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

2018-07-03 Thread ZmnSCPxj via bitcoin-dev
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)

2018-01-30 Thread ZmnSCPxj via bitcoin-dev
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))

2018-02-04 Thread ZmnSCPxj via bitcoin-dev
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

2018-02-06 Thread ZmnSCPxj via bitcoin-dev
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] BIP0008 clarification

2018-02-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Helder, >Hi, > > I’m trying to understand the process of signalling and activation of updates > in bitcoin. Following BIP34, BIP9, I got into BIP8. > In my understanding of what I read there, an update will be activated even if > the threshold of 95% signalling is not reached in

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

2017-12-26 Thread ZmnSCPxj via bitcoin-dev
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?

2018-06-21 Thread ZmnSCPxj via bitcoin-dev
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?

2018-06-20 Thread ZmnSCPxj via bitcoin-dev
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

2018-07-11 Thread ZmnSCPxj via bitcoin-dev
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

2018-01-22 Thread ZmnSCPxj via bitcoin-dev
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?

2018-03-12 Thread ZmnSCPxj via bitcoin-dev
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?

2018-03-12 Thread ZmnSCPxj via bitcoin-dev
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

2018-04-11 Thread ZmnSCPxj via bitcoin-dev
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

2018-03-21 Thread ZmnSCPxj via bitcoin-dev
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

2018-03-21 Thread ZmnSCPxj via bitcoin-dev
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

2018-10-16 Thread ZmnSCPxj via bitcoin-dev
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

2018-10-17 Thread ZmnSCPxj via bitcoin-dev
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

2018-09-03 Thread ZmnSCPxj via bitcoin-dev
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

2019-01-19 Thread ZmnSCPxj via bitcoin-dev
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

2019-01-19 Thread ZmnSCPxj via bitcoin-dev
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

2019-01-22 Thread ZmnSCPxj via bitcoin-dev
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

2018-12-21 Thread ZmnSCPxj via bitcoin-dev
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

2018-12-23 Thread ZmnSCPxj via bitcoin-dev
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

2018-12-24 Thread ZmnSCPxj via bitcoin-dev
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

2018-12-24 Thread ZmnSCPxj via bitcoin-dev
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)

2018-12-02 Thread ZmnSCPxj via bitcoin-dev
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

2019-01-02 Thread ZmnSCPxj via bitcoin-dev
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

2019-01-24 Thread ZmnSCPxj via bitcoin-dev
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

2019-01-27 Thread ZmnSCPxj via bitcoin-dev
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

2019-04-03 Thread ZmnSCPxj via bitcoin-dev
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

2019-04-04 Thread ZmnSCPxj via bitcoin-dev
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

2019-04-04 Thread ZmnSCPxj via bitcoin-dev
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

2019-04-04 Thread ZmnSCPxj via bitcoin-dev
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

2019-04-05 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-31 Thread ZmnSCPxj via bitcoin-dev
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

2019-04-07 Thread ZmnSCPxj via bitcoin-dev
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

2019-04-08 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-14 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-14 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-11 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-12 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-13 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-18 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-18 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-21 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-22 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-22 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-21 Thread ZmnSCPxj via bitcoin-dev
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

2019-03-20 Thread ZmnSCPxj via bitcoin-dev
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

  1   2   3   >