Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
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: > https://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565 > > However I remember that someone told me the tick method had a flaw.. Maybe the use of `SIGHASH_NONE` for both inputs of the TxOut transactions? Also txid malleability. The first can be fixed by not using `SIGHASH_NONE` for one of the inputs and requiring a hot privkey to sign with that. The second can be fixed by using SegWit outputs. Regards, ZmnSCPxj > > > On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev > wrote: > > > Does revaulting vault up with the same keys, or new ones? > > > > Are they new derivation paths on the same key? > > > > Would love some expanded explanation on how you’re proposing this would > > work. > > > > Thanks, > > Dustin > > > > On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev > > wrote: > > > > > 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. If the user was unaware of the theft of the key, then > > > the attacker could steal the funds after the delay period. > > > > > > To mitigate this, it is important to choose a stipend or withdrawal > > > amount per withdrawal period like x% of the funds. This limits the > > > total stolen funds to x% because once the funds are stolen the user > > > would know their hot key is compromised, and the user would know to > > > instead use one of the other clawback paths during all of the future > > > withdrawal delay periods instead of letting the delay timeout all the > > > way to the (stolen) default/hot key. > > > > > > The reason why a loss limiter is the way to go is because there's > > > currently no way (that I am aware of, without an upgrade) to force an > > > attacker to reveal his key on the blockchain while also forcing the > > > attacker to use a timelock before the key can spend the coins. I am > > > curious about what the smallest least invasive soft-fork would be for > > > enabling this kind of timelock. There are so many covenant proposals > > > at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY, > > > ). Or there's crazy things like a fork that enables a transaction > > > mode where the (timelock...) script of the first output is > > > automatically prefixed to any of the other scripts on any of the other > > > outputs when an input tries to spend in the future. A thief could add > > > his key to a new output on the transaction and try to spend (just like > > > a user would with a fresh/rotated key), but the OP_CSV would be > > > automatically added to his script to implement the public observation > > > delay window. > > > > > > Also, there was other previous work that I was only informed about > > > today after posting my proposal, so I should mention these as related > > > work: > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html > > > https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better > > > https://www.youtube.com/watch?v=diNxp3ZTquo > > > https://bitcointalk.org/index.php?topic=5111656 > > > > > > - Bryan > > > http://heybryan.org/ > > > ___ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
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 < bitcoin-dev@lists.linuxfoundation.org> wrote: > Does revaulting vault up with the same keys, or new ones? > > Are they new derivation paths on the same key? > > Would love some expanded explanation on how you’re proposing this would > work. > > Thanks, > Dustin > > On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 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. If the user was unaware of the theft of the key, then >> the attacker could steal the funds after the delay period. >> >> To mitigate this, it is important to choose a stipend or withdrawal >> amount per withdrawal period like x% of the funds. This limits the >> total stolen funds to x% because once the funds are stolen the user >> would know their hot key is compromised, and the user would know to >> instead use one of the other clawback paths during all of the future >> withdrawal delay periods instead of letting the delay timeout all the >> way to the (stolen) default/hot key. >> >> The reason why a loss limiter is the way to go is because there's >> currently no way (that I am aware of, without an upgrade) to force an >> attacker to reveal his key on the blockchain while also forcing the >> attacker to use a timelock before the key can spend the coins. I am >> curious about what the smallest least invasive soft-fork would be for >> enabling this kind of timelock. There are so many covenant proposals >> at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY, >> ). Or there's crazy things like a fork that enables a transaction >> mode where the (timelock...) script of the first output is >> automatically prefixed to any of the other scripts on any of the other >> outputs when an input tries to spend in the future. A thief could add >> his key to a new output on the transaction and try to spend (just like >> a user would with a fresh/rotated key), but the OP_CSV would be >> automatically added to his script to implement the public observation >> delay window. >> >> Also, there was other previous work that I was only informed about >> today after posting my proposal, so I should mention these as related >> work: >> >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html >> >> https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better >> https://www.youtube.com/watch?v=diNxp3ZTquo >> https://bitcointalk.org/index.php?topic=5111656 >> >> - Bryan >> http://heybryan.org/ >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
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 parent vault. The re-vaulting > transaction is > > broadcasted when someone wants to prevent a coin withdrawal during > the public > > observation delay period. The re-vaulting transaction spends the > delayed-spend > > transaction outputs. It has a single output with a script created by > running > > the entire vault setup function again. Hence, when the re-vaulting > transaction > > is confirmed, all of the coins go back into a new > identically-configured vault > > instead of being relinquished through the delayed-spend transaction > timeout for > > hot wallet key signing. > > As transactions need to be signed in reverse order, it seems to me that > there is a practical limit in the number of times a vault can be used. > Basically, the number of times we run the vault setup function is the > limit on number of re-vaultings possible. > > Is my understanding correct? > Yes, that is correct. When setting up the vault, plan it "all the way to the end" like next 100+ years. With exponential backoff on the relative timelock values, the total number of pre-signed transactions isn't really that high. With a few thousand pre-signed transactions (more than enough), you can have high resolution timelocks well into the future. On Wed, Aug 7, 2019 at 4:19 PM Dustin Dettmer wrote: > Does revaulting vault up with the same keys, or new ones? > Are they new derivation paths on the same key? > Honestly, no idea. The answer to that might depend on each individual vault user. If the user doesn't want to deal with the expense of managing a bunch of unique keys and other data, then it might make more sense to use the same values and have a small blob that has to be stored for a long time, rather than many different blobs stored in different places to deal with. - Bryan http://heybryan.org/ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
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 someone wants to prevent a coin withdrawal during the > public > observation delay period. The re-vaulting transaction spends the > delayed-spend > transaction outputs. It has a single output with a script created by > running > the entire vault setup function again. Hence, when the re-vaulting > transaction > is confirmed, all of the coins go back into a new identically-configured > vault > instead of being relinquished through the delayed-spend transaction > timeout for > hot wallet key signing. As transactions need to be signed in reverse order, it seems to me that there is a practical limit in the number of times a vault can be used. Basically, the number of times we run the vault setup function is the limit on number of re-vaultings possible. Is my understanding correct? Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
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 there's a cryptographic way to prove that muSig and > > 2P-ECDSA have not been used to create a certain pubkey/signature. > > In the second scheme, to revoke/spoil the bond, the entity that > controls one TXO participating in this bond needs to simply prove that > it somehow controls/have the ability to spend that TXO. > > In shared ownership rent scheme that ZmnSCPxj described in [1], > the 'TXO rentier' has a signed timelocked 'backout' transaction that > spends the locked TXO, and assigns the reward to rentier. > > If we say that any transaction that spends any TXO in the bond > (ignoring the timelock), invalidates the bond when presented to > takers, then TXO rentier can revoke the bond by simply > publishing this transaction (not to the blockchain, but by some other > means so that takers can receive it). > > The transaction validity can be verified, with the relaxed rules that > ignores the timelock. After it is verified, takers mark the whole > bond as revoked and will not consider it when chosing makers. > > One inconvenience here is that takers need to store the > data about revoked bonds. But it seems to me that there's no need > for that information to be synchronized between the participants > instantly. It is enougth for takers to get the revoked-set eventually. > > The rentier are still incentivized to not spoil the bond, to receive > the profit. Their funds are locked anyway. > > But if the goal of the 'rentier' is to attack the attacker, the > opportunity cost of these locked funds is the cost of the attack. > > If the renter rents TXOs from several entities to include in one bond, > revocation by one rentier spoils whole bond, and the total loss for all > participants is bigger than the oportunity cost of locked funds of a > single rentier that made the revocation. > > The possibility of such revocation increases risk for the renter and > would-be co-rentiers, and is likely limit the possible scale of such > TXO-renting operation. This is quite a clever solution. Let me then attempt to break it. It is possible to encrypt data in such a way that it requires sequential operations in order to decrypt. https://www.gwern.net/Self-decrypting-files This basically allows us to encrypt some data in such a way that its decryption is timelocked, by requiring a large number of sequential operations to decrypt. It also seems to me (I am not a cryptographer) that it may be possible to present a ZKP that an encrypted text, encrypted using the above timelock decryption, is a signature of a particular message with a particular public key. Thus, we can change the ritual to this: 1. I contact two lessors to aggregate their coins into a larger UTXO and thus break V^2. 2. We create a funding transaction that pays to a locked bond address, with a pubkey equal to a MuSig among us. This spends the TXOs they want to lease out, as well as some of my funds to be used for paying for rent. We do not sign this yet. 3. We create a backout transaction that returns the bond to both lessors, plus their rent. We partly perform the MuSig ritual to sign this transaction, with me as the last step. 4. Instead of providing the completed signature to the lessors, I encrypt it using the above timelocked encryption. I provide this encryption and a zero-knowledge proof that I have actually completed the signature ritual correctly and that the timelocked-encrypted text has the signature as plaintext. 5. The lessors now know they can acquire the signature by simply grinding the timelocked encryption. This allows them to recover their money by the appointed time. 6. We then exchange signatures for the funding transaction and broadcast and confirm it. Now, the lessors cannot provide a valid timelocked transaction, as they do *not* yet have a complete signature; thus they cannot snitch about my aggregation of their funds. At the same time, they know that the timelocked encryption allows them to eventually get a complete signature and recover their funds. I can defray this cost of processing by increasing my rent slightly. Now of course we can just go one step further and also allow bonds to be snitched by presenting the timelocked-encrypted text and the ZKP that it contains the signature for a timelocked transactions. But it seems to me that there is more than one way to skin this particular cat, thus unless all ways to create provable timelocked encryptions are enumerable, it would be possible to get around. (though of course it is dependent on a ZKP being possible for a timelocked encryption) Finally, aggregation is still possible to insure by off-blockchain agreements, possibly with
Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
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. If the user was unaware of the theft of the key, then the attacker could steal the funds after the delay period. To mitigate this, it is important to choose a stipend or withdrawal amount per withdrawal period like x% of the funds. This limits the total stolen funds to x% because once the funds are stolen the user would know their hot key is compromised, and the user would know to instead use one of the other clawback paths during all of the future withdrawal delay periods instead of letting the delay timeout all the way to the (stolen) default/hot key. The reason why a loss limiter is the way to go is because there's currently no way (that I am aware of, without an upgrade) to force an attacker to reveal his key on the blockchain while also forcing the attacker to use a timelock before the key can spend the coins. I am curious about what the smallest least invasive soft-fork would be for enabling this kind of timelock. There are so many covenant proposals at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY, ). Or there's crazy things like a fork that enables a transaction mode where the (timelock...) script of the first output is automatically prefixed to any of the other scripts on any of the other outputs when an input tries to spend in the future. A thief could add his key to a new output on the transaction and try to spend (just like a user would with a fresh/rotated key), but the OP_CSV would be automatically added to his script to implement the public observation delay window. Also, there was other previous work that I was only informed about today after posting my proposal, so I should mention these as related work: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better https://www.youtube.com/watch?v=diNxp3ZTquo https://bitcointalk.org/index.php?topic=5111656 - Bryan http://heybryan.org/ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
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 a transaction setup scheme that binds both the user and the attacker to always using a public observation and delay period before a weakly-secured hot key is allowed to arbitrarily spend coins. This is the same definition previously used[1]. During the delay period, there is an opportunity to initiate recovery/clawback which can either trigger deeper cold storage parameters or at least reset the delay period to start over again for the same keys. One of the important components of this is the delete-the-key pre-signed transaction concept, where only a single transaction is (pre)signed before deleting the key. This is basically an emulation of a covenant and enforces a certain outcome. Background and motivation = I was looking at Eyal and Sirer's 2016 vaults paper [1], and I saw this headscratcher: > Vault transactions use a delay mechanism. We note that vault transactions > cannot be implemented with existing timing mechanisms such as > CHECKLOCKTIMEVERIFY opcode or transaction locktime. This was probably written before the introduction of OP_CHECKSEQUENCEVERIFY. Still, a viable construction would have more steps than just using OP_CSV. They were probably not thinking about what those steps might be, because in the context of the paper they were proposing a bitcoin vault implemented using recursive consensus-enforced covenants via a new opcode, which obviously cannot be deployed without an upgrade fork. Covenants have been discussed for years, but require new opcodes or other consensus-enforcement changes. Relative locktimes are useful here because there is no knowledge as to when the transactions might be broadcasted in the future. The delays need to be relative to after the transaction is included in the blockchain, not to setup initialization time. Also, from [2]: > We show that a [vault transaction] mechanism is currently not possible in all > cryptocurrencies [...] Bitcoin's scripting language requires support for > covenants. I haven't seen any previous proposal for how to implement recursive bitcoin vaults without a fork and without a covenant. After asking around, I am pretty sure this is somewhat novel. The closest I guess is [3]. Vaults are particularly interesting as a bitcoin cold storage security mechanism because they enable a publicly observable delay period during which time a user could be alerted by a watchtower that a thief might be in the process of stealing their coins, and then the user may take some actions to place the coins back into the vault before the relative timelock expires. There seems to be no way to get this notification or observation period without a vault construction. It might have been assumed it required a covenant. Having a vault construction might go a long way to discourage would-be attackers, on principle that the attacker might be incapable of recovering their cost-of-attack because the recovery mechanism can lock up the coins indefinitely. Griefing or denial-of-service would still be possible, of course, but with multisig there might be some ways to put a halt to that as well. I am working under the assumption that the attacker knows that the user is a vault user. Vaults == The idea is to have a sequence of pre-generated pre-signed transactions that are generated in a certain way. The basic components are a vaulting transaction that locks coins into a vault, a delayed-spend transaction which is the only way to spend from a vault, and a re-vaulting transaction which can recover/clawback coins from the delayed-spend transaction. The security of this scheme is enforced by pre-signing transactions and deleting private keys, or with the help of SIGHASH_NOINPUT then there's another scheme where private keys are provably never known. This enforces that there's only a specific set of possible outcomes at every step of the vault. Some examples of what the set of broadcasted transactions might look like in regular usage: coins -> VT -> DST -> exit via hot wallet key coins -> VT -> DST -> RVT coins -> VT -> DST -> RVT -> DST -> ... coins -> VT -> ... -> RVT998 -> nuclear abort where: VT = vault transaction DST = delayed-spend transaction RVT = re-vaulting transaction The delayed-spending transaction would have a single output with a script like: ( 30 days AND hot wallet key OR 10 days AND re-vaulting public key OR 1 day AND 4-of-7 multisig OR 0 days and super-secure nuclear abort ragequit key ) Another diagram: VT_100 -> DST -> (optionally) RVT -> coins are now in VT_99 VT_99 -> DST -> (optionally) RVT -> coins are now in VT_98 ... VT_1 -> burn-all-coins nuclear abort ragequit
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
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 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 new wallets to be created and hodlers must trust the > wallets enough to move their coins and hold them there for a long time. Possibly not so much? The wallet need only sign two things: 1. The fidelity bond itself. 2. The backout transaction. Both can be done in a single session, then the private key involved can be erased permanently from memory. Only the signature for the backout needs to be stored, and this can be safely stored without encryption by publishing to any cloud service --- others getting a copy of the signature does not let them change the signature to authorize a different transaction. It would be enough to write the signing code in C and use special OS calls (which most languages higher than C do not expose) to allocate memory that will never be put in swap. Then generate the private key using that memory, then clear it after usage before deallocating to the OS. I believe `libsecp256k1` makes this easy. Unless part of the bond process requires that the taker do a challenge "sign this random nonce for me", but of note is that it would have to impose this on all makers. But if so, consider again this: 1. There exists two non-spying makers with nearly-equal bond values. 2. These makers need to keep their bond private keys in hot storage. 3. I approach both makers and offer to aggregate their bond values, forming a new bond with 4x the weight of their individual bonds, and split up the increased earnings between us. This can be made noncustodial by use of smart contracts on Bitcoin. 4. It is no different from the point of view of both makers: they still need to keep their bond private keys in hot storage. But this way earns them more money than operating as non-spying makers. 5. I earn not only the fees for JoinMarket, I also earn additional fees for spying on CoinJoins. It still seems to me that adding the V^2 tweak weakens the bond system, not strengthens it. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
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. At the cost of *greatly* strengthening aggregation. Suppose there is currently many makers, all with roughly-equal bonds. Suppose I were to approach two of these makers, and offer to aggregate their bonds. The combined bond would, because of the V^2 term, have 4 times the weight of the other makers. Thus, approximately I can earn a little below 4 times what one other maker does. I offer 1.5x what one maker does to both of those makers and keep a little below 0.5x to myself. So: 1. I earn without putting any of my money into bonds. I just need starting capital to pre-pay for the rents. 2. I get to learn a little below 4x more CoinJoins than other makers. This increases my earnings further since I can sell this privacy information, and I also get an advantage compared to other non-aggregating spies. It seems to me not to fix the root issue, i.e. makers who make for the purpose of gathering privacy information, even if it might fix sybil attackers. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
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 increasing the non-linearity to V^2 worsens the pooling pressure, not lessens it. (I wonder if instead going the opposite way and doing V^0.999 might work better; I have not figured all the implications of such a scheme and leave it to the reader.) > Unfortunately, both described schemes fail the same way as > 'require TXOs to be consolidated by the owner', by the fact that with > muSig, shared ownership of TXO is possible, as explained by ZmnSCPxj in > [1]. 2P-ECDSA is also possible, just more complex, so just saying 'ban > musig for the bonds' is not the answer, I believe. If my understanding is correct, efforts to expand ECDSA to more than two-party n-of-n "true" multisignatures already are ongoing. One might attempt to use transaction malleability as a protection, and require that transactions that put up bond TXOs should spend from at least one ***non***-SegWit output, so that the scheme as described fails (as the funding txid is malleable after-the-fact). But the scheme as described only considers ways to securely aggregate *within* the Bitcoin universe. I have recently learned of a spacce called the "real world", wherein apparently there exist things as "contract law". It seems to me this "contract law" is a half-baked implementation of Bitcoin cryptographic smart contracts. By what little I understand of this "contract law", it would be possible for an aggregator to accept some amount of money, with a promise to return that money in the future with some additional funds. If the aggregator fails to uphold its promise, then some (admittedly centralized) authority entity within the "real world" then imposes punishments (apparently inspired by similar mechanisms in Lightning Network) on the aggregator. Such arrangements (accepting some money now with a promise to return the money, plus some interest earned, in the future) apparently already exist in this "real world", under the name of "time deposits". Regards, ZmnSCPxj > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017217.html > > В Wed, 7 Aug 2019 01:55:41 +0500 > Dmitry Petukhov d...@simplexum.com wrote: > > > В Mon, 5 Aug 2019 20:04:26 +0100 > > Chris Belcher belc...@riseup.net wrote: > > > > > So what's needed is a way to make renting out TXOs impossible or > > > very difficult. > > > > You can make renting the TXOs risky for the attacker. Make it so that > > the entity that rented out the TXO can revoke the participation of > > said TXO in the market, by publishing some special signature. That > > act of revocation can also mean revocation of all other TXOs that > > were used in a bond alongside it. This way, any entity that wants to > > spoil an attacker's consolidation via rent, can rent out its TXO to > > the attacker, and then revoke it, spoiling the whole package the > > attacker have consolidated. > > There may be other way to impose penalties. > > For example, all locked TXO may be required to be spendable by any > > key that controls any TXO in the 'bond TXO package'. I think this > > should be possible with taproot - you will have to publish a taproot > > trees for your locked TXOs (say, N of them), and the tree for each TXO > > will have N leaves, each leaf will specify a condition "spendable by > > the key N". This way, if I give you my TXO to include it in a bond by > > locking it, you also need to make your other TXOs in a bond spendable > > by me. > > For both scenarios to work for the attacker, there's need to be an > > off-chain contractual relationship between the parties. Otherwise the > > entity that rents out the TXOs can spoil or just confiscate the bond > > of the entity that rented them, without reprecussions. > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: Discover and move your coins by yourself
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 - decode/create multisig redeem scripts - pubkey/privkey mapping , conversion and formats - sign/verify messages Browserifying everything now for the end of the month Message transféré Sujet : Discover and move your coins by yourself Date : Fri, 12 Jul 2019 20:35:00 +0200 De :Aymeric Vitte Pour : Bitcoin Dev Please see https://github.com/Ayms/bitcoin-transactions this is a merge of former bitcoin-transactions and bitcoin-wallets nodejs modules with additional features to be implemented as described in the README It is financed by NLnet via EU Horizon 2020 Next Generation Internet Search and Discovery call So the initial dev fees have been removed and the code is now open source and provided in clear under a MIT license The intent is to provide all the necessary tools for anybody to discover and manage their coins, as well as making transactions by themselves, without having to sync a full node or as an alternative to wallets when people don't understand where their coins are (we saw quite a lot of confusion for people not understanding at all how to find their coins and to what keys their addresses did relate in case of multisig, segwit and now bech32) It's somewhere bitcoin-cli outside of bitcoin core more easy to use and not restricted to its own wallet, available for any bitcoin based coins At the end it will be a secure standalone offline js webapp inside browsers (like https://peersm.com/wallet but the app does not reflect the current state of the nodejs repo) It's not a remake of iancoleman's tool but of course some features overlap, as well as for other existing tools, we will also extend all of this inside one tool with no limitations (for example some tools do not accept "invalid" bip39 seeds, or bip32 seeds, etc) Comments/suggestions welcome PS: initially sent to bitcoin-discuss but the list seems to be dead -- Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
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 new wallets to be created and hodlers must trust the wallets enough to move their coins and hold them there for a long time. Requiring fidelity bond TXOs to be held in hot wallets can also be beaten as a scheme for stopping renting, because the rentee can put their coin private keys on an always-on raspberry pi which is connected to the maker's computer and constantly ready to give out signatures. The coins would be in hot wallets yet still be rented out. As above the raspberry pi setup would be much more of a hassle than copypasting a signature into a website, so it could still be worth doing. I wonder if there's a cryptographic way to prove that muSig and 2P-ECDSA have not been used to create a certain pubkey/signature. On 06/08/2019 22:37, Dmitry Petukhov wrote: > Unfortunately, both described schemes fail the same way as > 'require TXOs to be consolidated by the owner', by the fact that with > muSig, shared ownership of TXO is possible, as explained by ZmnSCPxj in > [1]. 2P-ECDSA is also possible, just more complex, so just saying 'ban > musig for the bonds' is not the answer, I believe. > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017217.html > > В Wed, 7 Aug 2019 01:55:41 +0500 > Dmitry Petukhov wrote: > >> В Mon, 5 Aug 2019 20:04:26 +0100 >> Chris Belcher wrote: >> >>> So what's needed is a way to make renting out TXOs impossible or >>> very difficult. >> >> You can make renting the TXOs risky for the attacker. Make it so that >> the entity that rented out the TXO can revoke the participation of >> said TXO in the market, by publishing some special signature. That >> act of revocation can also mean revocation of all other TXOs that >> were used in a bond alongside it. This way, any entity that wants to >> spoil an attacker's consolidation via rent, can rent out its TXO to >> the attacker, and then revoke it, spoiling the whole package the >> attacker have consolidated. >> >> There may be other way to impose penalties. >> >> For example, all locked TXO may be required to be spendable by *any* >> key that controls any TXO in the 'bond TXO package'. I think this >> should be possible with taproot - you will have to publish a taproot >> trees for your locked TXOs (say, N of them), and the tree for each TXO >> will have N leaves, each leaf will specify a condition "spendable by >> the key N". This way, if I give you my TXO to include it in a bond by >> locking it, you also need to make your other TXOs in a bond spendable >> by me. >> >> For both scenarios to work for the attacker, there's need to be an >> off-chain contractual relationship between the parties. Otherwise the >> entity that rents out the TXOs can spoil or just confiscate the bond >> of the entity that rented them, without reprecussions. > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
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 the same > pooling pressure. > Deliberately increasing the non-linearity to V^2 worsens the pooling > pressure, not lessens it. > > (I wonder if instead going the opposite way and doing V^0.999 might work > better; I have not figured all the implications of such a scheme and leave it > to the reader.) > >> Unfortunately, both described schemes fail the same way as >> 'require TXOs to be consolidated by the owner', by the fact that with >> muSig, shared ownership of TXO is possible, as explained by ZmnSCPxj in >> [1]. 2P-ECDSA is also possible, just more complex, so just saying 'ban >> musig for the bonds' is not the answer, I believe. > > If my understanding is correct, efforts to expand ECDSA to more than > two-party n-of-n "true" multisignatures already are ongoing. > > One might attempt to use transaction malleability as a protection, and > require that transactions that put up bond TXOs should spend from at least > one ***non***-SegWit output, so that the scheme as described fails (as the > funding txid is malleable after-the-fact). > > But the scheme as described only considers ways to securely aggregate > *within* the Bitcoin universe. > > I have recently learned of a spacce called the "real world", wherein > apparently there exist things as "contract law". > It seems to me this "contract law" is a half-baked implementation of Bitcoin > cryptographic smart contracts. > By what little I understand of this "contract law", it would be possible for > an aggregator to accept some amount of money, with a promise to return that > money in the future with some additional funds. > If the aggregator fails to uphold its promise, then some (admittedly > centralized) authority entity within the "real world" then imposes > punishments (apparently inspired by similar mechanisms in Lightning Network) > on the aggregator. > Such arrangements (accepting some money now with a promise to return the > money, plus some interest earned, in the future) apparently already exist in > this "real world", under the name of "time deposits". > > > Regards, > ZmnSCPxj > Good morning all, Custodial solutions are much less worrying because they introduce so much counterparty risk. It's more risky to give bitcoins in custody than for fiat money because there's no lender of last resort. People using JoinMarket in a non-custodial way will always have a larger risk-adjusted return; The return for running a JoinMarket yield generator isn't that big anyway to start with. The non-custodial renting of TXO signatures is far more worrying. 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. All things considered the consolidation of makers due to renting TXOs is not as bad as sybil attacks. Consolidation of makers means that the privacy-relevant information is shared amongst fewer people than otherwise, but at least those people are independent (otherwise they'd merge together). In a sybil attack the privacy-relevant information is not shared at all, but entirely known by just one person which is much worse. CB ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
