On 07/11/2023 16.37, Bryan Bishop via bitcoin-dev wrote:
We would like to request community feedback and proposals on the future
of the mailing list.
>
> [...]
Have you considered switching to Matrix? It's federated, much like
e-mail. It's censorship resistant, in the sense that any participa
I'm trying to finish off bitcoinj's implementation for sending to
taproot addresses. For this, I'd like to test against a wallet that can
receive to P2TR and spend back.
I've been trying to get a taproot address from Bitcoin Core 22.0 and
spent many hours, but in vain. Can someone please simpl
I guess then the best way to discover nodes that have reject messages
enabled is connecting/disconnecting to random nodes and send them
invalid transactions and keep the ones which reply with a reject message.
On 18/10/2019 22.53, John Newbery via bitcoin-dev wrote:
>> Is there a NODE_* bit we ca
On 16/10/2019 18.43, John Newbery via bitcoin-dev wrote:
> Following discussion on this mailing list, support for BIP 61 REJECT
> messages was not removed from Bitcoin Core in V0.19. The behaviour in
> that upcoming release is that REJECT messages are disabled by default
> and can be enabled using
(Rather than replying individually, I try to address questions and add
my remarks in one post.)
> Finally, regarding alternatives, the filter-generation code for
> BIP 157/158 has been in Bitcoin Core for some time, though the
> P2P serving side of things appears to have lost any champions
> worki
An estimated 10+ million wallets depend on that NODE_BLOOM to be
updated. So far, I haven't heard of an alternative, except reading all
transactions and full blocks.
It goes without saying pulling the rug under that many wallets is a
disastrous idea for the adoption of Bitcoin.
> well-known DoS v
On 12/03/2019 23.14, Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Mar 12, 2019 at 7:45 PM Andreas Schildbach via bitcoin-dev
> wrote:
>> These two cases are understood and handled by current code. Generally
>> the idea is take reject messages serious, but don't
(Posting again, since my previous reply didn't appear)
On 08/03/2019 01.52, Gregory Maxwell via bitcoin-dev wrote:
> That is already required because even in the presence of perfectly
> honest and cooperative hosts reject messages at most can only tell you
> about first-hop behaviour. It won't e
?
>
> Sjors
>
>> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev
>> het volgende geschreven:
>>
>> Reject messages cannot be replaced for debugging user problems. At least
>> unless you plan to make RPC or bitcoind logfiles available via
In case anyone missed the announcement: bitcoinj 0.15, with support for
native segregated witness, has recently been released.
https://groups.google.com/d/msg/bitcoinj-announce/X6Zv1NSFxOk/KJACzHZMAQAJ
For operability testing, I just released new versions 7.0 of Bitcoin
Wallet. For now, they stil
Reject messages cannot be replaced for debugging user problems. At least
unless you plan to make RPC or bitcoind logfiles available via the P2P
protocol (both probably not a good idea).
The typical case is, I get mailed a wallet logfile with reject messages
and that's all I have. I cannot access t
On 08/11/2018 09.11, Dmitry Petukhov via bitcoin-dev wrote:
>> Copying addresses to the clipboard should be discouraged, rather than
>> supported.
>
> Do you know any reasonably convenient mechanism for end user to
> transfer an address from, say, a web page to the wallet address
> input field ?
Copying addresses to the clipboard should be discouraged, rather than
supported.
It is an inherently insecure mechanism. Regardless of the OS used, any
application can monitor the clipboard for Bitcoin addresses and replace
any address with their own, usually without any specific permission or
con
Yes, I guess the quicker filter exhaustion must be the reason why
bitcoinj doesn't make use of outpoints in filters for standard
transactions. I'll look into if I can change that.
On 04/14/2018 06:14 PM, Christian Decker via bitcoin-dev wrote:
> Note that this would compound the privacy leak that
Anton, a developer on the bitcoinj maiing list, recently made me aware
[1] of a compatibility issue between segwit and BIP37 (Bloom Filtering).
The issue affects only P2WPKH and the special case of transactions
without change outputs (such as when emptying a wallet). In this case,
neither inputs n
Generally agreed. This is why I nack'ed BIP72 years ago when we
discussed about standardization.
However, there are many ways to use BIP70 without BIP72. BIP72 is just a
kludge to biggy-pack the payment protocol onto BIP21. And also, as you
note, BIP72 can be easily fixed using a hash parameter.
On 09/29/2017 11:55 AM, Peter Todd via bitcoin-dev wrote:
>>> I'm well aware. As the payment protocol hasn't caught on - and doesn't fully
>>> overlap all the usecases that addresses do anyway - I think we should
>>> consider
>>> bringing this important feature to Bitcoin addresses too.
>>
>> Has
On 09/29/2017 03:45 AM, Peter Todd via bitcoin-dev wrote:
> On Thu, Sep 28, 2017 at 12:09:59PM +0200, Andreas Schildbach via bitcoin-dev
> wrote:
>> This feels redundant to me; the payment protocol already has an
>> expiration time.
>
> I'm well aware. As the paym
On 09/28/2017 04:41 PM, Sjors Provoost via bitcoin-dev wrote:
>> The payment request message is just as one-way as an address is. It is
>> already being emailed and printed on an invoice, in fact it often acts
>> as the invoice.
>
> True and the more complicated fields, like a digital signature,
On 09/28/2017 02:43 PM, Sjors Provoost via bitcoin-dev wrote:
>> This feels redundant to me; the payment protocol already has an
>> expiration time.
>
> The BIP-70 payment protocol has significant overhead and most importantly
> requires back and forth. Emailing a bitcoin address or printing it
This feels redundant to me; the payment protocol already has an
expiration time.
On 09/27/2017 06:06 PM, Peter Todd via bitcoin-dev wrote:
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> se
On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:
> On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
>> A solution is still needed to wallets who do not wish to use BIP43
>
> What if we added another byte field OutputType for wallets that do not
> follow BIP43?
>
> 0x00 - P2PKH
Generally I like the idea, but maybe we should come up with a
(Bech32-based?) new standard that also includes the key birthdate (aka
"wallet birthdate").
Also I heard Core will mix addresses of all types on the same HD chain.
What prefix would it pick? "*pub"?
On 09/05/2017 12:25 PM, Thomas Voeg
Your BIP would take away the only way the *receiver* has to raise the
fee: CPFP. And the receiver is arguably the more important party in this
question. After all the sender has no real incentive for his payment to
be confirmed; it's receiver who has.
On 07/02/2017 10:35 PM, Rhavar via bitcoin-de
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
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
s very little use of BIP37 at
> present, based on incoming connections to nodes I know end up in the DNS
> seed responses (no "SPV" clients do their own peer management).
>
>
> On 2017-06-19 12:58, Andreas Schildbach via bitcoin-dev wrote:
>> I'm not sure
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
In order for such messages to be dispatchable between apps, I suggest
prepending with an URI scheme, similar to the already existing
"bitcoin:" scheme.
Also I suggest defining a MIME type, e.g. for usage in NFC NDEF messages
or emails.
What is the relation of this BIP to BIP21 and BIP70-72? Is th
On 04/05/2017 11:37 PM, Gregory Maxwell via bitcoin-dev wrote:
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented in hardware.
Do you plan to release details about this, or is it already documented
somewhere?
__
On 03/21/2017 08:14 PM, Peter Todd via bitcoin-dev wrote:
> On Tue, Mar 21, 2017 at 05:16:30PM +0100, Andreas Schildbach via bitcoin-dev
> wrote:
>> Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
>> In Bitcoin Wallet, I use
Why use Base 32 when the QR code alphanumeric mode allows 44 characters?
In Bitcoin Wallet, I use Base 43 (alphabet:
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ$*+-./:") for most efficient QR
code encoding. I only leave out the space character because it gets
replaced by "+" in URLs.
On 03/20/2017 10:3
On 03/06/2017 06:37 AM, Tim Ruffing via bitcoin-dev wrote:
> And is the historical rate thing really necessary
> for typical applications?
Yes, it is. Basically all incoming transactions are historical, as your
wallet is likely not online when it happens.
___
On 09/21/2016 02:58 PM, Murch via bitcoin-dev wrote:
> Android Wallet for Bitcoin
The correct name is Bitcoin Wallet, or Bitcoin Wallet for Android (if
you want to refer to the Android version).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoun
Just glancing over your BIP, I wonder if we should use Protobuf. It uses
this "flexible" format already and is quite compact/binary. We use
Protobuf already for the payment protocol, and there is very good tool
support.
___
bitcoin-dev mailing list
bitco
FWIW, BIP44 also doesn't encode a seed birthday. This needed so that SPV
wallets do not need to scan from the beginning of the blockchain.
That doesn't mean BIP44 could not be final. There are some wallets that
interoperate on that standard and that's fine. The whole reason I
insisted on separatin
On 06/22/2016 04:25 PM, Erik Aronesty via bitcoin-dev wrote:
>
> Only large merchants are able to maintain such an infrastructure; (even
> Coinbase recently failed at it, they forgot to update their
> certificate). For end users that is completely unpractical.
>
>
> Payment protocol
Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
because of its strong types, less vulnerability to malleability and very
good platform support. Having coded both, I can say Protobuf is not more
difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
based on
The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs
define balance retrieval never changes. This is to make sure you always
see the same balance on "same BIP" wallets (and same seed of course).
So if you want to add paths, it has to be a new BIP.
On 05/13/2016 03:16 PM, Daniel
r if the
> changes are non-controversial just to cut down on #of BIP’s, but thats
> not a strong preference.
>
> On Fri, Mar 11, 2016 at 3:54 AM, Andreas Schildbach via bitcoin-dev
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> I think it's a bad i
small thing? If that is the accepted
> way to go, we can split it into two and make a separate proposal.
>
> On Fri, Mar 11, 2016 at 5:48 AM Andreas Schildbach via bitcoin-dev
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> I think it's a bad idea
I think it's a bad idea to pollute the original idea of this BIP with
other extensions. Other extensions should go to separate BIPs,
especially since methods to clarify the fee have nothing to do with
secure and authenticated bi-directional BIP70 communication.
On 03/10/2016 10:43 PM, James MacWh
Discussion about reasoning of OP_RETURN aside, I think your
specification needs to be more precise/less ambiguous.
Here is what BIP70 currently says about PaymentDetails.outputs:
"one or more outputs where Bitcoins are to be sent. If the sum of
outputs.amount is zero, the customer will be asked h
On 10/26/2015 01:12 PM, Will White via bitcoin-dev wrote:
> I'm making a website to tell my bitcoin wallet program to donate to more
> than one address at a time. BIP71 needs me to include a URL to do this,
> and then the wallet has to find out the information from the URL. I'd
> prefer to just se
Very cool! Thanks for tackling this.
On 09/05/2015 04:11 PM, Ken Shirriff via bitcoin-dev wrote:
> Use of the bitcoin symbol in text is inconvenient, because the bitcoin
> symbol isn't in the Unicode standard. To fix this, I've written a
> proposal to have the common B-with-vertical-bars bitcoin
On 08/29/2015 06:31 PM, Richard Moore via bitcoin-dev wrote:
> I like the idea of having a standard for this, that all explorers (and
> even core, eventually) would understand.
>
> I would recommend 2 changes though. First, using a real URI scheme,
> blockchain:// so that we can just use normal U
On 08/21/2015 07:55 AM, Peter Todd via bitcoin-dev wrote:
> 2) Bloom filter usage has declined significantly, as lite-SPV clients
> are moving towards using centralized, trusted, servers run by the wallet
> authors. For instance
> [Mycelium](https://github.com/mycelium-com/wallet),
Hmm, the advanced QR code standards are perhaps even useful if we don't
change anything about BIP7x. Because if we can cram more data without
loosing scanning performance this maybe means also we can stay with the
data we have but improve scanning?
___
48 matches
Mail list logo
