Bitcoin Core may send "reject" messages as response to "tx", "block" or
"version" messages from a network peer when the message could not be accepted.
This feature is toggled by the `-enablebip61` command line option and has been
disabled by default since Bitcoin Core version 0.18.0 (not yet
Hello list,
For the last few weeks I've been working on a literature review for
bitcoin privacy:
https://en.bitcoin.it/wiki/Privacy
It aims to cover about all privacy issues in bitcoin, including
Lightning network, and has a bunch of examples to help demonstrate how
the concepts work in
Hi all,
Just fyi, but this bitcoin-dev mailing list has been down for a few weeks.
It's currently hosted by Linux Foundation, and they are slowly deprecating
their support for email. We will have to find an alternative service
provider for the mailing list moving forward. I have received a
Hello all,
This might be another proto-BIP similar to the post about using a card
shuffle as a wallet seed that was posted here a few weeks back:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016645.html
This is an idea I had to deriving a wallet seed from the lucky
Hi,
I don't know if this is the right place to do so, but it says on the
website to first propose ideas for BIPS to the mailing list.
I would like to propose @bitficus idea for a satoshi symbol (monetary).
The idea has been floated around to switch to satoshi as a base unit.
The lightning
> On 20 Feb 2019, at 4:24 AM, Luke Dashjr wrote:
>
> Even besides NOINPUT, such a wallet would simply never show a second payment
> to the same address (or at least never show it as confirmed, until
> successfully spent).
This is totally unrelated to NOINPUT. You can make a wallet like this
Even besides NOINPUT, such a wallet would simply never show a second payment
to the same address (or at least never show it as confirmed, until
successfully spent).
At least if tx versions are used, it isn't possible to indicate this
requirement in current Bitcoin L1 addresses. scriptPubKey
This only depends on the contract between the payer and payee. If the contract
says address reuse is unacceptable, it’s unacceptable. It has nothing to do
with how the payee spends the coin. We can’t ban address reuse at protocol
level (unless we never prune the chain), so address reuse could
On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
> While this seems fully compatible with eltoo, is there any other proposals
> require NOINPUT, and is adversely affected by either way of tagging?
Yes, this seems to break the situation where a wallet wants to use NOINPUT
Trying the four possible options (p2pkh compressed, p2pkh uncompressed,
seg3, and bech32) is certainly a possibility and in fact, that's what I
ended up doing because not every wallet implements something like this, but
if there is a header field currently in use, it seemed reasonable to me to
use
The proposal includes actual code that does verification, but I didn't
include code for signing. I thought it could be inferred, but I could at
least include a description of how to sign. I am not sure exactly what part
you are referring to by "keys speech", but the signatures are done by ECDSA
Ah, OK, that's of course a good thing to document this undocumented (and
strange) stuff, as a matter of fact I implemented it after reading your
post (because this was on my todo list since some time) and got annoyed
quickly, mainly by what is doing formatMessageForSigning (which is quite
trivial
Then, since you wrote this proposal, maybe you should add the very
precise description of the signing/verification process since it is
documented nowhere
I don't get the use of the speech regarding keys while it should focus
on signatures which are summarized in a vague sentence inspired by your
See https://gist.github.com/laanwj/4fe8470881d7b9499eedc48dc9ef1ad1 for
formatted version,
Look under "Considerations" for topics that might still need to be discussed.
BIP: ???
Layer: Peer Services
Title: addrv2 message
Author: Wladimir J. van der Laan
Comments-Summary: No comments
14 matches
Mail list logo
