On Mon, Jun 28, 2021 at 3:52 AM wrote:
>
>
> Hi James,
> Sorry for not responding in detail.
> So, lets jump in the critiques.
>
> > You're making the assumption that miners won't build on top of a block
> with transactions they have not seen before or transactions that may
> contain double spends
On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
wrote:
>
> Hi ZmnSCPxj,
>
> Why you get the signal “trust the Gazin wallet”?
> Sabu is a protocol and the Gazin wallet will be an implementation of
> that protocol. We will implement it in react-native language to support
> both Android and iPh
I think you're making a number of assumptions about mining that are
not accurate.
> First of all, how much chance in finding next block the corrupted miners
> have? One percent of all Bitcoin hash powers? Or maximum 5 percent or 10? The
> cheaters must come up in dividing that 1.2 Bitcoin betwee
Recently a large merchant payment processor has decided to drop
support for BIP21 payment URI's in favor of accepting exclusively
BIP70 payments which has brought to light a number of problems with
BIP70:
1. Many wallets do not support BIP70 and have no near term intention
of doing so.
2. BIP70 re
There have been some other proposals to deal with this such as
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.html
that may be possible to implement in existing miners.
On Tue, Oct 3, 2017 at 9:52 AM, 潘志彪 via bitcoin-dev
wrote:
> Here is a solution may solve Block Withho
This seems like something that might be better dealt with by modifying
the RBF eviction policy to calculate feerate separation between the
transactions in the mempool and opportunistically evict the sweep
transaction+parent if it has a sufficiently different feerate from the
bumped fee replacement.
the pool operator/stratum server also does not do validation, then any
> number of problems could occur.
Yes, there is a good amount of risk with validationless mining right
now here since it's well known that over half of mining pools use
validationless mining to some degree. This may not be
On Tue, Jun 13, 2017 at 3:24 AM, Zheming Lin via bitcoin-dev
wrote:
> Hi all the developers:
>
> I must clarify that despite the general ideas comes from discussions with
> others. The opinion in replies are only limited to my self.
>
> The old TXs can be re-enable after the fourth stage and just
On Tue, Jun 13, 2017 at 3:13 AM, Zheming Lin wrote:
> Hi James:
>
> 在 2017年6月13日，15:19，James Hilliard 写道：
>
> On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin wrote:
>
> Hi James:
>
> Thank you very much for detailed feedback. Sorry for my understanding of
> English being poor. I’ll try to answer th
On Tue, Jun 13, 2017 at 1:50 AM, Zheming Lin wrote:
> Hi James:
>
> Thank you very much for detailed feedback. Sorry for my understanding of
> English being poor. I’ll try to answer that.
>
>
> 在 2017年6月13日，13:44，James Hilliard 写道：
>
> On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
On Mon, Jun 12, 2017 at 9:23 PM, Zheming Lin via bitcoin-dev
wrote:
> The BIP is described using Chinese and English. If any part is missing or
> need more specific, please reply. Forgive for my poor English.
>
> This method will incorporate any upgrade that affects non-mining nodes. They
> shou
mandatory signalling ahead of BIP148. Maybe that can be
>> >> >> >> changed though, I've suggested an immediate rollout with a
>> >> >> >> placeholder
>> >> >> >> client timeout instead of the HF code initially in order to
>> &
t;> >> is takes too long to activate unless started ahead of the existing
>> >> >> segwit2x schedule and it's unlikely that BIP148 will get pushed back
>> >> >> any further.
>> >> >> >
>> >> >> > Jared
>&
y, if either the segwit2x signatories balk about the Bit1
>> >> >>> signaling OR if the timelines for segwit2mb are missed even by a
>> >> >>> bit,
>> >> >>> it may cause the BIP148 chainsplit to be worse than it would be
>> >> >>> wi
ly the segwit2x plan were delayed for a few days. While any
>> >>> additional support would definitely be cheered on by BIP148
>> >>> supporters, the practical reality might be that this proposal would
>> >>> take BIP148 from the "unlikely to have
;>> supporters on the wrong pro-segwit, but still-viable chain.
>>>
>>> If Core had taken a strong stance to include BIP148 into the client,
>>> and if BIP148 support were much much broader, I would feel differently
>>> as the gamble would be more likely to disc
for miners to quickly defend against a
>>>> chain
>>>> split, much better than a -bip148 option. This allows miners to defend
>>>> themselves, with very little risk, since the defense is only activated if
>>>> the majority of miners do so. I wo
inority chainsplit that may wind up on the
> wrong side of two segwit-activated chains). As it stands now, this
> seems like a very dangerous attempt to compromise with a small but
> vocal group that are the ones creating the threat to begin with.
>
> Jared
>
> On Tue, Jun 6,
themselves, with very little risk, since the defense is only activated if
>> the majority of miners do so. I would move for a very rapid deployment.
>> Only miners would need to upgrade. Regular users would not have to concern
>> themselves with this release.
>>
>> On Wed
to >50%, I think, might cause
> confusion.)
>
> -Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
> wrote:
>
> Due to the proposed c
also sharing
> with the NSA.
>
> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
> wrote:
>
> Due to the proposed calendar(https://segwit2x.github.io/) for the
> SegWit2x agreement being too slow to activate SegWit mandatory
> signalling ahead of BIP148 using
n Wed, Jun 7, 2017 at 9:56 AM, James Hilliard via bitcoin-dev
> wrote:
>> Due to the proposed calendar(https://segwit2x.github.io/) for the
>> SegWit2x agreement being too slow to activate SegWit mandatory
>> signalling ahead of BIP148 using BIP91 I would like to propose anothe
Due to the proposed calendar(https://segwit2x.github.io/) for the
SegWit2x agreement being too slow to activate SegWit mandatory
signalling ahead of BIP148 using BIP91 I would like to propose another
option that miners can use to prevent a chain split ahead of the Aug
1st BIP148 activation date.
T
For the reasons listed
here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivation)
you should have it so that the HF can not lock in unless the existing
BIP141 segwit deployment is activated.
The biggest issue is that a safe HF is very unlikely to be able to be
coded and tested
On Sun, May 28, 2017 at 3:51 PM, Tom Zander via bitcoin-dev
wrote:
> On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
>> > why?
>>
>> the main
>> issue is due to 0.13.1+ having many segwit related features active
>> already, including all the P2P components, the new network service
>>
Mandatory signalling is the only way to lock in segwit with less than
95% hashpower without a full redeployment(which for a number of
technical reasons isn't feasible until after the existing segwit
deployment expires). There's no reason not to signal BIP141 bit 1
while also signalling bit 4, but y
posal is incompatible with the current
>>>> segwit implementation with regards to the NODE_WITNESS service bit. I
>>>> believe it could cause network partitioning if the service bit is not
>>>> changed.
>>>>
>>>> Andrew
>>>>
>
oposal is incompatible with the current
> segwit implementation with regards to the NODE_WITNESS service bit. I
> believe it could cause network partitioning if the service bit is not
> changed.
>
> Andrew
>
>
> On 5/22/2017 6:40 PM, James Hilliard via bitcoin-dev wro
On Tue, May 23, 2017 at 5:51 AM, Kekcoin wrote:
> I think there may be merit to this idea, allowing for political compromise
> without sacrificing the technological integrity of Bitcoin. There are a few
> mechanical problems I see with it, though.
>
> 1. It should change its activation logic from
I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:
"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that
The goal here is to minimize chain split risk and network disruption
while ma
Locking the lower bits on the timestamp will likely break existing
hardware that relies on being able to roll ntime.
On Thu, May 18, 2017 at 8:44 AM, Cameron Garnham via bitcoin-dev
wrote:
> Hello Bitcoin Development Mailing List,
>
> I wish to explain why the current approach to ‘ASICBOOST’ dose
Doing a second soft-fork from 50% to 75% sounds more difficult since
that's going from a more restrictive ruleset to less restrictive, you
might be able to hack around it but it wouldn't be a fully backwards
compatible change like going from 75% to 50% would be. 50% vs 75% does
affect max transacti
The discount is designed to reduce UTXO bloat primarily, witness spam
data would not make it into the UTXO set. The discount brings the fee
of a transaction more in line with the actual costs to the network for
the transaction. A miner spamming the network with 4MB witness blocks
would have very li
On Fri, Apr 14, 2017 at 3:58 PM, Tom Zander via bitcoin-dev
wrote:
> On Friday, 14 April 2017 22:51:04 CEST James Hilliard wrote:
>> This doesn't remove the need for consensus rule enforcement of course.
>
> Thanks for confirming my point.
>
> This means that Gregory was incorrect saying that ther
On Fri, Apr 14, 2017 at 3:34 PM, Tom Zander wrote:
> On Friday, 14 April 2017 21:33:49 CEST James Hilliard wrote:
>> This is false,
>>
>> Those "everyone can spend" transactions are prohibited from being
>> mined due to policy rules.
>
> I expected you to know this, but ok, I'll explain.
>
> A pol
On Fri, Apr 14, 2017 at 2:20 PM, Tom Zander via bitcoin-dev
wrote:
> On Friday, 14 April 2017 09:56:31 CEST Gregory Maxwell via bitcoin-dev
> wrote:
>> Segwit was carefully engineered so that older unmodified miners could
>> continue operating _completely_ without interruption after segwit
>> acti
It is a consensus rule
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
On Tue, Apr 4, 2017 at 6:47 AM, Tom Zander via bitcoin-dev
wrote:
> On Sunday, 2 April 2017 22:39:13 CEST Russell O'Connor via bitcoin-dev
> wrote:
>> Someone told me a while back that it would be more natural
There were bridge nodes being run on testnet at one point to prevent
forks
https://github.com/jl2012/bitcoin/commit/9717d856e72baa939d4b273f0a56e6009978e11b
On Thu, Mar 23, 2017 at 7:20 PM, Pieter Wuille via bitcoin-dev
wrote:
> On Thu, Mar 23, 2017 at 3:37 PM, Juan Garavaglia via bitcoin-dev
>
I think the main thing you're missing is that there will always be
transactions available to mine simply because demand for blockspace is
effectively unbounded as fees approach 0. Nodes generally have a
static mempool size and dynamic minrelaytxfee nowadays so as
transactions get mined lower fee tr
What's most likely to happen is miners will max out the blocks they
mine simply to try and get as many transaction fees as possible like
they are doing right now(there will be a backlog of transactions at
any block size). Having the block size double every year would likely
cause major problems and
Miners in general are naturally incentivized to always mine max size
blocks to maximize transaction fees simply because there is very
little marginal cost to including extra transactions(there will always
be a transaction backlog of some sort available to mine since demand
for block space is effect
I was told that the patent appears to be owned exclusively by Bitmain
in China https://www.google.com/patents/CN105245327A?cl=en
On Wed, May 11, 2016 at 4:50 PM, Matt Corallo via bitcoin-dev
wrote:
> That's the reason for this post! All current major ASIC manufacturers
> have made warrants that t
f period)
> After 10 weeks: 16XDiff (8 weeks per diff period)
> After 42 weeks: 256XDiff (32 weeks per diff period)
>
>
> On Wed, Feb 24, 2016 at 5:52 AM, James Hilliard via bitcoin-dev
> wrote:
>>
>> https://github.com/bitcoin/bips/pull/340
>>
>> BIP: ?
>
https://github.com/bitcoin/bips/pull/340
BIP: ?
Title: 2016 Multi-Stage Merge-Mine Headers Hard-Fork
Author: James Hilliard
Status: Draft
Type: Standards Track
Created: 2016-02-23
==Abstract==
Use a staged hard fork to implement a headers format change that is
merge mine incompatible along with
I think something that anyone who isn't validating should be aware of is
that cgminer(which powers the vast majority of the current mining network)
doesn't allow for a pool to revert to mining on the previous block due to
the way chain tracking is implemented.
https://github.com/ckolivas/cgminer/b
The priority space is causing major mempool bloating and GBT latency right
now since many of the free transactions aren't getting mined and cleared
out of the mempool anymore. From my testing setting minrelaytxfee=0.0001 is
not enough to prevent the mempool from getting large during a spam attack,
You should tell AT&T that you want the DVR/cable box put into what is
usually referred to as "bridge mode" or sometimes "true bridge mode"
depending on your ISP and then use your own router, look under
"Bridged Mode" at the bottom of this page for AT&T
http://www.att.com/gen/general?pid=23697 . You
47 matches
Mail list logo
