[bitcoin-dev] Contribution
Hi, bitcoin devs. I'm working at lbry.io and we stay closely to your core,
i want to discuss what you think about a contribution like:
base_blob and/or base_uint to be derived from std::array to be enabled move
semantics, as well on uint160, uint256, COutPoint.
Another approach that bother me is acquiring / releasing recursive mutex in
a loop, snippet from minig.cpp
while (nHeight < nHeightEnd && !ShutdownRequested())
{
std::unique_ptr
pblocktemplate(BlockAssembler(Params()).CreateNewBlock(coinbaseScript->reserveScript));
CBlock *pblock = >block;
{
LOCK(cs_main); // <- acquiring
IncrementExtraNonce(pblock, chainActive.Tip(), nExtraNonce);
} // < release
std::shared_ptr shared_pblock =
std::make_shared(*pblock);
if (!ProcessNewBlock(Params(), shared_pblock, true, nullptr)) // <
acquiring / release again inside
}
Doing it in a loop makes things to be slow down even more, what's idea
behind?
Also consider using of atomic global variable rather than acquiring mutex
again, no?
Did you interested in contribution in these approaches?
Regards
Antoniy Shumanov
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
Good morning Adam, > And I'm reminded that a related point is made by belcher in the gist > comment thread iirc (after we discussed it on IRC): over time a > "PayJoin-only" merchant doing the simplest thing - using a single utxo > over and over again, will concentrate more and more funds into it, and > inevitably violating UIH2 in an increasingly dramatic fashion > (contributing a 100BTC utxo to a 0.1BTC payment etc.). Suggesting it's > better if there's a mix of payjoin/non-payjoin. To be pedantic: as I understand bustapay, it would still not violate UIH2 (unless I misunderstand UIH2). Suppose the original transaction is: (0.05 payer, 0.07 payer) -> (0.1 payee, 0.02 payer) Then bustapay with such a PayJoin-only merchant with 100BTC UTXO would give: (100 payee, 0.05 payer, 0.07 payer) -> (100.1 payee, 0.02 payer). As I understand it, this technically does not violate UIH2. It would still conceivably be interpreted as a payment of 100.1 BTC, from a payer who happens to have massively lopsided UTXOs being owned, but still does not violate UIH2. However, if that 100.1 UTXO is subsequently used to pay a 100.3 payment, then that is used to pay a 100.7 payment, that strongly suggests such a naive PayJoin-only merchant. Perhaps a simple heuristic against this would be: 1. For every UTXO you own, flip a coin. If all of them come up heads, do not payjoin; just broadcast the original transaction. 2. Else, randomly select a UTXO (value not care?) and payjoin with that UTXO. However, I have no proper analysis of the blockchain, so -- Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
On Tuesday, January 29, 2019 6:06 PM, James MacWhyte wrote: > I'm not convinced this is a valid concern, at least not valid enough to add > extra complications to the process. Signing a transaction is something a wallet needs to be able to do anyway AND at the final-step. And actually a signed transaction is _simpler_ because it's more standard and way format to send and validate. > The sender could still refuse to sign the final transaction after they see > the recipient's in-/outputs; "show me yours and I'll show you mine" isn't > much of a spy deterrent, and nothing here prevents a DOS attack. If the sender refuses to sign the final transaction, the receiver just propagates the template transaction which pays the receiver! So it's a pretty weak attack. The only real attack is that the sender could double-spend the template-transaction before it's propagated, but the cost of doing this isn't free, as at the very least you need to pay the transaction fees of creating a double spend. It's not an amazingly good defence, but it's good enough that it's unlikely to get abused (and an attacker would only learn a single utxo of the receiver) . > As an implementor, I would suggest keeping the protocol as simple as > possible. By dropping the signing in the first step, the recipient doesn't > need to maintain the ability to lookup and verify unspent outputs. Being able to verify a transaction tends to be pretty simple in practice. (e.g. `testmempoolaccept` in bitcoin core's wallet) but if it's really hard for a receiver to do, it can easily just not do it... (and assume the template transaction is valid even if it's not). But I suspect this actually complicates the job for the receiver, because now you have to deal with transaction malleability as they can now give you an invalid transaction, you sign it and then they malleate into a valid transaction with a different txid. So if you're tracking the transaction by txid, you'll get really confused...). > It also would enforce the increased privacy, which the sender obviously wants > if they are going down this path I guess that's a valid concern. A sender might want to make a payment, but *only* if it can be done via a bustapay, while the current spec doesn't support that. But there's no way that justifies removing the protection for receivers. Without some _basic_ protection, every company that takes bustapayments will just get constantly attacked by a simple costless `wget` that leaks their wallet utxos... The only viable way I can see, would be the sender pays the first part of his invoice in lightning. And then pays the rest with a bustapay. Now the anti-spy thing is the fact the first part of the invoice was already paid. But with so many moving parts, no one is ever going to implement that :P___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bustapay BIP :: a practical sender/receiver coinjoin protocol
James On Sun, Jan 27, 2019 at 2:11 PM wrote: > > It isn't passed "back and forth so many times". > You are right, I got the wrong impression the first time I read it. > This is an important anti-DoS/anti-spy tactic, as it proves the sender > actually owns those inputs and if the protocol is not followed to > completion, the transaction can be dumped on the network. > I'm not convinced this is a valid concern, at least not valid enough to add extra complications to the process. The sender could still refuse to sign the final transaction after they see the recipient's in-/outputs; "show me yours and I'll show you mine" isn't much of a spy deterrent, and nothing here prevents a DOS attack. As an implementor, I would suggest keeping the protocol as simple as possible. By dropping the signing in the first step, the recipient doesn't need to maintain the ability to lookup and verify unspent outputs. It also would enforce the increased privacy, which the sender obviously wants if they are going down this path (in other words, either have the process complete or fail -- don't give the recipient the ability to broadcast the not-private transaction against the wishes of the sender). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
