Hi list,
I've recently spent a lot of time thinking about "PathCoin" ([1] - but I
wouldn't recommend reading that *first*, for reasons that will become clear).
[3]
I realized that my earlier conceptions were way too specific and there is a
wide range of possibilities for transferring coins in
Hi Antoine, Zman and list,
The whole line of thinking here is interesting but indeed my first question was
"who does the penalty of the actuary go to?" and yeah, it seems we're still
fairly stuck there.
re:
> However, the amount of satoshis that should be locked in such fidelity bonds
> must
Sorry for yet another message but:
It just occurred to me that while timing correlation itself might not be much
(in usual circumstances, there are tons of other transactions), it's, as usual
with metadata, the intersection of more than one thing that could hurt: I know
when the tx happens (say
Sorry forgot to include list on this:
> Hi Dan,
> Thanks for this! I look forward to reading it in detail, these ideas are for
> sure very interesting.
>
> I wanted to immediately "nit" a point I saw as I was reading:
>
> > Because BIP 78 messages are neither authenticated nor encrypted a malic
Hi Dan,
A couple more more thoughts:
> Out of band, the receiver of the payment, shares a bitcoin URI with the
> sender including a pj= query parameter describing the relay
> subdirectory endpoint and psk= parameter with base64 encoded
> 256-bit secret key.
You're sending the symmetric secret
A reasonable attack scenario might be: attacker gains control of client machine
and its privkey, wants to extract money. It first operates passively, waiting
for user to do 2FA on a normal transaction, only modifying the nonce used in
order to achieve its goal. Then, after that 1 transaction goe
It's an interesting idea for a protocol. If I get it right, your basic idea
here is to kind of "shoehorn" in a 2FA authentication, and that the
blind-signing server has no other function than to check the 2FA?
This makes it different from most uses of blind signing, where *counting* the
number
@ZmnSCPxj:
yes, Wagner is the attack you were thinking of.
And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the R
commitments.
@Tom:
As per above it seems you were more considering MuSig1 here, not MuSig2. At
least in this version. So you need the initial commitments to R.
> I think the problem is that Alice can still move the funds even if Bob
> decrypts and broadcasts by revealing s if she gets confirmed first.
Indeed. Imagine forgetting that, couldn't be me :)
> I think you always need a multisig in these kinds of situations but it need
> not be a key aggregate
Hi Lloyd,
> Yes but suppose you do *not* create another signature adaptor or otherwise on
> m. Since you've only generated one adaptor signature on m and no other
> signatures on m there is no possibility that a signature on m that appears
> under your key would not reveal y to you. This is an
ng to rewrite
reductions(?), so perhaps more work is needed on that(?).
Cheers,Adam
Sent with [Proton Mail](https://proton.me/) secure email.
--- Original Message ---
On Monday, May 1st, 2023 at 12:37, AdamISZ via bitcoin-dev
wrote:
> Hi Lloyd,
> thanks for taking a look.
>
ey go into the challenge hash function then
> any Schnorr-like scheme that was secure before will be secure when bip32/TR
> tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to
> it. This would be cool because then we could prove all these variants secure
> for a
Hi list,
I was motivated to look more carefully at the question of the security of using
signature adaptors after recently getting quite enthused about the idea of
using adaptors across N signing sessions to do a kind of multiparty swap. But
of course security analysis is also much more importan
Hi aj and list,
(questions inline)
--- Original Message ---
On Thursday, October 27th, 2022 at 18:21, Anthony Towns via bitcoin-dev
wrote:
>
> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
> a DoS issue when utxos are jointly funded by untrusting partners, and
Hi John,
Sorry for late feedback. Very much appreciated the in depth report!
So, I second Greg's main question, which I've really been thinking about a bit
myself since starting to research this area more: it feels like the Bitcoin
protocol research community (or, uh, some of it) should focus i
--- Original Message ---
On Thursday, October 20th, 2022 at 23:08, Peter Todd via bitcoin-dev
wrote:
> On Wed, Oct 19, 2022 at 03:17:51AM +, alicexbt via bitcoin-dev wrote:
>
> > > And the
> > > impression I got from the PR review club discussion more seemed like
> > > devs makin
b778494047c86c3a7c
Sent with Proton Mail secure email.
--- Original Message -------
On Thursday, June 30th, 2022 at 22:50, AdamISZ via bitcoin-dev
wrote:
> Just a small update to those interested:
> I migrated the gist due to failures of github's new equation formatting
> feature (whi
--- Original Message -------
On Sunday, June 12th, 2022 at 18:04, AdamISZ via bitcoin-dev
wrote:
> List denizens,
>
> As per the title, a suggested protocol for doing anti-Sybil that isn't too
> demanding for the users, but actually keeps a decent level of privacy.
>
>
Sent with Proton Mail secure email.
--- Original Message ---
On Thursday, May 26th, 2022 at 12:34, AdamISZ via bitcoin-dev
wrote:
> Hi Jonas, list,
> responses inline
>
> >
> > [0] https://github.com/jonasnick/bips/pull/25
>
>
> Right, thanks, will follow
List denizens,
As per the title, a suggested protocol for doing anti-Sybil that isn't too
demanding for the users, but actually keeps a decent level of privacy.
Notice how it's mostly focused on a user/customer of a service/product/website,
but it could conceivably useful in e.g. anti-Sybil in
Hi Jonas, list,
responses inline
Sent with Proton Mail secure email.
--- Original Message ---
On Thursday, May 26th, 2022 at 10:32, Jonas Nick via bitcoin-dev
wrote:
> Thanks for the detailed feedback. Let me try to summarize your argument: Key
> aggregation should fail if there are
--- Original Message ---
On Monday, May 23rd, 2022 at 17:09, AdamISZ via bitcoin-dev
wrote:
> Jonas, all,:
>
> So I do want to ask a couple further clarifying questions on this point, but
> I got rather majorly sidetracked :)
> I wonder can you (and other list readers!)
Jonas, all,:
So I do want to ask a couple further clarifying questions on this point, but I
got rather majorly sidetracked :)
I wonder can you (and other list readers!) take a look at my attempt here to
summarize what is described in Footnote 2 of the draft BIP (as it's related to
this discussi
Jonas,
Many thanks for getting the BIP draft out. Particularly appreciate the
reference code!
I have a question about identical pubkeys (including how it relates to MuSig2*
optimization):
What is the purpose of allowing this? Isn't it always the case that N equal
keys combined with M non-equa
> > > As a better analogy: I am borrowing a piece of gold, smelting it down to
> > > make
> > > a nice shiny advertisement "I am totally not a bot!!", then at the end of
> > > the
> > > lease period, re-smelting it back and returning to you the same gold piece
> > > (with the exact same atoms c
Sent with ProtonMail secure email.
--- Original Message ---
On Tuesday, May 3rd, 2022 at 02:37, vjudeu via bitcoin-dev
wrote:
> Typical P2PK looks like that: " OP_CHECKSIG". In a
> typical scenario, we have "" in out input and "
> OP_CHECKSIG" in our output. I wonder if it is p
> I suppose ultimately this brings up the question of the scope of this BIP.
> The abstract points out that the BIP contains both a definition of address
> derivation, but also how to sign fidelity bond certificates.
>
> My feeling is that the latter might be better not included? I note that the
--- Original Message ---
On Tuesday, May 10th, 2022 at 17:54, ZmnSCPxj via bitcoin-dev
wrote:
> Good morning waxwing,
>
> Ah, yes, now I remember.
> I discussed this with Tamas as well in the past and that is why we concluded
> that in defiads, each UTXO can host at most one advertise
--- Original Message ---
On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev
wrote:
> Hello ZmnSCPxj,
>
> This is an intended feature. I'm thinking that the same fidelity bond
> can be used to running a JoinMarket maker as well as a Teleport
> (Coinswap) maker.
>
> I don't
> I really don't see a world where bitcoin goes that route. Hiding coin amounts
> would make it impossible to audit the blockchain and verify that there hasn't
> been inflation and the emission schedule is on schedule. It would inherently
> remove unconditional soundness from bitcoin and replace
the
original timelock carries over to the new group, who would have to use a
shorter one ...
Not sure, but I might update and change the gist to include this new line of
thinking, in particular in (1) above .. at least if it makes sense :)
Regards,
waxwing / AdamISZ
Sent with Proto
Mail](https://protonmail.com/) Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, January 25th, 2022 at 11:53, Billy Tetrud via bitcoin-dev
>> wrote:
>>
>>> There was a protocol someone mentioned a while back called Sabu that had
>>&g
a critical vulnerability that could be exploited by miners. This is the
> write up:
>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>
> Perhaps some of the techniques there could be combined with your id
Hello list,
I took the time to write up this rather out-there idea:
Imagine you wanted to send a coin just like email, i.e. just transfer data to
the counterparty.
Clearly this is in general entirely impossible; but with what restrictions and
assumptions could you create a toy version of it?
‐‐‐ Original Message ‐‐‐
On Monday, 23 November 2020 00:40, AdamISZ via bitcoin-dev
wrote:
> Canvassing opinions/critiques from those working on bitcoin and related
> protocols.
>
> See the attached gist for a write-up of an outline of an idea, which is
> conceived for
Canvassing opinions/critiques from those working on bitcoin and related
protocols.
See the attached gist for a write-up of an outline of an idea, which is
conceived for joinmarket but can apply in other scenarios where there is market
for liquidity and in which privacy is a very high priority (
‐‐‐ Original Message ‐‐‐
On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev
wrote:
> How can a Bitcoin tranaction leak protocol usage ?
> * the output type (p2sh, p2wsh, ...)
> * the spending policy (2-of-3 multisig, timelock, hashlock,...)
> * outputs ordering (BIP69)
> *
> Hi, AFAIK snicker is limited to 2 party mixes for the foreseeable future.
> What makes this a useful anonymity system for cryptocurrency/Bitcoin?
>
> Thanks
>
> On 11/22/19 3:02 PM, AdamISZ via bitcoin-dev wrote:
>
> > Hi Riccardo,
> > Apologies for not answering before, t
> the 1to1 tx an higher one so there is less risk that only the coinjoin gets
> mined
> * Whit this spending strategy, the wallet initial scan does not need to be
> modified
>
> Il giorno mar 22 ott 2019 alle ore 15:29 AdamISZ via bitcoin-dev
> ha scritto:
>
>> Ju
Just to chime in on these points:
My discussions with ghost43 and ThomasV led me to the same conclusion, at least
in general, for the whole watch-only issue:
It's necessary that the key tweak (`c` as per draft BIP) be known by Proposer
(because has to add it to transaction before signing) and R
Hello list,
Here is a link for a draft of a BIP for a different type of CoinJoin I've named
'SNICKER' = Simple Non-Interactive Coinjoin with Keys for Encryption Reused.
https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79
Summary in document abstract and motivation, but also there is
41 matches
Mail list logo
