Re: [bitcoin-dev] tx max fee

On 5/11/23 04:02, vjudeu via bitcoin-dev wrote: Every transaction paying "fee > sum" can be replaced by N transactions paying "fee <= sum", where the sum of all fees will be the same. These N transactions will generally have a lower feerate than the original, and the lowest feerate of the N c

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

On 5/9/23 09:32, Erik Aronesty via bitcoin-dev wrote: obviously it's easy enough to evade if every non-economic user simply > keeps enough bitcoin around and sends it back to himself > > so maybeit's a useless idea? but maybe that's enough of a hassle to stop > people (it certainly breaks ordi

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

And prevent perfectly reasonable transfers of value Such a transfer can only be reasonable when off-chain value is attached to the coins.  A rule like this is the embodiment of the philosophy that the Bitcoin network is for onchain-economic transactions. Parties could get around the rule by

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

On 7/11/22 15:26, Peter Todd via bitcoin-dev wrote: Anyway, designing protocols for "price go up forever" hopium is a bad idea. Yet that is the design, and it's a good one.  It is equivalent to relying on bitcoin to steadily grow in utility vs. fiat currencies. If it fails to do that, there

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

On 7/20/19 10:46 AM, Matt Corallo via bitcoin-dev wrote: (less trustful and privacy-violating) alternative over the coming years. The same paper that established the 'privacy-violating' conventional wisdom presented mitigations which have seen little exploration. https://eprint.iacr.org/2014/

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Apr 7, 2017 12:42, "Gregory Maxwell" wrote: On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev wrote: > A network in which many nodes maintain a transaction index also enables a > class of light node applications that ask peers to prove existence and > spentness o

Re: [bitcoin-dev] Using a storage engine without UTXO-index

On Apr 6, 2017 6:31 PM, "Tomas via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Bitcrust just uses a *transaction-index*, where outputs can be looked up regardless of being spent. A network in which many nodes maintain a transaction index also enables a class of light node appl

Re: [bitcoin-dev] High fees / centralization

On 3/30/2017 9:14 AM, David Vorick wrote: > On Mar 30, 2017 12:04 PM, "Tom Harding via bitcoin-dev" > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > Raystonn, > > Your logic is very hard to dispute. An important special case is >

[bitcoin-dev] High fees / centralization

Raystonn, Your logic is very hard to dispute. An important special case is small miners. Small miners use pools exactly because they want smaller, more frequent payments. Rising fees force them to take payments less frequently, and will only tend to make more of them give up. With fees rising s

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote: > On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev > > wrote: > > With a tightening of the rule set, a hash power minority that has > not upgraded will not produce a minority bra

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

On 3/15/2017 5:25 PM, b...@cock.lu wrote: > compact fraud proofs in Bitcoin aren't possible > In the white paper SPV clients have the same security as fully > validating nodes In addition to not existing, if compact fraud proofs did exist, trying to ensure they are seen by SPV clients has the same

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

Agreed. In contrast, BIP37 as used today is totally decentralized, and can me made much more secure, private, and scalable -- without giving up the utility of unconfirmed transactions. Please don't read into this statement a belief that all the coffees should go on the chain, or that the sec

Re: [bitcoin-dev] Three hardfork-related BIPs

On 1/28/2017 10:29 AM, Peter Todd via bitcoin-dev wrote: > a world of nodes in large datacenters is a world where it's very easy > to force the few Bitcoin nodes remaining to follow AML/KYC rules If that's true, why haven't we already seen AML/KYC required of mining pools? That would be comparati

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Johnson, It's actually clear from your original post - you treat "all zeros" in a special way - as the equivalent of all ones. The semantics match the impression I got originally. Sorry we got sidetracked. ___ bitcoin-dev mailing list bitcoin-dev@l

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Even more to the point, new post- fork coins are fork-specific. The longer both forks persist, the more transactions become unavoidably fork-specific through the mixing in of these coins. Any attempt to maximize replay will become less effective with time. The rationality of actors in this s

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

On 1/24/2017 8:03 PM, Johnson Lau wrote: it seems they are not the same: yours is opt-out, while mine is opt-in. I missed this. So in fact you propose a self-defeating requirement on the new network, which would force unmodified yet otherwise compatible systems to change to support the new n

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote: > 9. If the network characteristic byte is non-zero, and the existing > network characteristic bit is set, the masked version is used to > determine whether a transaction should be mined or relayed (policy change) Johnson, Your proposal sup

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

James, I share your conviction that miners are the natural gatekeepers of the maximum block size. The trouble I see with Block75 is that linear growth won't work forever. Also, by reading actual and not miners' preferred max blocksize, this proposal is sensitive to randomness in block timing and

Re: [bitcoin-dev] Interpreting nTime for the purpose of Bitcoin-attested timestamps

On 9/19/2016 10:56 AM, Peter Todd wrote: > I should state that assumption more clearly. Glad to get you thinking, and I need to change my suggestion. The catch-up formula is not applicable because it doesn't limit how long the dishonest miners have to catch up. Instead you want the probability t

Re: [bitcoin-dev] Interpreting nTime for the purpose of Bitcoin-attested timestamps

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/17/2016 9:20 PM, Peter Todd via bitcoin-dev wrote: > The probability that all N blocks are found by dishonest miners is q^N, That's the probability that dishonest miners find N blocks in a row immediately. What you want is the probability that

Re: [bitcoin-dev] New BIP: Dealing with dummy stack element malleability

On 9/1/2016 9:40 PM, Johnson Lau via bitcoin-dev wrote: > This BIP will be deployed by "version bits" BIP9 using the same parameters > for BIP141 and BIP143, with the name "segwit" and using bit 1. > This fix has value outside of segwit. Why bundle the two together? Shouldn't miners have to opp

[bitcoin-dev] Proposal: Hard fork opt-out bits

Your thoughts are sought on this simple proposal to allow transaction authors to restrict execution to fewer than all blockchain forks where the transaction would otherwise be valid. Proposal Node implementations select a bit from among the upper 8 bits of the transaction version space to enfor

Re: [bitcoin-dev] Making AsicBoost irrelevant

On May 11, 2016 7:33 PM, "Peter Todd" wrote: > The optimisation has been independently discovered two or three times (Spondoolies and maybe Bitmain). The idea that a precedent can be set, whereby those who seek or are awarded mining optimization patents risk retaliatory consensus changes, is ver

Re: [bitcoin-dev] Making AsicBoost irrelevant

On 5/10/2016 2:43 PM, Sergio Demian Lerner via bitcoin-dev wrote: > > If we change the protocol then the message to the ecosystem is that > ASIC optimizations should be kept secret. Further to that point, if THIS optimization had been kept secret, nobody would be talking about doing anything, as w

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

On 12/20/2015 3:34 AM, Jeff Garzik via bitcoin-dev wrote: > Ideally we should start having wallets generate those proofs now, and > then introduce the max-age as a second step as a planned hard fork a > couple years down the line. > > However, > 1) There is also the open question of "grandfathered"

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

On Nov 17, 2015 5:54 AM, "Tamas Blummer via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Isolating storage from the rest of consensus code is technically desirable, but implementations using different storage will be unlikely bug-for-bug compatible, > hence able to split the net

Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate

On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote: > In this case, I don't even believe we have any regulator contributors > that disagree. Since Gavin Andresen chose you to be one of 4 people who decides whose contributions are accepted to the Core project, shouldn't you recuse yourself

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On 9/30/2015 10:58 AM, Jorge Timón via bitcoin-dev wrote: > I don't think we need to wait for you to understand the advantages of > softforks to move forward with BIP65, just like we didn't need to wait > for every developer and user to understand BIP66 to deploy it. What a bad example. BIP66 de

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On 9/29/2015 7:05 PM, Rusty Russell wrote: Tom Harding via bitcoin-dev writes: With a simple delay, you can have the embarrassing situation where support falls off during the delay period and there is far below threshold support just moments prior to enforcement, but enforcement happens anyway

Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote: '''Success: Activation Delay''' The consensus rules related to ''locked-in'' soft fork will be enforced in the second retarget period; ie. there is a one retarget period in which the remaining 5% can upgrade. At the that activation bloc

Re: [bitcoin-dev] Fill-or-kill transaction

On 9/17/2015 8:27 PM, jl2012 via bitcoin-dev wrote: > However, requiring 100 block maturity will unfortunately make the > system much less appealing since the recipient may not like it. The maturity requirement can be dropped if the expiration height is more that 100 blocks after inclusion height.

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

culty retarget readjusts to an average of 10 minutes again? On Tue, Sep 8, 2015 at 8:27 PM, Tom Harding via bitcoin-dev <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: There is another concern regarding "flexcap" that was not discussed. A change to difficulty

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

There is another concern regarding "flexcap" that was not discussed. A change to difficulty in response to anything BUT observed block production rate unavoidably changes the money supply schedule, unless you also change the reward, and in that case you've still changed the timing even if not the

Re: [bitcoin-dev] block size - pay with difficulty

On 9/2/2015 9:05 PM, Jeff Garzik via bitcoin-dev wrote: Schemes proposing to pay with difficulty / hashpower to change block size should be avoided. The miners incentive has always been fairly straightforward - it is rational to deploy new hashpower as soon as you can get it online. Introduci

Re: [bitcoin-dev] Unlimited Max Blocksize (reprise)

On 8/30/2015 9:54 AM, Peter R wrote: > Like Daniele pointed out, the greedy algorithm assumed in the paper is > asymptotically optimal in such a case. I'm convinced. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxf

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

On 8/21/2015 3:06 PM, Peter Todd via bitcoin-dev wrote: > On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote: >> Anyone have the best reference for the DoS issues? > Well actually, we can reference the DoS attacks that Bitcoin XT nodes > are undergoing right now - part of the attack is re

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

ack no inversion. This can actually allow more direct preservation of existing semantics. http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009350.html On 8/19/2015 9:21 AM, Mark Friedenbach via bitcoin-dev wrote: > I am indifferent on this issue (the bit inversion), but so far on

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

On 8/21/2015 5:01 PM, Peter Todd wrote: > >> I checked the scenario where only the radio is on, and found the car >> does not crash. > Incidentally, what's your acceptable revenue difference between a small > (1% hashing power) and large (%30 hashing power) miner, all else being > equal? (remember

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

On 8/21/2015 3:21 PM, Peter Todd wrote: > To use a car analogy, Pieter Wuille has shown that the brake cylinders > have a fatigue problem, and if used in stop-and-go traffic regularly > they'll fail during heavy braking, potentially killing someone. You've > countered with a study of highway drivin

Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP

On 8/20/2015 11:07 PM, Peter Todd via bitcoin-dev wrote: > I run a number of high speed nodes and while I don't have historical > logs handy over time, I've noticed a drop from about %5-%10 SPV > clients at any one time tocloser to %1 Just checked mine and found 20.4% bitcoinj connections. ___

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

On 8/20/2015 5:37 PM, Peter Todd wrote: > On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote: > >> I found that small miners were not at all disadvantaged by large blocks. >> > > You used 20% as the size of the large miner, with all the sm

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

On 8/20/2015 3:23 AM, Milly Bitcoin via bitcoin-dev wrote: For the 73th time or so this month on this list: The maximum block size consensus rule limits mining centralization (which is currently pretty bad). Instead of posting all these messages with bald claims why don't you work on a decent

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

Nobody mentioned exchange rates. Those matter to miners too. Does it make sense for George Soros and every other rich person / institution to have the power to move difficulty, even pin it to min or max, just by buying or selling piles of BTC to swing the exchange rate? On 8/14/2015 8:03 AM, Ad

Re: [bitcoin-dev] Fees and the block-finding process

On 8/11/2015 2:23 PM, Adam Back via bitcoin-dev wrote: I dont think Bitcoin being cheaper is the main characteristic of Bitcoin. I think the interesting thing is trustlessness - being able to transact without relying on third parties. That rules out Lightning Network. Lightning relies on thi

Re: [bitcoin-dev] What Lightning Is

On 8/9/2015 2:45 PM, Hector Chu wrote: > Tom, my understanding is that the money that is debited from a payment > hub is simultaneously credited from either another payment hub or the > person making the payment, so that the net funds flow at a payment hub > always sums to zero. That describes the

Re: [bitcoin-dev] What Lightning Is

On Aug 9, 2015 11:54 AM, "Mark Friedenbach" wrote: > On the contrary the funds were advanced by the hub on the creation of the channel. There is no credit involved. That's a chuckle. As I said, nothing requires the hub to advance anything, and if it does, Bob can expect to pay for it. We'll se

[bitcoin-dev] What Lightning Is

On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote: > Don't turn Bitcoin into something uninteresting, please. Consider how Bob will receive money using the Lightning Network. Bob receives a payment by applying a contract to his local payment channel, increasing the amount payable to him w

Re: [bitcoin-dev] Idea: Efficient bitcoin block propagation

On 8/6/2015 10:16 AM, Sergio Demian Lerner via bitcoin-dev wrote: > Is there any up to date documentation about TheBlueMatt relay network > including what kind of block compression it is currently doing? (apart > from the source code) > Another question. Did the "relay network" relay

Re: [bitcoin-dev] Block size following technological growth

On 8/6/2015 7:53 AM, Pieter Wuille via bitcoin-dev wrote: > > So if we would have 8 MB blocks, and there is a sudden influx of users > (or settlement systems, who serve much more users) who want to pay > high fees (let's say 20 transactions per second) making the block > chain inaccessible for low

Re: [bitcoin-dev] Superluminal communication and the consensus block size limit

On 8/5/2015 4:24 PM, Jorge Timón via bitcoin-dev wrote: > Miner A is able to process 100 M tx/block while miner B is only able > to process 10 M tx/block. > B needs to sell ASICs and buy 90 M tx worth of CPU. Or, if you cap blocksize at 10 M tx, than A needs to sell the exact same amount of CPU

Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block Size Limit"--new research paper suggests

On 8/5/2015 3:44 PM, Dave Hudson via bitcoin-dev wrote: I do suspect that if we were to model this more accurately we might be able to infer the "typical" propagation characteristics by measuring the deviation from the expected distribution. The paper models propagation using a single time va

Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal

On 8/1/2015 1:45 PM, Pieter Wuille via bitcoin-dev wrote: > > Regarding "reasonable", I have a theory. What if we would have had 8 > MB blocks from the start? My guess is that some more people would have > decided to run their high-transaction-rate use cases on chain, that > we'd regularly see 4-6

Re: [bitcoin-dev] Another block size limit solution - dynamic block size limit.

On 7/30/2015 8:03 AM, Максим Божко via bitcoin-dev wrote: > I propose to implement dynamic block size limit. Its short summary is > here in doc: > > https://docs.google.com/document/d/1ixt0loN7LOF6M_2HXvV0D-3ZCayvcfj0rzVm-h-6ONg/edit > > A dynamic limit based on recent block sizes has been discuss

Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader

On 7/30/2015 11:14 AM, Jorge Timón wrote: > The blocksize limit (your "production quota") is necessary for > decentralization, not for having a functioning fee market. > If we can agree that hitting the limit will JUST cause higher fees and > not bitcoin to fail, puppies to die or the sky to turn

Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader

Yes. So far, the transaction count factor has completely dominated the per-tx fee factor. This fact should be of great interest to miners. On 7/30/2015 7:25 AM, Dave Hudson wrote: > >> On 30 Jul 2015, at 06:14, Tom Harding via bitcoin-dev >> > <mailto:bitcoin-dev@list

Re: [bitcoin-dev] Bitcoin Core and hard forks

Jorge, We obviously disagree fundamentally on the role of societal adoption, in the system that Satoshi designed. Adoption is well ahead of Satoshi's schedule, and the measure of this is the exchange rate. It is at once an imperfect measure, and one of the most perfect markets that has ever

Re: [bitcoin-dev] Bitcoin Core and hard forks

On 7/24/2015 2:24 AM, Jorge Timón wrote: > Regarding "increasing the exchange rate" it would be really nice to > just push a button and double bitcoin's price just before the next > subsidy halving, but unfortunately that's something out of our control. Jorge, right now, from the activity on git

Re: [bitcoin-dev] Bitcoin Core and hard forks

On 7/23/2015 10:51 AM, Jorge Timón wrote: > We know perfectly well that the system will need to eventually be > sustained by fees. Fee revenue can rise just as easily without increased BTC fee rates. Two avenues that are just as effective: increased exchange rate, increased number of fee-paying t

Re: [bitcoin-dev] Bitcoin Core and hard forks

On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote: > If the user expectation is that a price would never arise because > supply is going to be increased ad infinitum and they will always be > able to send fast in-chain bitcoin transactions for free, just like > breath air (an abundant resour

Re: [bitcoin-dev] Bitcoin Core and hard forks

On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote: It would be irresponsible and dangerous to the network and thus the users of the software to risk forks, or to take a leading role in pushing dramatic changes. Count me among those who see allowing bitcoin to become space-constrained,

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

On 7/21/2015 6:58 AM, Peter Todd via bitcoin-dev wrote: Re: BIP #'s, we explicitly have a policy of allocating them for stupid ideas, to avoid having to be gatekeepers. Ironically that makes it harder to get a BIP # if you know what you're doing, because Gregory Maxwell will argue against you i

Re: [bitcoin-dev] Mempool "Expected Byte Stay" policy

On 7/16/2015 2:38 AM, Thomas Zander via bitcoin-dev wrote: On Wednesday 15. July 2015 16.15.24 Tom Harding via bitcoin-dev wrote: On 7/15/2015 12:18 PM, Thomas Zander via bitcoin-dev wrote: On Tuesday 14. July 2015 17.24.23 Tom Harding via bitcoin-dev wrote: Rule 2: A transaction and its

Re: [bitcoin-dev] Mempool "Expected Byte Stay" policy

On 7/15/2015 12:18 PM, Thomas Zander via bitcoin-dev wrote: On Tuesday 14. July 2015 17.24.23 Tom Harding via bitcoin-dev wrote: Rule 2: A transaction and its dependents are evicted on its 2-hour anniversary, whether space is required or not Instead of 2 hours, why not a number of blocks? So

Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions

You perform a valuable service with your demonstration, but you neglected to include the txid's to show that you actually did it. Your advice is must-follow for anyone relying on an unconfirmed tx: it must pay a good fee and be highly relayable/minable. On 7/14/2015 8:29 PM, simongreen--- via b

[bitcoin-dev] Mempool "Expected Byte Stay" policy

Spammers out there are being very disrepectful of my fullnode resources these days! I'm making some changes. In case others are interested, here's a description: There is now a maximum size for the memory pool. Space is allocated with a pretty simple rule. For each tx, I calculate MY COST o