On Mon, Jun 19, 2017 at 12:26 PM, bfd--- via bitcoin-dev
wrote:
> Several times. It's been debated if unconfirmed transactions are necessary,
> methods of doing more private filtering have been suggested, along with
> simply not filtering unconfirmed transactions at all. My collected data
> sugges
Most SPV wallets make it quite clear that unconfirmed transactions are
just that.
On 06/19/2017 06:36 PM, adiabat via bitcoin-dev wrote:
> This has been brought up several times in the past, and I agree with
> Jonas' comments about users being unaware of the privacy losses due to
> BIP37. One th
Here is the text of a post to reddit from Feb 2017, discussing a similar
idea, and wondering if it could reduce the incentive to delay broadcast of
solved blocks:
# How an anchored Proof of Stake Sidechain can help the Bitcoin main chain
# Steps:
1. Soft fork Bitcoin to enable side chains
2. Cr
It is essential that BIP-148 nodes connect to at least two other BIP-148 nodes
to prevent a network partition in August 1st. The temporary service but is how
such nodes are able to detect each other.
> On Jun 19, 2017, at 12:46 PM, Tom Zander via bitcoin-dev
> wrote:
>
>> On Monday, 19 June 2
On Monday, 19 June 2017 21:26:22 CEST Luke Dashjr via bitcoin-dev wrote:
> To ease the transition to BIP148 and to minimise risks in the event miners
> choose to perform a chain split attack, at least Bitcoin Knots will be
> using the temporary service bit (1 << 27) to indicate BIP148 support.
>
>
To ease the transition to BIP148 and to minimise risks in the event miners
choose to perform a chain split attack, at least Bitcoin Knots will be using
the temporary service bit (1 << 27) to indicate BIP148 support.
Once the transition is complete, this will no longer be necessary, and the bit
On Tue, Jun 20, 2017 at 02:01:45AM +0800, Wang Chun via bitcoin-dev wrote:
> There has been proposal to change the PoW in case of potential 51% attacks
> from malicious miners during a fork. But such a change in PoW renders
> multi-billion-dollar of ASIC into worthless. which hurts economy so much
There has been proposal to change the PoW in case of potential 51% attacks
from malicious miners during a fork. But such a change in PoW renders
multi-billion-dollar of ASIC into worthless. which hurts economy so much
and the average innocent mining users. I would propose, instead of PoW
change, we
On Monday, 19 June 2017 18:30:18 CEST Jonas Schnelli wrote:
> I personally would ALWAYS [snip]
I mentioned that it was a usability point for a reason, and your personal
behavior makes me want to quote one of the main UX guidelines;
“You are not your user”
http://uxmyths.com/post/715988395/myt
This has been brought up several times in the past, and I agree with
Jonas' comments about users being unaware of the privacy losses due to
BIP37. One thing also mentioned before but not int he current thread
is that the entire concept of SPV is not applicable to unconfirmed
transactions. SPV use
>>
>> I think many users would be willing ...
>> a) … to trade higher privacy (using client side filtering) for not having
>> the „incoming transaction“ feature b) – if they want 0-conf – to fetch
>> all inved transactions
>
> You seem to misunderstand the usecase.
> If you send me a transaction,
>
> On the other hand, I remember only 1 (one) inquiry about the privacy
> problems of BIP37 (or privacy at all).
IMO privacy its something developers should make sure users have it.
Also, I think, todays SPV wallets should make users more aware of the possible
privacy implications.
Do users kn
On Monday, 19 June 2017 17:49:59 CEST Jonas Schnelli wrote:
> Hi
>
> > On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
> >> It's been debated if [filtering of] unconfirmed transactions are
> >> necessary,
> >
> > Why would it not be needed? Any SPV client (when used as a
> > p
> Just to give you a number: based on the statistics of the Bitcoin Wallet
> app there are at least 2 million wallets depending on BIP37. Not all
> would need instant notification but based on the daily support enquiries
> instant notificaton is the most asked property of Bitcoin.
Yes. Users pro
Hi Greg,
Responses below:
On 6/18/2017 5:30 PM, Tao Effect wrote:
> In Drivechain, 51% of miners have total control and ownership over all
> of the sidechain coins.
It would not be accurate to say that miners have "total" control. Miners
do control the destination of withdrawals, but they do not
On 06/19/2017 05:49 PM, Jonas Schnelli via bitcoin-dev wrote:
>>> It's been debated if [filtering of] unconfirmed transactions are
>>> necessary,
>>
>> Why would it not be needed? Any SPV client (when used as a payment-receiver)
>> requires this from a simple usability point of view.
>
>
> I thi
Hi
> On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
>> It's been debated if [filtering of] unconfirmed transactions are
>> necessary,
>
> Why would it not be needed? Any SPV client (when used as a payment-receiver)
> requires this from a simple usability point of view.
I th
>
> Since the sidechain has the sidechain BMM headers that they want the LD
> (bribe) data for, I think that they could specifically request LD data
> relevant only to that sidechain by providing a list of hashes to the
> mainchain, and the mainchain can return a list of boolean values telling
> th
Just to give you a number: based on the statistics of the Bitcoin Wallet
app there are at least 2 million wallets depending on BIP37. Not all
would need instant notification but based on the daily support enquiries
instant notificaton is the most asked property of Bitcoin.
On 06/19/2017 02:26 PM,
On Monday, 19 June 2017 14:26:46 CEST bfd--- via bitcoin-dev wrote:
> It's been debated if [filtering of] unconfirmed transactions are
> necessary,
Why would it not be needed? Any SPV client (when used as a payment-receiver)
requires this from a simple usability point of view.
--
Tom Zander
Bl
Several times. It's been debated if unconfirmed transactions are
necessary, methods of doing more private filtering have been suggested,
along with simply not filtering unconfirmed transactions at all. My
collected data suggests that there is very little use of BIP37 at
present, based on incomi
I'm not sure if this has been brought up elsewhere in this thread.
This proposal doesn't seem to be a complete replacement of BIP37: It
doesn't provide a filter for unconfirmed transactions like BIP37 does.
That means that most light clients will continue to use BIP37 even if
they may use this BI
22 matches
Mail list logo
