Re: [bitcoin-dev] Ordinal Inscription Size Limits

Onchain capacity is a red herring. There are so many problems with it and we don't need to go into it here if it's already been beaten to death. What we need are the op codes necessary to create a trustless, disconnected graph of layer two solution. We all know that some form of covenant

Re: [bitcoin-dev] Swift Activation - CTV

On Tue, Jan 2, 2024, 8:52 AM Michael Folkson wrote: > In the interests of time I'll just pick two to respond to but I don't > agree with any of your points. > > > Covenants allow trustless utxos sharing and also are needed for > vaulting. The numerous use cases are documented, built out and on

Re: [bitcoin-dev] Ordinal Inscription Size Limits

> > . > > In the USA, where I am, large businesses like UBER, Lyft, and many major > telecom, cable, & electric utilities process huge volumes of regular and > irregular credit card payments on a monthly basis. Almost none oft hose > transactions are completed in bitcoin. > Unfortunately block

Re: [bitcoin-dev] Swift Activation - CTV

reduce that implementation risk in any way, > shape or form. > > Thanks > Michael > > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin > >

Re: [bitcoin-dev] Ordinal Inscription Size Limits

Bitcoin already has a spam prevention system called "fees". I don't believe it's insufficient. The only issue is the stochastic nature of its effectiveness Which can be resolved with things like payment pools, tree payments ( https://utxos.org/uses/scaling/), etc. On Fri, Dec 29, 2023, 9:33

Re: [bitcoin-dev] Swift Activation - CTV

So what exactly are the risks of CTV over multi-sig? > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ossification and misaligned incentive concerns

growing awareness of the > inevitability of the problem that will arise in the future as a result. > And there is slowly growing acceptance of well-thought-out proposals to > fix this situation. > The free market is more important than finite supply. > > > Regards > Jaroslaw

[bitcoin-dev] ossification and misaligned incentive concerns

currently, there are providers of anonymity services, scaling services, custody, and other services layered on top of bitcoin using trust-based and federated models. as bitcoin becomes more popular, these service providers have increasingly had a louder "voice" in development and maintenance of

Re: [bitcoin-dev] Scaling Lightning With Simple Covenants

> > replacing CTV usage with Musig2 > > this changes the trust model to a federated one vs trustless and also increases the on-chain footprint of failure, correct? > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Concern about "Inscriptions"

indeed, i once added a proof-of work requirement to public keys on an open relay server protocol, in additon to posk, in order to make it harder to roll new keys and access the network as a spammer/scammer. not hard to embed anything in a public key, but you can't embed too much, especially if

Re: [bitcoin-dev] Blinded 2-party Musig2

correct. you cannot select R if it is shipped with a POP On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan wrote: > Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of > knowledge of the r values used to generate each R used prevents the Wagner > attack, no? > > On Wed, Jul 26,

Re: [bitcoin-dev] Blinded 2-party Musig2

personally, i think *any* time a public key is transmitted, it should come with a "proof of secret key". it should be baked-in to low level protocols so that people don't accidentally create vulns. alt discussion link: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 On

Re: [bitcoin-dev] Blinded 2-party Musig2

posk is "proof of secret key". so you cannot use wagner to select R On Mon, Jul 24, 2023 at 1:59 PM AdamISZ via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > @ZmnSCPxj: > > yes, Wagner is the attack you were thinking of. > > And yeah, to avoid it, you should have the 3rd round

Re: [bitcoin-dev] Blinded 2-party Musig2

You can't choose R if you provide posk On Mon, Jul 24, 2023 at 10:31 AM Jonas Nick via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Tom, > > I'm not convinced that this works. As far as I know blind musig is still > an open > research problem. What the scheme you propose

Re: [bitcoin-dev] Blinded 2-party Musig2

as long as all parties provide a proof of secret key along with their public key, that should not be possible or you can do it as a two-step process where all parties provide a commitment to the public key and nobody reveals a public key until that commitment is received or if you want to be

Re: [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin

"The sender could store redundant copies of the encrypted transaction data with multiple trust- minimized middlemen, for the recipient to download when they come back online." sounds like a nostr event sent to a half dozen relays On Fri, May 12, 2023, 9:15 AM Robin Linus via bitcoin-dev <

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

i agree 100%. effective communication is challenging, especially in an environment like this. that being said, alicexbt is probably right that we - probably need a well written spec, RFC-style perhaps - need more anon or nym maintainers where the online reputation isn't trivially linked to

Re: [bitcoin-dev] tx max fee

answer seems to be "yes", because you > can always replace a single transaction moving 1 BTC as fees with multiple > transactions, each paying one satoshi per virtual byte, and then instead of > consuming around one kilobyte, it would consume around 1 MvB per 0.01 BTC, > so 100 M

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

> > > > no data at all exactly, which is why a relationship between "cpfp-inclusive outputs" and "fees" makes sense. it's clear that's a good definition of dust, and not too hard to get a working pr up for the network-layer. i get that your node will still route. i get that it would break

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

I would like to point out that I'm not an advocate for doing anything at this point aside from working on l2 just to make it inconvenient for people I just think the discussion of outputs and fees is interesting and related to the game theory portion of Bitcoin On Tue, May 9, 2023, 8:23 AM

Re: [bitcoin-dev] tx max fee

fair. i suppose you could support cpfp in any dust filtering. im not a fan, but I think its the only legit way to defend the chain from non money use cases On Mon, May 8, 2023, 7:58 PM Peter Todd wrote: > On Sun, May 07, 2023 at 07:59:40PM -0400, Erik Aronesty via bitcoin-dev >

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

t? You are impinging on a valid use case as well as >> requiring a consensus rule change. >> >> -- >> Michael Folkson >> Email: michaelfolkson at protonmail.com >> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F >> >> Learn about Bitcoin: https://www.yout

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

ue and attempted >>> Lightning channel closes during fee spikes? If I *want* to close my >>> Lightning channel during a protracted fee spike where I have to pay an >>> onchain transaction fee greater than the amount I am receiving you want to >>> stop me doing that? You are

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

d use case as well as > requiring a consensus rule change. > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin > > --- Original Message

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

probably easier just to reject any transaction where the fee is higher than the sum of the outputs On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi guys, > > I think everyone on this list knows what has happened to the Bitcoin >

[bitcoin-dev] tx max fee

possible to change tx "max fee" to output amounts? seems like the only use case that would support such a tx is spam/dos type stuff that satoshi warned about its not a fix for everything, but it seems could help a bit with certain attacks ___

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

i think the w3c is a very good example of a slow train wreck, and we should do everything possible to avoid the decisions they made On Thu, Apr 20, 2023 at 7:09 AM Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Personnally I will never criticize the maintainers,

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

yes, the code itself was far less contentious than the weird stab at forking the network there remains a real chance that bip 119 is the simplest and most flexible and reasonably safe covenant tech for many use cases although im partial to 118 as well because lightning is a killer app and it

Re: [bitcoin-dev] Refreshed BIP324

you can always do what protocols usually do. 1 byte is fine for now, but reserve the top bit for "this is a two byte id" (128 choices). then when you run out of room, set the top bit which means "this is a 2 byte id (again with one reserved) and so-on. ie: how protobuf stores integers. On

Re: [bitcoin-dev] Ordinal Inscription Size Limits

there are already images encoded in the chain using multisig. when we eliminated the max-witness size in 2017, that made it a bit cheaper, that's all (one tx instead of many) https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html my favorite one is the javascript exploit for

Re: [bitcoin-dev] Ordinal Inscription Size Limits

its trivial to store images in such a way that they look like legit transactions. this was done, in the past, using large numbers of multisig output addresses that encode the images. given the goals of the project, introducing this sort of censorship into bitcoin seems fundamentally undesirable

Re: [bitcoin-dev] Ordinal Inscription Size Limits

my only concern is that as block space gets limited the likelihood of soft fork opcode tech improvement proposals getting accepted by the community goes down schnorr sigs are extremely useful to me (anon, cheap multisig) and some sort of vault tech would be very helpful as well

Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case

> 0-conf on Bitcoin with its understood risks is a significant use case and that use case doesn't change, at all, with full rbf. the risk profile will, likely, remain the same. observation of the fee paid, history of doing business with the customer, transaction size are all needed. On Mon,

Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case

NACK support for 0-conf is harmful for reasons already stated ad nauseum On Wed, Dec 14, 2022 at 4:58 AM Daniel Lipshitz via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A 0-conf double spend caused by FSS-RBF would be harmless since the > original output (address and

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)

> > > > Many zero-conf proponents work on the bleeding edge of supporting > Lightning, including myself. Lightning is not risk-free and the base layer > should not be assuming it as a primary dependency for commercial payments. > for low-value payments, lightning is the only workable version

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

note: if it was possible to enforce this, we wouldn't need proof of work at all. since it isn't possible, proof of work is strictly necessary. On Mon, Dec 5, 2022 at 9:53 AM Rijndael via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning, > > That sounds like a very

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

There has never been any enforcement of miner preferences. The convention is changing quickly, since miners are squeezed for cash and want to capture every nickel, plus there are bounties for full rbf being posted every day. I would suggest considering to continue doing business, as usual, as

Re: [bitcoin-dev] brickchain

> I think it's pretty clear that the "competitive nature of PoW" is not referring to verification nodes cool, so we can agree there is no accepted centralization pressure for validating nodes then > layers also add fees to users source? i feel like it's obvious that the tree-like efficiencies

Re: [bitcoin-dev] brickchain

> A) to not increase the workload of full-nodes yes, this is critical > given the competitive nature of PoW itself validating nodes do not compete with PoW, i think maybe you are not sure of the difference between a miner and a node nodes do validation of transactions, they do this for free,

Re: [bitcoin-dev] On mempool policy consistency

> > > With full-rbf, who saw what transaction first doesn't matter: the higher > fee paying transaction will always(*) replace the lower fee one. With > opt-in RBF, spamming the network can beat out the alternative. > incentivised predictability is critical when designing low level protocols,

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

actually, peter makes an important point here technically, all we need is for *miners* to consistently mine "full rbf" as long as they do, businesses that accept 0conf will have to adjust their risk accordingly, and the problem of misaligned incentives is resolved i don't think it matters what

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

> > (the only way to replace a transaction is Replace-By-Fee but this > implies the transaction that IS TO BE REPLACED has a certain flag set, > and it is optional). > 1. full rbf is becoming standard. tx without full rbf can just be rejected as a part of the sabu protocol 2. that's fine.

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

> Currently Lightning is somewhere around 15% of our total bitcoin payments. This is very much not nothing, and all of us here want Lightning to grow, but I think it warrants a serious discussion on whether we want Lightning adoption to go to 100% by means of disabling on-chain commerce. Is this

Re: [bitcoin-dev] brickchain

> currently, a miner produce blocks with a limited capacity of transactions that ultimately limits the global settlement throughput to a reduced number of tx/s. reduced settlement speed is a desirable feature and isn't something we need to fix the focus should be on layer 2 protocols that allow

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

not sure if this is helpful, but when i'm code reviewing a change to an existing, functioning and very complex system, i rarely go back to "first principles" to analyze that change independently, and instead try to decide if it's better or worse than what we have now you can introduce a new

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

Also, lightning works fine and is readily available in convenient mobile apps used by millions of people, or in . So the need for a 0conf has been mitigated by other solutions for fast payments with no need for a trust relationship. And for people that don't like mobile risks, core lightning

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

1... > Degradation Remember, if hash rate declines (no sign that it will so far), the net-effect is longer clearance times for large transactions. It's not "failure" or "breaking" 2... Certainly, if demand for blockspace isn't high enough to support clearance then the *first *thing to do would

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

you can stop talking about the "security of the system" as meaningful this has been discussed enough if fees are not sufficient, clearance times increase and large stakeholders are incentivised to mine in the best case, fees are sufficient in the worst case, it degrades to proof of stake i'm

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

> I'm pretty sure we will have a textbook case of Prisoner's Dilemma here. no, there is no large payoff for betrayal ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

even with zero block reward and minimal fees, large holders who perform zero transactions will still mine in order to preserve the value of the network this is not "mining your own tx", it is unrelated this is "mining at a small loss to preserve your stake" not only don't we need issuance or

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

> > > subsidy to directly tie miner revenue to the total value of Bitcoin > makes it not exactly how we want to incentivise a service that keeps > > again, this is meaningless. if the fees aren't enough to keep bitcoin secure for large transactions, then large holders are incentivised to mine

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

nstead of trying > to preserve it with corruptible practices outside of market dynamics > principles. > > On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Fees and miner rewards are not needed at all for

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

Fees and miner rewards are not needed at all for security at all since long term holders can simply invest in mining to secure the value of their stake. Isn't it enough that the protocol has a mechanism to secure value? Sure fees *might* be enough. But in the event that they are not, large

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

Bitcoin doesn't rely on fees. It relys on users protecting the network out of self interest - running nodes now - mining later It has always been incentivised by holders acting out of self interest If large holders allocating a small percentage to mining to protect their interest, that's all

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

> > we can expect mining to transition to a public service from the current > for-profit business model > I get it now Game theory would predict all of the major players mining in the future will be large holders If you're holding a hundred Bitcoin you should take one, sell it for mining

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

> > Miners will learn to create anyone-can-spend outputs to bribe other miners > to build on their block rather than reorg it. (Due to the coinbase > maturity, this will require some amount of floating capital.) > (reward + avg fee) * 144 * 365 (one year) == approximate investment needed to

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

> If in the future Bitcoin is entirely dependent on fees for security (scheduled very strongly) and this pattern keeps up (overwhelmingly likely) then this is going to become a serious problem. We should carefully define "when" this becomes an issue. Suppose the reward is 1.5625 BTC. That's

Re: [bitcoin-dev] No Order Mnemonic

Sorry, I totally forgot the checksum. You can take my ops-per-second and multiply it by about 16 (because of the 4 check bits), making a delete + two swaps or 4 swaps, etc. still pretty reasonable. On Mon, Jul 11, 2022 at 9:11 AM Erik Aronesty wrote: > 1. You can swap two positions, and then

Re: [bitcoin-dev] No Order Mnemonic

1. You can swap two positions, and then your recovery algorithm can brute-force the result by trying all 132 possible swaps. 2. You can make a single deletion and only have to brute 2048 3. You can keep doing these, being aware that it becomes geometrically more difficult each time (deletion +

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

> > > Alternatively, losses could be at a predictable rate that's entirely > different to the one Peter assumes. > No, peter only assumes that there *is* a rate. Regardless of what the rate is, if it is any value for which there exists *any fixed central tendency*, tail emission is *evenually*

Re: [bitcoin-dev] Bitcoin covenants are inevitable

On Thu, Jul 7, 2022 at 8:29 PM Eric Voskuil wrote: > Value is subjective, though a constraint of 1tx per 10 minutes seems > unlikey to create a fee of 5000x that of 5000tx. This is of course why I > stated my assumption. Yet this simple example should make clear that at > some point a reduction

Re: [bitcoin-dev] Bitcoin covenants are inevitable

The relationship between block size and fees is not remotely linear. In a restricted environment, the fee rewards are much higher. **the ones moving more sats will win the top spots and will pay as much as is reasonable** Smaller blocks produce better security for the network both in

Re: [bitcoin-dev] Bitcoin covenants are inevitable

> > We should not imbue real technology with magical qualities. > Precisely. It is economic forces (people), not technology, that provide security. Yes, and these forces don't prevent double-spend / 51% attacks if the amounts involved are greater than the incentives. In addition to "utility",

Re: [bitcoin-dev] Bitcoin covenants are inevitable

. > > My thoughts on this are that we will need to periodically make some > software change to adjust a *target amount of investment in security*, > because the > I think perhaps you're underestimating the degree to which utility can be added to the main chain to encourage fees. For example,

Re: [bitcoin-dev] Bitcoin covenants are inevitable

> > Anyway, demurrage and inflation have identical economic properties. They're >> both a tax on savings. The only difference is the way that tax is >> implemented. > > the fact that a conversation on inflation is continuing without being ignored is probably an indicator that the utility of

Re: [bitcoin-dev] Bitcoin covenants are inevitable

On Sun, Jun 19, 2022 at 2:04 PM Manuel Costa via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > if we start seeing issues with block rewards being too low to maintain > acceptable security, we're going to have multiple solutions being > implemented for it, and definitely a hard

Re: [bitcoin-dev] Bitcoin covenants are inevitable

Yes Although I'm guessing most would agree that would be worse. I certainly would choose to add fee generating features over inflation Probably most other people would too On Sat, Jun 11, 2022, 11:36 PM Peter Todd wrote: > On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty

Re: [bitcoin-dev] Bitcoin covenants are inevitable

Maintaining the security of the protocol is squarely the responsibility of the Bitcoin software and the core developers Continued demand for block space is critical for Bitcoin's security. Therefore it *is* the responsibility of Bitcoin software and core developers to maintain a continued demand

[bitcoin-dev] signature abstraction

was thinking it might be possible to create a protocol for signatures where some bounded elliptic curve parameters are in the script, allowing the efficient verification of a broad range of elliptic curves schnorr signatures... rather than a fixed curve has anyone proposed this sort of thing

Re: [bitcoin-dev] Silent Payments – Non-interactive private payments with no on-chain overhead

i like the 00 || X_spend || X_scan + mandate address reuse prevention. might as well start with something strict easy to loosen it later - if needed - harder to tighten it later because of back-compatibility with addresses in-use On Tue, May 24, 2022 at 11:02 AM alicexbt via bitcoin-dev <

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

> > > > FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle > messages and pubkey delegation. The ability to covenants would be > secondary and would mostly serve to get us some real user data about what > sort of covenants users find especially valuable. > I don't think this

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

> > > > Have you taken a look at my proposal > ? > The proposal is, to be clear, *not* "voting" but rather polling that isn't > programmatically connected to activation. The intention is for people > (developers) to

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

There are many challenges with on-chain voting, here are a few: - We may not want votes on-chain, because it creates miner incentives for contentious BIP's to drive up fees - Miners can block votes from the chain - Cold storage votes are probably the most important for certain proposals (like

Re: [bitcoin-dev] What to expect in the next few weeks

> > > I would comment on this point, but I'm not sure I'm "technical enough". I > have to admit: I've never played tennis. > You are technicial enough to read the nacks... everyone is: https://github.com/JeremyRubin/utxos.org/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc I can give a summary

Re: [bitcoin-dev] Speedy Trial

- it occurs to me that the real problem we have isn't whether miners lead or users lead. we know that users lead, we just need miners to be "ready" and have time to upgrade their software - in the case of "evil" forks, i also don't need or want miners to "defend" bitcoin... (if bitcoin is so

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

> > > useful!), using APO-AS covers it. And it's not a couple dozen more virtual > bytes that are going to matter for > a potential vault user. > makes sense that byte-efficiency would be likely less important to vault users vs lightning noninteractive channel users > > the meantime others will

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

On Sat, Apr 23, 2022, 5:05 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > @Zac > > More use cases means more blockchain usage which increases the price of > a transaction for *everyone*. > > This is IMO a ridiculous opposition. Anything that increases the

Re: [bitcoin-dev] Simple step one for quantum

IW, NTRU and NTRU Prime both made it to round 3 > for > the public key encryption/exchange and digital signature categories, but > both of them seem to be mired in some sort of patent controversy atm... > > -- Laolu > > [1]: https://csrc.nist.gov/Projects/post-quantum-cr

[bitcoin-dev] Simple step one for quantum

First step could be just implementing a similar address type (secp26k1+NTRU) and associated validation as a soft fork https://www.openssh.com/releasenotes.html#9.0 Then people can opt-in to quantum safe addresses Still should work with schnorr and other things It's a lot of work to fold this

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

> note how ETH has quite high on chain fees for basic transactions, > because there are so many use-cases where the per-tx value can afford much > higher fees. That kind of expansion of use-case also arguably harms Bitcoin as > a whole by providing more fuel for a future contentious blocksize

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

> As I understand your counterproposal, it would require publishing one transaction per evicted participant. if you also pre-sign (N-2, N-3, etc), you can avoid this > In addition, each participant has to store `N!` possible orderings in which participants can be evicted, as you cannot predict

Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`

hey, i read that whole thing, but i'm confused as to why it's necessary seems like N of N participants can pre-sign an on-chain transfer of funds for each participant to a new address that consists of (N-1) or (N-1) participants, of which each portion of the signature is encrypted for the same

[bitcoin-dev] bip39

really don't like that art, work, and artwork are 3 different words would be nice to clean up adjacent ambiguity it's not a big deal, but it can lead to confusion when writing things down dup: ('canal', 'arm') ('can', 'alarm') dup: ('canal', 'one') ('can', 'alone') dup: ('canal', 'ready')

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

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 blocks where there is an invalid but ignored dust

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

drivechain is a cool proposal. i don't think there's a ton of obvious risk to the network itself (not slow, not too much work for nodes, etc), but it seems to encourage "bad behavior", not sure the incentives line up to prevent thefts, and not sure that won't turn around and bite bitcoin's main

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

Noe: for A. Chow's upgrade to work, there obviously has to be an effort to deliberately-blacklist unupgraded coins, say after 10-20 years of opportunity to upgrade, or something like that, as long as the transition to quantum isn't so fast that there's no way to do this. On Mon, Mar 22, 2021 at

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

you should check out some of the earlier work done here: https://github.com/olalonde/proof-of-solvency#assets-proof to be honest, if any exchange supported that proof, it would be more than enough. there's really no way to prevent a smash-and-grab, but this does prevent a slow-leak On Mon,

Re: [bitcoin-dev] CheckSigFromStack for Arithmetic Values

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 signature components without

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

your protocol should always assume the email system is fully compromised, and only send public information over email: - public keys / addresses are sent - other routing data encrypted with public keys (not sure how data is routed in sabu) your end user should be able to verify public keys /

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

> PoS is not suitable for use as a consensus system, because it is constitutionally incapable of producing a consensus. true - but only for a system that is starting from nothing. since bitcoin already exists, and we have a consensus, you can use bitcoin's existing consensus to maintain that

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

ifferent, conflicting transactions. Nodes will need a way > > to all come to consensus on what the right set of “sent notes” is. > > I think you will end up reinventing a lot of the problems solved by > > bitcoin. > > > > Why did you pick email as the RPC mechan

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

It is vulnerable to sybil attacks or where the recipient is a victim of a proxy attack. If the recipient is not connected to a valid Network, then double spends could be allowed. as long as this protocol is intended for use of transactions around a dollar or so I don't see that being a

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

for very small transactions, this seems to make a hell of a lot of sense. it's like lightning, but with no limits, no routing protocols... everything is guaranteed by relative fees and the cost-of-theft. pretty cool. On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev wrote: > > Hi, > I have

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

> the classical debate with PoS supporters - I explain an attack and they > "patch it", creating problem elsewhere i agree. my original post was: "assume that we can accurately mimic the investment in ASIC's and the expenditure of electricity with "burns" of coin representing that

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

nsibilities on the holder to > > > > > > > > > > maintain the quality of all the other bars of gold out > > > > > > > > > > there. > > > > > > > > > > Bitcoin feels like this too and in many ways is more i

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

> > For Bitcoin to succeed I think we need to keep it that way and >>>> >> >> > Proof-of-Stake makes everything a bit too exciting. >>>> >> >> > >>>> >> >> > I suppose in the end the market will decide what

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

and bias against Proof of >>> >> >> >> Stake. Yes there have been lots of shady coins that use insecure >>> >> >> >> PoS mechanisms. Yes there have been massive issues with >>> >> >> >> distribution of PoS coins (of course there have

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

act have clear centralization >> >> >> pressure - this is not disputed. Our goal in relation to that is to >> >> >> ensure that the centralization pressure remains insignifiant. Proof of >> >> >> work also clearly has a lot more barriers to entry than

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

> > I don't think 99% of transactions need that level of security > Well you can't get security for the 1% of transactions that need it without > giving that security to all transactions on the chain. Also, the blockchain > security created by miners isn't really a per transaction thing

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

ause as the attacker accumulates hashpower, it >> >> drives honest miners out of the market as the difficulty increases to >> >> beyond what is economically sustainable. Also, its been shown that the >> >> best proof of work can do is require an attacker to obtain 3

  1   2   3   >