Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-16 Thread ZmnSCPxj via bitcoin-dev
Good morning vjudeu, > > What happens if a series of blocks has a timestamp of 0x at the > > appropriate time? > > The chain will halt for all old clients, because there is no 32-bit value > greater than 0x. > > > 1. Is not violated, since "not lower than" means "greater than

Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

2021-10-15 Thread ZmnSCPxj via bitcoin-dev
Good morning yanmaani, > It's well-known. Nobody really cares, because it's so far off. Not > possible to do by softfork, no. I think it is possible by softfork if we try hard enough? > 1. The block timestamp may not be lower than the median of the last 11 > blocks' > > 2. The block

Re: [bitcoin-dev] On the regularity of soft forks

2021-10-11 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > This also has strong precedent in other important technical bodies, e.g. from  > https://datatracker.ietf.org/doc/html/rfc7282 On Consensus and Humming in the > IETF. > > Even worse is the "horse-trading" sort of compromise: "I object to >    your proposal for

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-10-08 Thread ZmnSCPxj via bitcoin-dev
Good morning Pieter, > Indeed - UTXO set size is an externality that unfortunately Bitcoin's > consensus rules fail to account > for. Having a relay policy that avoids at the very least economically > irrational behavior makes > perfect sense to me. > > It's also not obvious how consensus rules

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-10-08 Thread ZmnSCPxj via bitcoin-dev
Good morning shymaa, > The suggested idea I was replying to is to make all dust TXs invalid by some > nodes. Is this supposed to be consensus change or not? Why "some" nodes and not all? I think the important bit is for full nodes. Non-full-nodes already work at reduced security; what is

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-10-07 Thread ZmnSCPxj via bitcoin-dev
Good morning shymaa > If u allow me to discuss,,, > I previously suggested storing dust UTXOS in a separate Merkle tree or > strucutre in general if we are talking about the original set. > I'm a kind of person who doesn't like to throw any thing; if it's not needed > now keep it in the

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-10-06 Thread ZmnSCPxj via bitcoin-dev
Good morning e, > mostly thinking out loud > > suppose there is a "lightweight" node: > > 1. ignores utxo's below the dust limit > 2. doesn't validate dust tx > 3. still validates POW, other tx, etc. > > these nodes could possibly get forked - accepting a series of valid, > mined

Re: [bitcoin-dev] Question- must every mining rig attempt every block?

2021-10-05 Thread ZmnSCPxj via bitcoin-dev
Good morning Nathan, > For purposes of conserving energy, couldn't each mining rig have some > non-gameable attribute which would be used to calculate if a block would > be accepted by that rig? > > Don't the mining rigs have to be able to identify themselves to the > network somehow, in order to

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

2021-10-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Luke, > All attempts are harmful, no matter the intent, in that they waste > contributors' time that could be better spent on actual development. > > However, I do also see the value in studying and improving the review process > to harden it against such inevitable attacks. The

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

2021-10-01 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, I think this is still good to do, controversial or no, but then I am permanently under a pseudonym anyway, for what that is worth. > Few questions for everyone reading this email: > > 1.What is better for Security? Trusting authors and their claims in PRs or a > good

Re: [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation)

2021-09-29 Thread ZmnSCPxj via bitcoin-dev
Good morning trilemabtc, > Hash: SHA256 > > In search of more freedom, I thought of a hardwallet that makes the funds > unseizable, using proof of creation (another step with key file), only the > creator can reveal the private keys, more details about the idea can be found > in the directory:

Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects

2021-09-27 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, > Good morning Bitcoin devs, > > In one of the answers on Bitcoin Stackexchange it was mentioned that some > companies may hire you to introduce backdoors in Bitcoin Core: > https://bitcoin.stackexchange.com/a/108016/ > > While this looked crazy when I first read it, I

Re: [bitcoin-dev] [Lightning-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

2021-09-20 Thread ZmnSCPxj via bitcoin-dev
Good morning John Law, > (at the expense of requiring an on-chain transaction to update > the set of channels created by the factory). Hmmm this kind of loses the point of a factory? By my understanding, the point is that the set of channels can be changed *without* an onchain transaction.

Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

2021-09-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Filippo, > Hi! > > From the proposal it is not clear why a miner must reference other miners' > shares in his shares. > What I mean is that there is a huge incentive for a rogue miner to not > reference any share from > other miner so he won't share the reward with anyone, but it

Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool

2021-09-07 Thread ZmnSCPxj via bitcoin-dev
Good morning all, A thing I just realized about Braidpool is that the payout server is still a single central point-of-failure. Although the paper claims to use Tor hidden service to protect against DDoS attacks, its centrality still cannot protect against sheer accident. What happens if some

Re: [bitcoin-dev] Drivechain: BIP 300 and 301

2021-09-07 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, > Thanks for sharing all the details. One thing that I am not sure about: > > > * We already ***know*** that blockchains cannot scale > > * Your plan for scaling is to make ***more*** blockchains? > > Scaling Bitcoin can be different from scaling Bitcoin sidechains. You can

Re: [bitcoin-dev] Drivechain: BIP 300 and 301

2021-09-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, Just to be clear, neither Liquid nor RSK, as of my current knowledge, are Drivechain systems. Instead, they are both federated sidechains. The money owned by a federated sidechain is, as far s the Bitcoin blockchain is concerned, really owned by the federation that.runs

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

2021-08-31 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac, > Hi ZmnSCPxj, > > Thank you for your helpful response. We're on the same page concerning > privacy so I'll focus on that. I understand from your mail that privacy would > be reduced by this proposal because: > > * It requires the introduction of a new type of transaction that

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

2021-08-31 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac, > Perhaps you could help me understand what would be required to implement the > *unmodified* proposal. That way, the community will be able to better assess > the cost (in terms of effort and risk) and weigh it against the perceived > benefits. Perhaps *then* we find that

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-20 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > one interesting point that came up at the bitdevs in austin today that favors > remove that i believe is new to this discussion (it was new to me): > > the argument can be reduced to: > > - dust limit is a per-node relay policy. > - it is rational for miners to mine dust

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

2021-08-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac, > Thank you for your counterproposal. I fully agree that as a first step we > must establish whether the proposed functionality can be implemented without > making any changes to consensus. > > Your counterproposal is understandably more technical in nature because it >

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

2021-08-16 Thread ZmnSCPxj via bitcoin-dev
Good morning TS, > Entering a BTC address for a transaction can pose a risk of error (human or > technical). While > there is a checksum integrated in BTC addresses already, this is used only at > a technical > level and does not avoid entering a valid but otherwise wrong address. > Moreover,

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

2021-08-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac, > Hi ZmnSCPxj, > > Thank you for your insightful response. > > Perhaps I should take a step back and take a strictly functional angle. > Perhaps the list could help me to establish whether the proposed > functionality is: > > Desirable; > Not already possible; > Feasible to

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-10 Thread ZmnSCPxj via bitcoin-dev
Good morning all, Thinking a little more, if the dust limit is intended to help keep UTXO sets down, then on the LN side, this could be achieved as well by using channel factories (including "one-shot" factories which do not allow changing the topology of the subgraph inside the factory, but

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-08-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Billy, et al., > For sure, CT can be done with computational soundness. The advantage of > unhidden amounts (as with current bitcoin) is that you get unconditional > soundness. My understanding is that it should be possible to have unconditional soundness with the use of El-Gamal

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

2021-08-09 Thread ZmnSCPxj via bitcoin-dev
fromGood morning Zac, With some work, what you want can be implemented, to some extent, today, without changes to consensus. The point you want, I believe, is to have two sets of keys: * A long-term-storage keyset, in "cold" storage. * A short-term-spending keyset, in "warm" storage,

Re: [bitcoin-dev] Proof of reserves - recording

2021-07-09 Thread ZmnSCPxj via bitcoin-dev
Good morning e, Okay, it seems to me that what you are saying is something like this: > Proof-of-reserves would (partially) work for a "pure" warehousing service > (i.e. user pays some fee, service keeps money and provides proofs that money > is kept). > However, "pure" warehousing is not what

Re: [bitcoin-dev] Proof of reserves - recording

2021-07-09 Thread ZmnSCPxj via bitcoin-dev
Good morning e, > Any expectation of interest implies borrowing, in other words, a loan to > the bank. Perhaps this is the key point of contention? In cases where Bitcoin is given over to an exchange, there is no expectation of interest, at least in the sense that there is no expectation

Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

2021-07-09 Thread ZmnSCPxj via bitcoin-dev
ers to), Merkle not so much. Regards, ZmnSCPxj > On Thu, Jul 8, 2021 at 4:12 AM ZmnSCPxj via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Good morning Jeremy, > > Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple > > kilobytes)...

Re: [bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]

2021-07-08 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple kilobytes)... blocksize increase *cough* Since a quantum computer can derive the EC privkey from the EC pubkey and this scheme is resistant to that, I think you can use a single well-known EC

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-06 Thread ZmnSCPxj via bitcoin-dev
Good morning Russell, > Hi ZmnSCPxj, > > I don't believe we need to ban Turing completeness for the sake of banning > Turing completeness. Well I believe we should ban partial Turing-completeness, but allow total Turing-completeness. I just think that unlimited recursive covenants (with or

Re: [bitcoin-dev] Proof of reserves - recording

2021-07-05 Thread ZmnSCPxj via bitcoin-dev
it only proves that the funds were owned under a particular key > > at some snapshot of the past, it does not prove that the key will not get > > lost (or "lost and then salvaged by a scuba diver") later. > > > > Regards, > > ZmnSCPxj > > > > &

Re: [bitcoin-dev] Proof of reserves - recording

2021-07-05 Thread ZmnSCPxj via bitcoin-dev
key will not get lost (or "lost and then salvaged by a scuba diver") later. Regards, ZmnSCPxj > > e > > > On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev > > bitcoin-dev@lists.linuxfoundation.org wrote: > > Good morning Billy, > > > > > I wonder if

Re: [bitcoin-dev] Proof of reserves - recording

2021-07-05 Thread ZmnSCPxj via bitcoin-dev
Good morning Billy, > I wonder if there would be some way to include the ability to prove balances > held on the lightning network, but I suspect that isn't generally possible.  Thinking about this in terms of economic logic: Every channel is anchored onchain, and that anchor (the funding

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Russell, > On Sun, Jul 4, 2021 at 9:02 PM Russell O'Connor > wrote: > > > Bear in mind that when people are talking about enabling covenants, we are > > talking about whether OP_CAT should be allowed or not. > > > > That said, recursive covenants, the type that are most worrying,

Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

2021-07-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Dave, > On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote: > > > However, I think the broader community is unconvinced by the cost benefit > > of arbitrary covenants. See > > https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6 > > as a

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

2021-07-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Erik and Jeremy, > The "for" arithmetic here is largely to mean that this cleverness allows an > implementation of `OP_CHECKSIGFROMSTACK`, using arithmetic operation `OP_ADD`. > > To my mind this cleverness is more of an argument against ever enabling > `OP_ADD` and friends, LOL. >

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

2021-07-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Erik, > i may be ignorant here but i have a question: > > Given that schnorr signatures now allow signers to perform complex arithmetic > signing operations out-of-band using their own communications techniques, > couldn't you just perform the publishing and accumulation of these

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

2021-07-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, > Dear Bitcoin Devs, > > It recently occurred to me that it's possible to do a lamport signature in > script for arithmetic values by using a binary expanded representation. There > are some applications that might benefit from this and I don't recall seeing > it discussed

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-29 Thread ZmnSCPxj via bitcoin-dev
Good morning Raymo, > Hey Alex, > > Your scenario works perfectly unless we put some restrictions on > accepting transaction by creditor (in our case Bob). > These are restrictions: > Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as > transaction input. > Alice has to reserve

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-28 Thread ZmnSCPxj via bitcoin-dev
Good morning Raymo, > Hi ZmnSCPxj, > > Why you get the signal “trust the Gazin wallet”? > Sabu is a protocol and the Gazin wallet will be an implementation of > that protocol. We will implement it in react-native language to support > both Android and iPhone. Of course it will be open source and

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-27 Thread ZmnSCPxj via bitcoin-dev
Good morning Raymo, > > It looks you already missed the entire design of Sabu and its > restrictions. First of all, the Gazin wallet always controls the Sabu > restrictions for every transaction in order to consider it as a valid > transaction in a valid deal. That is, the creditor wallet

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-26 Thread ZmnSCPxj via bitcoin-dev
Good morning Raymo, > Good morning ZmnSCPxj > Sorry for late reply. > > > Guarantee Transactions (GT) being higher-fee is not assured. > > The question is “assuring what?”. > The whole point of my proposal is the fact that issuers and creditors > act rationally and won't harm their selves. The

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

2021-06-19 Thread ZmnSCPxj via bitcoin-dev
Good morning Raymo, > Hi, > I have a proposal for improve Bitcoin TPS and privacy, here is the post. > https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180 > https://bitcointalk.org/index.php?topic=5344020.0 > Can you please

Re: [bitcoin-dev] Consensus protocol immutability is a feature

2021-05-23 Thread ZmnSCPxj via bitcoin-dev
t * `nonce`: 4 bytes, random number with no other meaning. What do you refer to? Because the above block header format is hashed to generate the `prevBlockHash` for the *next* block, it is almost impossible to change the format without a hardfork. Regaards, ZmnSCPxj > > On 2

Re: [bitcoin-dev] Reducing block reward via soft fork

2021-05-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Karl, > On 5/23/21, ZmnSCPxj via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Good morning James, > > > > > Background > > > > > > === > > > > > > Reducing the block reward reduces the inc

Re: [bitcoin-dev] Reducing block reward via soft fork

2021-05-23 Thread ZmnSCPxj via bitcoin-dev
Good morning James, > Background > === > Reducing the block reward reduces the incentive to mine. It reduces the > maximum energy price at which mining is profitable, reducing the energy use. > If people want to retain previous levels of security, they can offer to pay higher fees, which

Re: [bitcoin-dev] Consensus protocol immutability is a feature

2021-05-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Jorge, et al, > Hardforks can be useful too. > But, yes, I agree softforks are preferable whenever possible. I think in principle the space of possible softforks is very much wider than can be trivially expected. For instance, maaku7 once proposed a softfork that could potentially

Re: [bitcoin-dev] Fee estimates and RBF

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, > But it will involve lot of exception handling. Yes, that is precisely the problem here. If you select a fixed feerate and then just broadcast-and-forget, you have no real exceptions you have to handle --- but that means not using RBF at all. Testing the handling of

Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Michael, > Good morning Michael, > > > Nothing in a dynamic system like PoW mining can be 100% anticipated, for > > example there might be advanced in manufacturing of chips which are > > patented and so on. > > It sounds like your take is that this means no improvements can ever

Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Michael, > Nothing in a dynamic system like PoW mining can be 100% anticipated, for > example there might be advanced in manufacturing of chips which are patented > and so on.  > > It sounds like your take is that this means no improvements can ever be made > by any mechanism,

Re: [bitcoin-dev] Prediction Markets and Bitcoin

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, > > > Of course the people ultimately funding the development must impose what > >direction that development goes to, after all, it is their money that is > >being modified. Thus development must follow the market. > > Disagree.  > > 1.A position in a futures market about

Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Michael, > That’s interesting. I didn’t know the history of ASICBOOST. History is immaterial, what is important is the technical description of ASICBOOST. Basically, by fixing the partial computation of the second block of SHA256, we could selectively vary bits in the first block

Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Michael, > That’s a fair point about patents. However, note that we were careful about > this. oPoW only uses SHA3 (can be replaced with SHA256 in principle as well) > and low precision linear matrix multiplication. A whole industry is trying to > accelerate 8-bit linear matrix

Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning devrandom, > On Mon, May 17, 2021 at 11:47 PM ZmnSCPxj: > > > When considering any new proof-of-foo, it is best to consider all effects > > until you reach the base physics of the arrow of time, at which point you > > will realize it is ultimately just another proof-of-work anyway.

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac, > VDFs might enable more constant block times, for instance by having a > two-step PoW: > > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to > difficulty adjustments similar to the as-is). As per the property of VDFs, > miners are able show proof of

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Michael, > Am 17.05.2021 um 04:58 schrieb Luke Dashjr: > > > It increases security, and is unavoidable anyway. > > You can't. > > There must be a way. dRNG + universal clock + cryptographical magic?! Proof-of-work **is** the cryptographic magic that creates a universal clock. In

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Anton, > >> 4. My counter-proposal to the community to address energy consumption > >> problems would be *to encourage users to allow only 'green miners' > >> process>> their transaction.* In particular: > >>... > >> (b) Should there be some non-profit organization(s) certifying

Re: [bitcoin-dev] Opinion on proof of stake in future

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
Good morning Erik, > Verifiable Delay Functions involve active participation of a single > verifier. Without this a VDF decays into a proof-of-work (multiple > verifiers === parallelism). > > The verifier, in this case is "the bitcoin network" taken as a whole. > I think it is reasonable to

Re: [bitcoin-dev] Proposal: Low Energy Bitcoin PoW

2021-05-18 Thread ZmnSCPxj via bitcoin-dev
> A few things jump out at me as I read this proposal > > First, deriving the hardness from capex as opposed to opex switches the > privilege from those who have cheap electricity to those who have access to > chip manufacturers/foundries. While this is similarly the case for Bitcoin > ASICS

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

2021-05-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, > Hi Yanmaani, > > >Merged mining at present only needs one hash for a merkle root, and that's > >stored in the coinbase. > > Yes, but that method is not "blind", meaning BTC miners have to validate the > merged-mined chain, which is a significant downside. > > >It would be

Re: [bitcoin-dev] Fee estimates and RBF

2021-05-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, I believe a "true" full-RBF wallet should be what every onchain wallet aspires to. However, I think a lot of the effort necessary here has to do with sheer engineering issues. For example, if you think "RBF does not exist", you can do things like: * Spend an unconfirmed

Re: [bitcoin-dev] maximum block height on transaction

2021-05-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Billy, and list, > - Using an opcode would greatly increase CPU usage because the script cache > would need to be reworked (and probably cannot be made to work). > - Adding a field would greatly increase the code complexity to the level of > SegWit, without all the important

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

2021-04-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Christopher, > >> But more importantly, adding limitations on OP_RETURN transactions is not > >> helpful.  Users who want to embed arbitrary data in their transactions can > >> always do so by encoding their data inside the values of legacy > >> multi-signature scriptpubkeys

Re: [bitcoin-dev] Designing Bitcoin Smart Contracts with Sapio (available on Mainnet today)

2021-04-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, et al., > Bitcoin Developers, > > I'm very excited to introduce Sapio[0] formally to you all. This seems quite interesting to me as well! I broadly agree with the rant on monetary units. In C-Lightning we always (except for some legacy fields that will eventually be

Re: [bitcoin-dev] maximum block height on transaction

2021-04-15 Thread ZmnSCPxj via bitcoin-dev
Good morning Billy, > I've come across this argument before, and it seems kind of like Satoshi's > word here is held as gospel. I haven't heard any deep discussion of this > topic, and I even asked a question on the bitcoin SE about it. Sorry to > hijack this conversation, but I'm very

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-04-15 Thread ZmnSCPxj via bitcoin-dev
Good morning LL, > On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev > wrote: > > > I curious about whether anyone informed about ECC and QC > > knows how to create output scripts with lower difficulty that could be > > used to measure the progress of QC-based EC key cracking. 

Re: [bitcoin-dev] Prediction Markets and Bitcoin

2021-04-15 Thread ZmnSCPxj via bitcoin-dev
Good morning Prayank, > I think prediction markets or such tokens might help in adding to the > information we already have however they don't decide or replace anything. > Bitcoin development should impact such markets and not the other way around.  "Human behavior is economic behavior. The

Re: [bitcoin-dev] Taproot NACK

2021-03-17 Thread ZmnSCPxj via bitcoin-dev
Good morning, > Good afternoon, > > That is not desirable since yourself and I cannot prove the property of the > UTXO when it is further spent unless we can ourselves scrutinize it. What property *needs* to be proven in the first place? I suspect you are riding too much on your preferences

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

2021-03-17 Thread ZmnSCPxj via bitcoin-dev
Good morning Andrew, > I wouldn't fully discount general purpose hardware or hardware outside of the > realm of ASICS. BOINC (https://cds.cern.ch/record/800111/files/p1099.pdf) > implements a decent distributed computing protocol (granted it isn't a > cryptocurrency), but it far computes data

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

2021-03-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Andrew, Looking over the text... > # I am looking towards integrating memory hard compatibility w/ the mining > algorithm. Memory hard computation allows for time and space complexity for > data storage functionality, and there is a way this can likely be implemented > without

Re: [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections)

2021-03-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Andrew and Andrea, Further afield: https://en.bitcoin.it/wiki/Taproot_Uses Taproot ring signatures was also asked by Andrea, above page contains this link (have not actually read it myself): https://github.com/jonasnick/taproot-ringsig Regards, ZmnSCPxj

Re: [bitcoin-dev] Taproot NACK

2021-03-16 Thread ZmnSCPxj via bitcoin-dev
> It's incredible how this troll keeps trolling and the list (bitcoin-dev !!) > keeping attention > > Good troll, really Depending on topic raised, it may be useful to at least answer the troll naively as if it were an honest question, if only so that third parties reading do not get

Re: [bitcoin-dev] Taproot NACK

2021-03-16 Thread ZmnSCPxj via bitcoin-dev
Good morning JAMES, > Good Afternoon, > > Verifiable and independantly verifiable are not the same. Independantly > scrutinable means any public can scrutinise blockchain to determine it > is honest. It does not rely on involved parties but insistently on the > data published in the blockchain.

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

2021-03-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, Thank you. Assuming only keys, an easier way of delegating would be simply to give a copy of the privkey outright to the delegatee. However, an advantage of this technique you described is that the delegator can impose additional restrictions that are programmable via any

Re: [bitcoin-dev] Delegated signatures in Bitcoin within existing rules, no fork required

2021-03-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Jeremy, This is a very cool idea! > Multiple Delegates: By signing a txn with several delegate outputs, it is > possible to enforce multiple disparate conditions. Normally this is > superfluous -- why not just concatenate S1 and S2? The answer is that you may > have S1 require a

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

2021-03-15 Thread ZmnSCPxj via bitcoin-dev
Good morning aj, > On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev > wrote: > > > It may initially take months to break a single key. > > From what I understand, the constraint on using quantum techniques to > break an ECC key is on the number of bits you can entangle

Re: [bitcoin-dev] Taproot NACK

2021-03-15 Thread ZmnSCPxj via bitcoin-dev
Good morning JAMES, > No-one has yet demonstrated that Conjoin or using Wasabi wallet is secure if > it relies on third-parties. Are the transaction not forwarded partially > signed as with an SPV wallet? So it is possible the SPV server cannot > redirect funds if dishonest? SPV wallets are

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-19 Thread ZmnSCPxj via bitcoin-dev
Good morning list, > It was pointed out to me that this discussion is largely moot as the software > complexity for Bitcoin Core to ship an > option like this is likely not practical/what people would wish to see. > > Bitcoin Core does not have infrastructure to handle switching consensus rules

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-19 Thread ZmnSCPxj via bitcoin-dev
Good morning list, > This is absolutely the case, however note that the activation method itself > is consensus code which executes as a part > of a fork, and one which deserves as much scrutiny as anything else. While > taproot is a model of how a soft-fork should > be designed, this doesn't

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

2021-02-18 Thread ZmnSCPxj via bitcoin-dev
Good morning all, > "An activation mechanism is a consensus change like any other change, can be > contentious like any other change, and we must resolve it like any other > change. Otherwise we risk arriving at the darkest timeline." > > Who's we here? > > Release both and let the network

Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

2021-02-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Luke, > > Another point to ponder is test modes. > > In mass production you need test modes. > > > (Sure, an attacker can try targeted ESD at the `TESTMODE` flip-flop > > repeatedly, but this risks also flipping other scan flip-flops that contain > > the data that is being

Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

2021-02-12 Thread ZmnSCPxj via bitcoin-dev
Good morning Luke, Another thing we can do with scan mode would be something like the below masking: input CLK, RESET_N; input TESTMODE; input SCANOUT_INTERNAL; output SCANOUT_PAD; reg gating; wire n_gating = gating && TESTMODE; always_ff @(posedge CLK, negedge

Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

2021-02-11 Thread ZmnSCPxj via bitcoin-dev
Good morning Luke, > > (to be fair, there were tools to force you to improve coverage by injecting > > faults to your RTL, e.g. it would virtually flip an `&&` to an `||` and if > > none of your tests signaled an error it would complain that your test > > coverage sucked.) > > nice! It

Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

2021-02-02 Thread ZmnSCPxj via bitcoin-dev
Good morning again Luke, > [my personal favourite is a focus on power-efficiency: battery-operated > hand-held devices at or below 3.5 watts (thus not requiring thermal pipes or > fans - which tend to break). i have to admit i am a little alarmed at the > world-wide energy consumption of

Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

2021-02-02 Thread ZmnSCPxj via bitcoin-dev
Good morning Luke, I happen to have experience designing digital ASICs, mostly pipelined data processing. However my experience is limited to larger geometries and in SystemVerilog. On the technical side, as I understand it (I have been out of that industry for 4 years now, so my knowledge may

Re: [bitcoin-dev] Hardware wallets and "advanced" Bitcoin features

2021-01-14 Thread ZmnSCPxj via bitcoin-dev
Good Morning Kevin, > Inputs (mainly for pre-signed Tx): > == > Problem: Poisoned inputs are a major risk for HW as they don't know the > UTXO set. While this can be exploited for fee > attacks, it is a bigger threat to pre-signed transactions

Re: [bitcoin-dev] Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs

2020-12-31 Thread ZmnSCPxj via bitcoin-dev
Good morning Ruben, and list, First and foremost --- what is the point of sidechains, in the first place? If sidechains are for experimental new features, then softforking in a new sidechain with novel untested new features would be additionally risky --- as you note, a bug in the sidechain

Re: [bitcoin-dev] Out-of-band transaction fees

2020-12-01 Thread ZmnSCPxj via bitcoin-dev
Good morning e, and Sebastian, So it seems, the goals are the below: * Someone wants to pay a fee to get a transaction confirmed. * Miners want to know how much they earn if they confirm a transaction. * The one paying for the fee does not want to link its other coins to the transaction it

Re: [bitcoin-dev] Out-of-band transaction fees

2020-12-01 Thread ZmnSCPxj via bitcoin-dev
Good morning Sebastian and e, > Hi Eric, > > > In paying fees externally one must find another way to associate a fee with > > its transaction. This of course increases the possibility of taint, as you > > describe in part here: > > I'm not sure I follow, do you see a problem beyond the facts

Re: [bitcoin-dev] CoinPools based on m-of-n Schnorr aggregated signatures

2020-11-15 Thread ZmnSCPxj via bitcoin-dev
Good morning Sridhar, My understanding is that it is still possible to generate an m-of-n aggregated pubkey, it "just" requires an interactive setup (i.e. all n signers have to talk to each other and send data a few times to each other) and they have to keep extra data around in order to "sign

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

  1   2   3   4   5   >