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 b
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 o
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
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 basi
on 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.linuxfoundati
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 Rossi
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 checks
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 consensus rules, and is res
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 sig
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
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 trans
Great post, Peter.
4) By fixing the problem (or possibly just "fixing" the problem) are
we encouraging/legitimising blockchain use-cases other than BTC value
transfer? Should we?
I don't think it would encourage non-value-transfer usage more
because, as you noted, many such use cases are valuable
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
acti
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
i
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 of
On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > 在 2017年6月14日，02:11，Gregory Maxwell 写道：
> >
> > On Tue, Jun 13, 2017 at 2:23 AM, Zheming Lin via bitcoin-dev
> > wrote:
> >> The BIP is described using Chinese and English. If any
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:
>
>>
>>
>> > 在 2017年6月14日，02:11，Gregory Maxwell 写道：
>> >
>> > On Tue, Jun 13, 2017 a
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 写道：
>>
>>
>>
>> On Wed, Jun 14, 2017 at 9:39 AM, Zheming Lin via bitcoi
Are you willing to share the code that you used to run the test?
- Jameson
On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On this day, the Bitcoin network was crawled and reachable nodes surveyed
> to find their maximum throughput in
On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'd really like to move from "IMPOSSIBLE because... (electrum hasn't
On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo wrote:
>
> On Jul 23, 2015, at 11:10 AM, Jameson Lopp 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 cost of bearing this load must be p
I find it to be an admirable goal to try to keep node operation costs low
and accessible to the average user. On the other hand, if we are able to
keep the resource requirements of nodes at the level of, say, whatever the
latest Raspberry Pi model on a residential Internet connection can handle,
I'
d
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 wrote:
> On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <
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
confi
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
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 7:4
On Wed, Aug 19, 2015 at 8:15 AM, Hector Chu wrote:
> On 19 August 2015 at 13:08, Jameson Lopp wrote:
> > If operating as an SPV node then it can check the transactions by
> querying
> > other nodes.
>
> SPV is for checking validity of transactions that have already entered
> the blockchain, as I
I don't think you'll find much support for introducing a mandatory minimum
block size. It's quite wasteful to "pad" blocks with transactions that the
miner is just sending back to themself. If you want to solve the block
propagation issue, I'd recommend instead working on O(1) block propagation.
T
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 future
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 the
30 matches
Mail list logo
