I find Google Groups especially repugnant not not only because what has already
been mentioned, but Google Groups has a quite clunky and annoying user
interface that makes it difficult for me to find anything or interest in there.
Usenet was migrated to Google Groups for some reason, and it's
Just like we have BIPP38 encrypted keys for singular private keys, I was
wondering if it would be possible to come up with a way to encrypt an extended
private key using reversible encryption.
BIP38 was designed with physical coins in mind, and in particular covers the
cases for lot and
Burak, I don't remember if this has been mentioned previously in the
conversation about Ark, but a disadvantage in the protocol as it is currently
is that "Ark require users to come online and "refresh" their coins every few
weeks, otherwise the ASP can sweep the funds." (putting that in quotes
Regarding this:
> Users are not so well protected during reorgs, e.g. if Bob double-spends
> a transaction whose funds were later used in a payment to Carol, then
> Carol loses the money. For this reason, Alice will probably want to
> prove to users that no funds they receive in a payment derive
Hey guys,
I'm more of the opinion that if this particular format the spam transactions
are using is addressed, it will not only cause the mempool to relax, but it
will also give us time to regroup and work on Layer 2 before the next onslaught
of spam transactions using a (slightly) different
May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev
> wrote:
>
>> probably easier just to reject any transaction where the fee is higher than
>> the sum of the outputs
>>
>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev
>> wrote:
>>
>>> Hi
Hi guys,
I think everyone on this list knows what has happened to the Bitcoin mempool
during the past 96 hours. Due to side projects such as BRC-20 having such a
high volume, real bitcoin transactions are being priced out and that is what is
causing the massive congestion that has arguable not
Hi Michael.
I read the transcript of the Socratic and I have to say that it is quite
detailed and touches a lot of problems including the well-known theft/offline
problems which also has forms elsewhere such as for passwords.
My question is, do you or anyone else in the Socratic know of any
Over the past few days I've figured out a novel way to batch transactions
together into blocks, thereby compacting the transaction size and increasing
the transactions-per-second. This is all on layer 1, without any hardforks -
only a single softfork is required to add MuSig1 support for
> I am attempting to achieve two goals with this proposal, primarily for the
> benefit of wallet users:
>
> Goal #1. Transfer labels between different wallet implementations
> Goal #2. Manage labels in applications outside of Bitcoin wallets (such as
> Excel)
>
> Much of the feedback so far has
of how they store this. Given that you can always connect together
> an output and its address or find the outputs at any address, it doesn't
> seem like it would actually leak any more information than just including
> addresses. Am I missing something?
>
> On Wed, Aug 24, 2022, 14:44 Ali
I think these problems can be mitigated if the CSV format is strictly defined,
such as how I specified it in my previous message.
In particular, the parser has to recognize only one specific header line that
has a version number somewhere, or abort - and I still insist on quoting the
labels
Hi Craig,
This a really good proposal. I studied your BIP and I have some feedback on
some parts of it.
> The first line in the file is a header, and should be ignored on import.
>From past experience and lessons, most notably BIP39, it is important that a
>version byte is defined somewhere
Besides, all silent payments are mined at the end of the day, so they are still
transactions that are included in publicly auditable blocks.
The only thing that changes from the user's point of view is that these
addresses cannot be heirarchically derived with BIP44 (or any other path for
that
This message relates to an edge case which BIP322 only partially solves, and
that is Proof of Payment.
When you make a transaction to any business, it keeps the transaction in its
records and generates an invoice so anyone can verify the transaction took
place.
When you do a P2P transaction,
Greetings list.
Following the discussions I made about BIP322 delegation on this mailing list
and in other places, I have decided that that delegation depends on a very
similar problem that arises when writing contracts and commitments. That
problem is how to implement private Multisig.
Of
Since I mailed the original scheme, some people have suggested to me that this
delegation scheme can be written in TapScript, to avoid revealing the unspent
public keys. I think that is a good idea.
Here is a very helpful slideshow about implementing Multisig scripts in Taproot
by Jimmy
(Note: I'm going to stick with this thread for all proposals for BIP322
polishing, not just delegation - unless the subject matter changes radically as
other people discuss it.)
Instead of the admittingly complicated scheme using transactions, I've created
one that utilizes multisig to make
[A similar message was posted in the Bitcointalk BIP322 thread.]
OK, I just figured out how to solve the delegation problem. It builds on Jeremy
Rubin's transaction delegation post which I linked to a few days ago.
In BIP322, there is a [planned] provision for some person to delegate signing
delegate to another
> >> scriptPubKey; needed for better privacy and CoinJoin/Lightning
> >> compatibility
>
> I need more documentation to understand this motivation.
>
> On Tue, Aug 9, 2022 at 8:46 PM Ali Sherief via bitcoin-dev
> wrote:
> > In the case of
Wait a minute. I did some lookup on OP_CHECKDATASIG to see if it's in some btc
BIP draft somewhere, and it is actually an opcode in Bitcoin Cash since some
years ago -
https://mengerian.medium.com/the-story-of-op-checkdatasig-c2b1b38e801a
I think we can safely assume that Kalle and the other
ake transaction invalid, but inside TapScript, those opcodes are defined as
> OP_SUCCESS, and make things automatically valid.
>
>
> On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev
> wrote:
> > Although there is a Github issue/PR at
> > https://github.com/bitc
Although there is a Github issue/PR at
https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items of
BIP322, I decided to throw it in the mailing list again to see if anyone else
has suggestions for dealing with them.
So in an older copy of the draft at
It would probably only work out if each output got their own private keys,
since otherwise Alice can't share any outputs with Bob and vice versa.
The whole thing sounds like an HTLC with an additional trading of private keys
for the actual trades instead of in the HLTC. How are they going to
h more obvious to everyone.
>
> On Thu 4. 8. 2022 at 17:49, Ali Sherief via bitcoin-dev
> wrote:
>
>> Hi,
>>
>> I have created a new BIP, called notatether-signedmessage. It can be viewed
>> at
>> https://github.com/ZenulAbidin/bips/blob/master/bip-notate
> IMO, there is no benefit to an additional message signing standard, especially
> one that doesn't address the problems with the current standard or (at
> present) BIP322.
In that case, I propose the following:
- I scrap the Taproot/Schorr and the two extensions inside the BIP, which will
Also, I forgot to write in the previous message, that this BIP is not a
standard - that's the reason I raised the N+1 problem in the first place. As
mentioned previously, it's strictly limited to a reference manual - which
could've been hosted anywhere else (such as my own website), but these
elp Kalle out with BIP 322?
>
> https://github.com/bitcoin/bips/pull/1347
>
>
> On Thursday 04 August 2022 12:18:56 Ali Sherief via bitcoin-dev wrote:
>
> > Hi,
> >
> > I have created a new BIP, called notatether-signedmessage. It can be viewed
> > at
My sincere apologies, the link returns a 404 (trailing dot). The correct link
to the BIP is
https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki
-Ali
--- Original Message ---
On Thursday, August 4th, 2022 at 3:18 PM, Ali Sherief
wrote:
> Hi,
>
> I
Hi,
I have created a new BIP, called notatether-signedmessage. It can be viewed at
https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki.
For those who want a quick summary, it defines a step-by-step process for
signing and verifying messages from legacy,
ets I have seen did
not have a sign message feature, not even for legacy addresses.
- Ali
--- Original Message ---
On Thursday, July 28th, 2022 at 3:27 PM, Pieter Wuille
wrote:
> --- Original Message ---
> On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-de
Here is an except of the BIP-notatether-messageverify thread, where I
contemplate how to implement address/message signing support for Taproot i.e.
Schnorr signatures, in my post at:
https://bitcointalk.org/index.php?topic=5407517.msg60642144#msg60642144
(stripped of bbcode formatting)
==
Hi guys, I have created a discussion thread for my draft BIP related to message
verification on BitcoinTalk: https://bitcointalk.org/index.php?topic=5407517.0
Feel free to read it and contribute if you wish.
- Ali
___
bitcoin-dev mailing list
Well, if there are wallets that are already verifying BIP137 signatures, a
universal BIP that encompasses all signatures would also have to check for
BIP137 signatures obviously. Can't have an all-encompassing BIP that excludes
some signature types.
Fortunately, as is the case for my original
Hi Peter,
> COLDCARD makes signatures exacly like that, when told to sign with a segwit
> address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>
> Unfortunately, I do not
[my third attempt at getting this message through. Surprisingly, I managed to
send this at the second try with the correct SMTP, From, To and all, but maybe
it was caught in GreyListing (protonmail).]
I was thinking about creating a BIP to address the lack of standardization for
Segwit message
n
> and transaction fee useful too. However, this requires changes to the
> chain notifications in interfaces/chain.h.
>
> [0]: https://github.com/bitcoin/bitcoin/pull/23624
> [1]:
> https://github.com/bitcoin/bitcoin/pull/23624/files#diff-ac4b2d3a8de2c4dd41ad9d75505ea6ce4dc87a476710a9
This has also been posted on Bitcointalk forum:
https://bitcointalk.org/index.php?topic=5373341.msg58539261#msg58539261 I have
republished it here hoping someone more knowledgeable can post some insight
about this.
It appears that the ZeroMQ topic I'm listening to, "rawtx", not only emits
I am using Bitcoin Core's HTTP RPC server as a basis for my own application.
While browsing the source code of src/httprpc.cpp, I notice that the
InterruptHTTPRPC function
https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/httprpc.cpp#L310-L314
just calls
This is an interesting read: https://bitcointalk.org/index.php?topic=5348856.0
So according to this, somebody is spamming the bitcoin network with addr
message pointing to invalid addresses and ports, which bloats the peers.dat and
corresponding structure in memory.
Since peers.dat uses a
40 matches
Mail list logo
