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 small miners having good connectivity

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

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 that we

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: [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

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 bitcoin-dev@lists.linuxfoundation.org mailto:bitcoin

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 MB

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] 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

[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

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,

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

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] 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

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 fee

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

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 github,

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

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

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

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

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 <bitcoin-dev@lists.linuxfoundation.org> 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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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] 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

[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

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" > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > Raystonn, > > Your logic is very

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

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

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

On Apr 7, 2017 12:42, "Gregory Maxwell" <g...@xiph.org> wrote: On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > A network in which many nodes maintain a transaction index also enables a > class of light node

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

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.

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,

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

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

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