Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

On Fri, Apr 30, 2021 at 7:59 AM Amir Taaki via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A committee to guide the committee? You guys truly have lost the plot. > > All the good minds and cryptographers have left Bitcoin. What remains is > an empty echo chamber. > > Truth is

[bitcoin-dev] Transaction size & weight calculation tooling

Hi all, Anyone who has built a Bitcoin wallet / service has to deal with a variety of challenges when it comes to transaction construction. One of these challenges is around determining an appropriate fee; aside from block space market volatility and the inherent problems of forecasting the

Re: [bitcoin-dev] BIP39 seeds

I believe it would depend upon the entropy used for the seed, as that would affect how many bits the checksum represents. https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic So for a 24 word / 256 bit mnemonic the checksum is 8 bits, thus there are 8 valid

Re: [bitcoin-dev] Testnet block generation

This is normal behavior due to a special rule on testnet. For a detailed explanation you can read https://web.archive.org/web/20160910173004/https://blog.blocktrail.com/2015/04/in-the-darkest-depths-of-testnet3-16k-blocks-were-found-in-1-day/ - Jameson On Thu, Jun 28, 2018 at 9:22 AM Mattia

Re: [bitcoin-dev] Possible change to the MIT license

hing the Bitcoin Foundation would lead on here? and runs for cover> > > In any case, it’s frustrating to watch the ongoing FUD and scammery going > unanswered in any “official” capacity. > > > On February 13, 2018 at 7:25:35 AM, Jameson Lopp via bitcoin-dev ( > bitcoin-dev@lists.

Re: [bitcoin-dev] Possible change to the MIT license

If I'm understanding the problem being stated correctly: "Bitcoin is under a branding attack by fork coins." The proposed solution is to disincentivize fork coins from using the word Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me that the words of the license are

Re: [bitcoin-dev] Total fees have almost crossed the block reward

I'd hope that the incentives are in place to encourage high volume senders to be more efficient in their use of block space by batching transactions and implementing SegWit, though this may not be the case for providers that pass transaction fees along to their users. We've been trying to be more

Re: [bitcoin-dev] UTXO growth scaling solution proposal

Sounds like demurrage to me, which has been implemented in other cryptocurrencies such as Freicoin - http://freico.in/ While it's an interesting to apply this line of thinking from a scaling perspective, I suspect most would find it untenable from a monetary policy perspective. You have touched

Re: [bitcoin-dev] how to disable segwit in my build?

On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote: > >> I believe that a good reason not to wish your node to be segwit > > compliant is to avoid having to deal with the extra

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

On Wed, Jun 14, 2017 at 12:04 PM, Zheming Lin wrote: > Hi Jameson: > > 在 2017年6月15日，02:55，Jameson Lopp 写道： > > > > On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin wrote: > >> Hi Jameson: >> >> 在 2017年6月15日，01:20，Jameson Lopp

Re: [bitcoin-dev] Proposal: Demonstration of Phase in Full Network Upgrade Activated by Miners

On Wed, Jun 14, 2017 at 11:29 AM, Zheming Lin wrote: > Hi Jameson: > > 在 2017年6月15日，01:20，Jameson Lopp 写道： > > > > On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev lists.linuxfoundation.org> wrote: > >> >> >> > 在

Re: [bitcoin-dev] Encouraging good miners

Bitcoin chooses the "best chain" based upon the one that has the most cumulative proof of work behind it. Are you proposing that the cumulative proof of work be ignored if two blocks are within a certain threshold of each others' work and if so, the number of transactions in the block / the size

Re: [bitcoin-dev] Moving towards user activated soft fork activation

You've made many salient points, Shaolin, though I have a few questions: 1) How well does this model work under adversarial conditions? Fair point about signaling not being reliable, though it seems more vague in terms of safety given that you can't actually know what percentage of hashrate that

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

Since "buried deployments" are specifically in reference to historical consensus changes, I think the question is more one of human consensus than machine consensus. Is there any disagreement amongst Bitcoin users that BIP34 activated at block 227931, BIP65 activated at block 388381, and BIP66

[bitcoin-dev] BIP44 & BIP32 chain address look-ahead limits

I recently ran into an issue while importing a Mycelium HD wallet where it was not finding all of my funds - upon further investigation with Mycelium devs we realized that the wallet was following the BIP44 spec correctly, but BIP44 may have a flaw. The problem was a result of my creating 16

Re: [bitcoin-dev] SegWit testnet is live

BitGo also intends to support SegWit transactions as soon as possible. - Jameson On Thu, Jan 7, 2016 at 9:17 PM, Matthieu Riou via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Not strictly speaking a wallet but we (BlockCypher) will also go down the > segwit path as soon as the

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik wrote: > >> You present this as if the Bitcoin Core development team is in charge > >> of deciding the network

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A large part of your argument is that SW will take longer to deploy than a > hard fork, but I completely disagree. Though I do not agree with some > people claiming we can deploy SW

Re: [bitcoin-dev] A solution to increase the incentive of running a node

If operating as an SPV node then it can check the transactions by querying other nodes. On an unrelated note, it sounds like your proposal will significantly increase the data size of every transaction, which will create even more contention for block space. - Jameson On Wed, Aug 19, 2015 at

Re: [bitcoin-dev] A solution to increase the incentive of running a node

On Wed, Aug 19, 2015 at 7:15 AM, Hector Chu via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Bitcoin is imploding due to a failure of consensus. There has been a failure of consensus on how to fix the design flaw evinced by the block size fiasco. I disagree, but this isn't a

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

Anecdotally I've seen two primary reasons posed for not running a node: 1) For enthusiasts who want to altruistically run a node at home, it's usually a bandwidth / quality of service problem. There are tools to help work around this, but most users aren't sysadmins and would prefer a simple

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

are not magic bullets and still require the occasional on-chain settlement. Larger blocks will be necessary with or without the actual scalability enhancements. - Jameson On Thu, Jul 30, 2015 at 12:36 PM, Bryan Bishop kanz...@gmail.com wrote: On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin

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

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo elombr...@gmail.com wrote: On Jul 23, 2015, at 11:10 AM, Jameson Lopp jameson.l...@gmail.com wrote: Larger block sizes don't scale the network, they merely increase how much load we allow the network to bear. Very well put, Jameson. And the