On 07/08/2019 00:33, ZmnSCPxj wrote:
> Good morning all,
>
> It might be useful to remember that there exists pressure to pool
> proof-of-work due to tiny non-linearities caused by Proximity Premium and
> Variance Discount flaws.
> Similarly, any non-linearity in any fidelity bond scheme exerts
Hi,
I have a proposal for implementing bitcoin vaults in a way that does not
require any soft-forks or other software upgrades, although it could benefit
from SIGHASH_NOINPUT which I'll describe later.
I call them pre-signed vaults.
Vault definition
Here, a vault is defined as
These are very creative schemes. At the very least they would stop the
easy mindless renting TXO method, where someone with coins on a hardware
wallet simply creates a signature and copypastes it into a website to
get free money. The workaround scheme with shared ownership of TXOs
requires brand
FYI Phase 3 is released https://github.com/Ayms/bitcoin-transactions,
features:
- create transactions
- decode transactions
- verify transactions
- convert/map addresses (including bech32)
- create/map wallets (bip32,39,44, etc), wallets recovery (missing/wrong
words) and check
-
Good morning all,
It might be useful to remember that there exists pressure to pool proof-of-work
due to tiny non-linearities caused by Proximity Premium and Variance Discount
flaws.
Similarly, any non-linearity in any fidelity bond scheme exerts the same
pooling pressure.
Deliberately
Good morning Dmitry,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Wednesday, August 7, 2019 6:05 PM, Chris Belcher via bitcoin-dev
wrote:
> These are very creative schemes. At the very least they would stop the
> easy mindless renting TXO method, where someone with
Good morning Chris,
> Also, as described in my other email
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017218.html
> starting "
> Let's say the sybil attacker...") the superlinear V^2 term is essential
> to the resistance of the fidelity bond system to sybil attacks.
Hi,
One of the biggest problems with the vault scheme (besides all of the
setup data that has to be stored for a long time) is an attacker that
silently steals the hot wallet private key and waits for the vault's
owner to make a delayed-spend transaction to initiate a withdrawal
from the vault.
Good morning Bryan,
> - Re-vaulting transaction. This is where the magic happens. The re-vaulting
> transaction is signed during transaction tree setup, before constructing
> the
> delayed-spend transaction for the parent vault. The re-vaulting
> transaction is
> broadcasted when
Good morning Dmitry,
> The first scheme - 'allow revocation of the whole bond by the key
> controlling even a single TXO in a bond' - might be more promising.
Is it?
I imagine any key can secretly be a MuSig or aggregated ECDSA key, with the
aggregator being a signatory.
>
> > I wonder if
Replying to two emails below.
On Wed, Aug 7, 2019 at 7:27 PM ZmnSCPxj wrote:
> > - Re-vaulting transaction. This is where the magic happens. The
> re-vaulting
> > transaction is signed during transaction tree setup, before
> constructing the
> > delayed-spend transaction for the
Good morning Sergio,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, August 8, 2019 10:09 AM, Sergio Demian Lerner via bitcoin-dev
wrote:
> Seems to be comparable to the proposed "Tick Method" from 2013:
>
Seems to be comparable to the proposed "Tick Method" from 2013:
https://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565
However I remember that someone told me the tick method had a flaw..
On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <
13 matches
Mail list logo
