romises their key.
> > That said, I think this problem is easily fixed by adding a new user key
> to the
> > protocol with which they must sign in order for the transfer to be
> considered
> > valid on the state chain. This way, if the SE wishes to steal the funds
> (which
> &g
ernational search report rejected it on the grounds of prior
> art.
>
> Tom
>
> On Tue, Mar 31, 2020 at 11:36 AM David A. Harding wrote:
>
>> On Wed, Mar 25, 2020 at 01:52:10PM +, Tom Trevethan via bitcoin-dev
>> wrote:
>> > Hi all,
>> >
Hi all,
We are starting to work on an implementation of the statechains concept (
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
with particular interest in using the protocol enable the change of
ownership (novation) of an individual position
020 at 01:52:10PM +0000, Tom Trevethan via bitcoin-dev
> wrote:
> > Hi all,
> >
> > We are starting to work on an implementation of the statechains concept (
> >
> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
> ),
gt; > this type of system.
>> >
>> > Although I think the existence of this application is something
>> to be
>> > mindful of, there are several important things to note:
>> >
>> > 1. Although there are si
We are designing an off-chain coin-swap protocol that will work with the
statechain implementation we are developing (
https://github.com/commerceblock/mercury). The general idea is that coins
deposited with a statechain entity (statecoins) can be transacted
peer-to-peer off-chain in a way that
Hi ZmnSCPxj,
> I think the entire point of non-custodiality ***is*** trust minimization.
There are also legal and regulatory implications. It is much easier for a
service to operate without requiring its users to be KYCed if it is
non-custodial and funds cannot be frozen/seized.
> The main
Hi ZmnSCPxj,
> The SE can run in a virtual environment that monitors deletion events and
records them.
> Such a virtual environment could be set up by a rootkit that has been
installed on the SE hardware.
> Thus, even if the SE is honest, corruption of the hardware it is running
on can allow
Hi ZmnSCPxj,
Thanks for the reply.
> Okay, I suppose this is much too high-level a view, and I have no idea
what you mean by "statecoin" exactly.
Sorry, most of the protocol details are in the links, but terminology
should be made clearer. A "statecoin" is a UTXO that is a 2-of-2 between
the
Hello,
A statechain implementation and service co-signs 'backup' (off-chain)
transactions to transfer ownership of a UTXO from one owner to the next. A
suggested here
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
, this service (the statechain
chain has been
> pegged out, so pruning will be impossible. You may wish to consider some
> kind of liveness rule where one statechain transaction needs to be made per
> year. If they miss the deadline, they're just forced on-chain, which is not
> terrible, in any case.
>
> Hope t
A couple of features we are considering for the mercury statechain
wallet/service and would be good to get comments/feedback on.
1.
In the current setup (https://github.com/commerceblock/mercury), deposits
are free and permissionless (i.e. no authentication required to generate a
shared key
An update on progress on the development of the blinded two-party Schnorr
scheme for statechains.
As stated previously, we believe that one-more-signature and Wagner attacks
are mitigated by the client committing the values of the blinding nonce
used (labeled f) and the value of R2 used in a
We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
it can hold a private key that is required to generate an aggregate
signature on an aggregate public key, but that it does not learn either: 1)
The
Thanks for the replies. As I understand it, the v=2 nonces signing protocol
of musig2 prevents the Wagner attack. Also, that the challenge value c must
be blinded from the server to prevent the server from being able to
determine the signature from the on-chain state.
In addition, in order to
@Jonas
OK, thanks, I get the logic now. I believe this attack can be mitigated (at
least in the case of using this scheme for statechains) by the receiver of
a coin verifying the construction of all previous challenges.
So in this case, the sender of a coin would record R2[K-1] in addition to m
Hi Jonas,
Seems you are right: for every tx, compute c from the on-chain data, and
the server can match the c to the m (tx). So there would need to be a
method for blinding the value of c.
On Mon, Jul 24, 2023 at 4:39 PM Jonas Nick wrote:
> > Party 1 never learns the final value of (R,s1+s2)
egards,
>> ZmnSCPxj
>>
>>
>> Sent with Proton Mail secure email.
>>
>> --- Original Message ---
>> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
&
r scheme has only one `R` per party, would it not be vulnerably to that
> attack?
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
> bitcoin-dev@lists.linux
A follow up to this, I have updated the blinded statechain protocol
description to include the mitigation to the Wagner attack by requiring the
server to send R1 values only after commitments made to the server of the
R2 values used by the user, and that all the previous computed c values are
gt; owner prove the knowledge of a non-identifying secret he learned as
> recipient to the server that is related to the statechain tip?
>
> BR,
> moonsettler
>
> --- Original Message ---
> On Monday, August 7th, 2023 at 2:55 AM, Tom Trevethan via bitcoin-dev <
> b
f wagner's attack.
>
> LL
>
> On Wed, 9 Aug 2023 at 23:34, Tom Trevethan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> @moonsettler
>>
>> When anyone receives a coin (either as payment or as part of a swap) they
>> need to
Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
knowledge of the r values used to generate each R used prevents the Wagner
attack, no?
On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick wrote:
> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an
> attack
@moonsettler
Your scheme for blinding the challenge (e in your notation) works as far as
I can tell. It is better than the way I suggested as it doesn't require
modifying the aggregated pubkey (and the blinding nonce can be different
for each signature).
@AdamISZ and @Jonas
It is not
The submitpackage RPC is available on regtest in the current core release.
Is there any plan or timeline for deploying this on mainnet in the next
release? Can't find any recent discussion. It would be very helpful given
current (and likely future) issues with mempool purge.
Tom
25 matches
Mail list logo
