The reason that BIP37 presents a long list of problems is that it is a
client-server scenario wedged into a peer-to-peer network. The only possible
excuse for this design was implementation shortcut.
As this thread and others demonstrate, reproducing this design flaw will not
eliminate the prob
Hi Erik,
As you know:
1. If a sidechain is merged mined it basically grows out of the existing
Bitcoin mining network. If it has a different PoW algorithm it is a new
mining network.
2. The security (ie, hashrate) of any mining network would be determined
by the total economic value of the block.
On Tuesday, 20 June 2017 00:41:49 CEST Gregory Maxwell via bitcoin-dev
wrote:
> Can someone make a case why saving no more than those figures would
> justify the near total loss of privacy that filtering gives?
First, your figures are wrong and also fall out of the sky with no
justification. Can
On 2017-06-20 12:52, Tom Zander via bitcoin-dev wrote:
Second, stating that a bloom filter is a "total loss of privacy" is
equally
baseless and doesn’t need debunking.
"On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin
Clients"
We show analytically and empirically that the
- a proof-of-burn sidechain is the ultimate two-way peg. you have to burn
bitcoin *or* side-chain tokens to mine the side chain. the size of the
burn is the degree of security.i actually wrote code to do randomized
blind burns where you have a poisson distribution (non-deterministic
selecte
Are we going to merge BIP91 or a -BIP148 option to core for inclusion in
the next release or so?
Because a large percentage of miners are indifferent, right now miners have
to choose between BIP148 and Segwit2x if they want to activate Segwit.
Should we be forcing miners to choose to run non-core
I don't think it's a huge deal if the miners need to run a non-Core node
once the BIP91 deployment of Segwit2x happens. The shift will most likely
be temporary.
I agree that the "-bip148"-option should be merged, though.
2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists
Also Jonas Nick gave a fairly comprehensive presentation on privacy
leaks in bitcoin protocol including SPV and bloom query problem
specifics:
https://www.youtube.com/watch?v=HScK4pkDNds
Adam
On 20 June 2017 at 14:08, bfd--- via bitcoin-dev
wrote:
> On 2017-06-20 12:52, Tom Zander via bitcoin-
I think it is very naïve to assume that any shift would be temporary.
We have a hard enough time getting miners to proactively upgrade to
recent versions of the reference bitcoin daemon. If miners interpret
the situation as being forced to run non-reference software in order
to prevent a chain spli
On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
wrote:
> Because a large percentage of miners are indifferent, right now miners have
> to choose between BIP148 and Segwit2x if they want to activate Segwit.
Miners can simply continuing signaling segwit, which will leave them
at leas
I concur with Mark's reply. Just to underscore this: Miners arent going to
bother to signaling or changing a setting unless they have to. Anything that
requires time--especially if requiring a restart/any time not mining or risks a
crash---reduces income. So why would they change any settings un
> Ironically, it looks like most of the segwit2x signaling miners are
> faking it (because they're not signaling segwit which it requires).
> It'll be unfortunate if some aren't faking it and start orphaning
> their own blocks because they are failing to signal segwit.
Well, they're doing some kin
Ken and team,
Took some time but here it is ! *Bravo !*
And as usual reporter make up the shit they want ... Feel free to remind
them that we had a working group and we worked on it.
https://www.theverge.com/2017/6/20/15840008/new-emoji-
unicode-consortium-version-10-bitcoin-symbol
The "Could be
If segwit is activated before Aug 1, as now seems likely, there will be no
split that day. But if activation is via Segwit2x (also likely), and at
least some nodes do & some don't follow through with the HF 3mo later
(again, likely), agreed w/ Greg that *then* we'll see a split - probably in
Sep/O
On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg
wrote:
> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
> BIP148) node, because they wouldn't have the new consensus rule of requiring
> all blocks to signal for segwit.
All versions of Bitcoin Core since 0.13.1 signal segw
> I think it would be useful for there to exist a useful and trivial
> patch against current (0.14.2) software to engage in the BIP91-like
> orphaning, like people have provided for BIP148-- but right now I
> don't see any specification of the behavior so it's unclear to me
> _exactly_ what it woul
Why do you say activation by August 1st is likely? That would require an entire
difficulty adjustment period with >=95% bit1 signaling. That seems a tall order
to organize in the scant few weeks remaining.
> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
> wrote:
>
> If segwit i
I could be wrong, but the latest BIP91 implementation (also included in
Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This has
been updated at
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So if 80%
of hashpower is actually running that code and signaling on
(That is: "...because they're mined by old non-Segwit2x nodes that *aren't
signaling bit 1 support*", ie, that support neither Segwit2x nor old segwit)
On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff
wrote:
> I could be wrong, but the latest BIP91 implementation (also included in
> Segwit2x) cu
# Jacob Eliosoff:
> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
split.
Correct. There are 2 short activation periods in BIP91 either of which
would avoid a split.
# Gregory Maxwell:
> unclear to me _exactly_ what it would need to implement to be consistent.
This is the
80% have set "NYA" in their coinbase string. We have no idea what that
means. People are equating it to BIP 91 -- but BIP 91 did not exist at
the time of the New York agreement, and differs from the actual text
of the NYA in substantive ways. The "Segwit2MB" that existed at the
time of the NYA, and
21 matches
Mail list logo
