Stephen [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-05-11 to 2015-06-27
💬 Posted a total of 7 messages
📚 Participated in the following categories: Bitcoin-development, BIP, BIP draft
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 14:43:28

- reply

📅 Original date posted:2015-06-27
📝 Original message:
Quick question on the security of the Lightning Network when rerouting payments.
Say A wants to make a payment to E, and they find a payment channel route through A->B->C->E. The payment is done in increments of 0.01 BTC until the full 1 BTC has been paid. However, part way through the payments, C becomes unresponsive. The contract has already been given to C that guarantees payment if C can produce the pre-image of a certain hash, and C does receive the pre-image from E. They do not share that pre-image with B, though. C must reveal the pre-image, either to B directly or on the blockchain, before B's contract times out, which guarantees B will receive payment.
But A has not paid the full amount to E yet when C became unresponsive. A wants to re-route her payment to avoid delays, so she re-routes the rest of the payments through A->B->D->E. A finishes the payments through this alternate route. But now, can't C reveal the pre-image to B, who then reveals it to A? Which, will effectively steal an extra 0.01 BTC from Alice and give it to E. (C and E could have been colluding to do this, splitting the profits).
Is there something that prevents this that I do not see yet, or is this just the risk one takes with payment re-routing?
Thanks!
Stephen

2023-06-07 17:37:36

- reply

📅 Original date posted:2015-06-14
📝 Original message:While this idea is theoretically interesting because it involves many stakeholders, rather than just miners, I think in practice this would not work very well. Users don't want to worry about this kind of technicality, they just want to be able to make a transaction and have it be processed.
In addition, while this gives stakeholders some weight with the fees they supply, these fees are marginal compared to the block size subsidy. If this proposal were actually implemented, I think miners would vote for whatever they think is best, and users would not contradict them with their votes to ensure a fast confirmation time. Users are incentivized to be in agreement with miners because the miners provide them with the confirmations they need, but fees do not provide a great incentive for miners to be in agreement with users, and likely won't for some time.
Best,
Stephen
> On Jun 12, 2015, at 2:11 PM, Peter Todd <pete at petertodd.org> wrote:
>
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
>
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize voting:
>
> https://www.mail-archive.com/[email protected]/msg02323.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:36:37

- reply

📅 Original date posted:2015-06-06
📝 Original message:Hi Kristov,
I like the idea. Mainly because having a standard reminds developers to consider this issue. In addition, we would have visibility into the portion of the network that adopts this strategy to enhance privacy. A few points of feedback:
- I think your explanation of sorting could be significantly shortened and clarified by simply saying that the TXIDs of inputs should be compared as uint256 integers.
- The malleability of input TXIDs, as mentioned in the proposal, could cause inputs to be ordered in a non-standard way. Reordering then them would invalidate the signatures (assuming SIGHASH_ALL), so the transaction would be left with improperly ordered inputs. While not a huge issue, it's not ideal. I think the best way to get around this would be to use normalized TXIDs, but you might also be able to sort based on the previous outputs that each of the inputs are spending? These both require information that may not be readily available, however, and use of normalized transaction IDs is not fully developed yet.
Best,
Stephen
> On Jun 5, 2015, at 8:12 PM, Kristov Atlas <kristovatlas.lists at gmail.com> wrote:
>
> Hello all,
>
> I have written a draft of a BIP to standardize the sorting of tx inputs and outputs for privacy and security reasons. A few colleagues have reviewed this and provided feedback privately, but now it's ready for feedback from a wider audience.
>
> If there is positive sentiment about the proposal after feedback is integrated, I aim for a bip number to be assigned and have it accepted into https://github.com/bitcoin/bips
>
> Link: https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki
>
> For your convenience, here's the abstract:
>
> "Currently there is no standard for bitcoin wallet clients when ordering transaction inputs and outputs. As a result, wallet clients often have a discernible blockchain fingerprint, and can leak private information about their users. By contrast, a standard for non-deterministic sorting could be difficult to audit. This document proposes deterministic lexicographical sorting, using hashes of previous transactions and output indices to sort transaction inputs, as well as value and locking scripts to sort transaction outputs."
>
> Thanks,
>
> Kristov Atlas
> Open Bitcoin Privacy Project Contributor, Blockchain.info Security Engineer, etc.
> Twitter: @kristovatlas
> Blog: kristovatlas.com
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150605/6364f4b4/attachment.html>

2023-06-07 17:36:28

- reply

📅 Original date posted:2015-06-02
📝 Original message:Do you think it would be useful to have an inverted version of both CSV and CLTV? To verify if an output is spent before a specific time. CLTV and CSV could be implemented by taking two stack arguments, an integer for the comparison and TRUE/FALSE.
Now that I think about this more, the problem is that, for example, just having a lock time of less than some value doesn't actually mean it has to be spent before that script value, so this might not work. Likely any implementations of such a feature would have to provide the script execution environment with access to information that it doesn't have now, which is what we are trying to avoid.
Best,
Stephen
> On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <mark at friedenbach.org> wrote:
>
> You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers:
>
> https://github.com/maaku/bitcoin/tree/checksequenceverify
>
> Most of the interesting use cases for relative lock-time require an RCLTV opcode. What is interesting about this architecture is that it possible to cleanly separate the relative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like CLTV, the CSV opcode only checks transaction data and requires no contextual knowledge about block headers, a weakness of the other RCLTV proposals that violate the clean separation between libscript and libconsensus. In a similar way, this BIP proposal only touches the transaction validation logic without any impact to script.
>
> I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing at a time.
>
>> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <stephencalebmorse at gmail.com> wrote:
>> Hi Mark,
>>
>> Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented.
>>
>> In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can be done by the first-signing party. So, while your solution would probably work in cases like this, where multiple signing parties are involved, there may be other, seen or unforeseen, use cases that require putting the relative locktime right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothing that enforces using an nSequence and nVersion=2 that would prevent spending the output until a certain time.
>>
>> I hope this is received as constructive criticism, I do think this is an innovative idea. In my view, though, it seems to be less fully-featured than just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an OP_RCLTV would be needed.
>>
>> Best,
>> Stephen
>>
>>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <mark at friedenbach.org> wrote:
>>> I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following thread:
>>>
>>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>>
>>> In short summary, this proposal seeks to enable safe transaction replacement by re-purposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time.
>>>
>>> The advantages of this approach is that it makes use of the full range of the 32-bit sequence number which until now has rarely been used for anything other than a boolean control over absolute nLockTime, and it does so in a way that is semantically compatible with the originally envisioned use of sequence numbers for fast mempool transaction replacement.
>>>
>>> The disadvantages are that external constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and re-purposing nSequence as a relative lock-time precludes its use in other contexts. The latter point has been partially addressed by having the relative lock-time semantics be enforced only if the most-significant bit of nSequence is set. This preserves 31 bits for alternative use when relative lock-times are not required.
>>>
>>> The BIP draft can be found at the following gist:
>>>
>>> https://gist.github.com/maaku/be15629fe64618b14f5a
>>>
>>> The reference implementation is available at the following git repository:
>>>
>>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>>
>>> I request that the BIP editor please assign a BIP number for this work.
>>>
>>> Sincerely,
>>> Mark Friedenbach
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/7b87e165/attachment.html>

2023-06-07 17:35:14

- reply

📅 Original date posted:2015-05-16
📝 Original message:We should make sure to consider how BIP34 affects normalized transaction ids, since the height of the block is included in the scriptSig ensuring that the txid will be different. We wouldn't want to enable replay attacks in the form of spending coinbase outputs in the same way they were spent from a previous block.
So maybe normalized txids should strip the scriptSigs of all transactions except for coinbase transactions? This seems to make sense, since coinbase transactions are inherently not malleable anyway.
Also, s7r linked to my 'Build your own nHashType' proposal (although V2 is here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal_v2.md). I just wanted to add that I think even with normalized ids, it could still be useful to be able to apply these flags to choose which parts of the transaction become signed. I've also seen vague references to some kind of a merklized abstract syntax tree, but am not fully sure how that would work. Maybe someone on here could explain it?
Best,
Stephen
> On May 15, 2015, at 5:54 AM, s7r <s7r at sky-ip.org> wrote:
>
> Hello,
>
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
> b) replays
>
> If you strip just the scriptSig of the input(s), the txid(s) can still
> be mutated (with higher probability before it gets confirmed).
>
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, and I don't think it's the proper way to do it.
>
> Something similar can be achieved if you would use a combination of
> flags from here:
>
> https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
>
> But this has some issues too.
>
> I've read your draft but didn't understand how exactly will this prevent
> normal malleability as we know it, second level malleability and replays
> as well as how will we do the transition into mapping the txes in the
> blockchain to normalized txids. Looking forward to read more on this
> topic. Thanks for the brainstorming ;)
>
>
>> On 5/13/2015 3:48 PM, Christian Decker wrote:
>> Hi All,
>>
>> I'd like to propose a BIP to normalize transaction IDs in order to
>> address transaction malleability and facilitate higher level protocols.
>>
>> The normalized transaction ID is an alias used in parallel to the
>> current (legacy) transaction IDs to address outputs in transactions. It
>> is calculated by removing (zeroing) the scriptSig before computing the
>> hash, which ensures that only data whose integrity is also guaranteed by
>> the signatures influences the hash. Thus if anything causes the
>> normalized ID to change it automatically invalidates the signature. When
>> validating a client supporting this BIP would use both the normalized tx
>> ID as well as the legacy tx ID when validating transactions.
>>
>> The detailed writeup can be found
>> here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
>>
>> @gmaxwell: I'd like to request a BIP number, unless there is something
>> really wrong with the proposal.
>>
>> In addition to being a simple alternative that solves transaction
>> malleability it also hugely simplifies higher level protocols. We can
>> now use template transactions upon which sequences of transactions can
>> be built before signing them.
>>
>> I hesitated quite a while to propose it since it does require a hardfork
>> (old clients would not find the prevTx identified by the normalized
>> transaction ID and deem the spending transaction invalid), but it seems
>> that hardforks are no longer the dreaded boogeyman nobody talks about.
>> I left out the details of how the hardfork is to be done, as it does not
>> really matter and we may have a good mechanism to apply a bunch of
>> hardforks concurrently in the future.
>>
>> I'm sure it'll take time to implement and upgrade, but I think it would
>> be a nice addition to the functionality and would solve a long standing
>> problem :-)
>>
>> Please let me know what you think, the proposal is definitely not set in
>> stone at this point and I'm sure we can improve it further.
>>
>> Regards,
>> Christian
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:34:38

- reply

📅 Original date posted:2015-05-11
📝 Original message:Why do so many tie the block size debate to creating "a fee market", as if one didn't already exist? Yes, today we frequently see many low priority transactions included into the next block, but that does not mean there is not a marketplace for block space. It just means miners are not being sufficiently tough to create a *competitive* marketplace.
But who are we to say that the marketplace should be more competitive, and to go further and try to force it by altering consensus rules like the block size limit? If miners want to see more competitive fees, then they need only to alter their block creation protocol.
There are many arguments for and against changing the consensus limit on block size. I'm simply saying that "to force a marketplace for fees/block space" should not be one of them. Let the market develop on it's own.
- Stephen
> On May 10, 2015, at 4:45 PM, Sergio Lerner <sergiolerner at certimix.com> wrote:
>
> Two years ago I presented a new way to create a fee market that does not depend on the block chain limit.
>
> This proposal has not been formally analyzed in any paper since then, but I think it holds a good promise to untangle the current problem regarding increasing the tps and creating the fee market. BTW, think the maximum tps should be increased, but not by increasing the block size, but by increasing the block rate (I'll expose why in my next e-mail).
>
> The original post is here (I was overly optimistic back then): https://bitcointalk.org/index.php?topic=147124.msg1561612#msg1561612
>
> I'll summarize it here again, with a little editing and a few more questions at the end:
>
> The idea is simple, but requires a hardfork, but is has minimum impact in the code and in the economics.
>
> Solution: Require that the set of fees collected in a block has a dispersion below a threshold. Use, for example, the Coefficient of Variation (http://en.wikipedia.org/wiki/Coefficient_of_variation). If the CoVar is higher than a fixed threshold, the block is considered invalid.
>
> The Coefficient of variation is computed as the standard deviation over the mean value, so it's very easy to compute. (if the mean is zero, we assume CoVar=0). Note that the CoVar function does not depend on the scale, so is just what a coin with a floating price requires.
>
> This means that if there are many transactions containing high fees in a block, then free transactions cannot be included.
> The core devs should tweak the transaction selection algorithm to take into account this maximum bound.
>
> Example
>
> If the transaction fee set is: 0,0,0,0,5,5,6,7,8,7
> The CoVar is 0.85
> Suppose we limit the CoVar to a maximum of 1.
>
> Suppose the transaction fee set is: 0,0,0,0,0,0,0,0,0,10
> Then the CoVar is 3.0
>
> In this case the miner should have to either drop the "10" from the fee set or drop the zeros. Obviously the miner will drop some zeros, and choose the set: 0,10, that has a CoVar of 1.
>
> Why it reduces the Tx spamming Problem?
>
> Using this little modification, spamming users would require to use higher fees, only if the remaining users in the community rises their fees. And miners won't be able to include an enormous amounts of spamming txs.
>
> Why it helps solving the tragedy-of-the-commons fee "problem"?
>
> As miners are forced to keep the CoVar below the threshold, if people rises the fees to confirm faster than spamming txs, automatically smamming txs become less likely to appear in blocks, and fee-estimators will automatically increase future fees, creating a the desired feedback loop.
>
> Why it helps solving the block size problem?
>
> Because if we increase the block size, miners that do not care about the fee market won't be able to fill the block with spamming txs and destroy the market that is being created. This is not a solution against an attacker-miner, which can always fill the block with transactions.
>
> Can the system by gamed? Can it be attacked?
>
> I don't think so. An attacker would need to spend a high amount in fees to prevent transactions with low fees to be included in a block.
> However, a formal analysis would be required. Miller, Gun Sirer, Eyal.. Want to give it a try?
>
> Can create a positive feedback to a rise the fees to the top or push fess to the bottom?
>
> Again, I don't think so. This depends on the dynamics between the each node's fee estimator and the transaction backlog. MIT guys?
>
> Doesn't it force miners to run more complex algorithms (such as linear programming) to find the optimum tx subset ?
>
> Yes, but I don't see it as a drawback, but as a positive stimulus for researchers to develop better tx selection algorithms. Anyway, the greedy algorithm of picking the transactions with highest fees fees would be good enough.
>
>
> PLEASE don't confuse the acronym CoVar I used here with co-variance.
>
> Best regard,
> Sergio.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150511/6eaf0f71/attachment.html>

2023-06-07 17:33:42

- reply

📅 Original date posted:2015-05-16
📝 Original message:Comments in line:
> On May 8, 2015, at 11:08 PM, Peter Todd <pete at petertodd.org> wrote:
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>
> Right now pools already get DoSed all the time through their work
> submission systems; getting DoS attacked via their nodes as well would
> be a disaster.
It seems that using a -miner flag to follow rules about smaller blocks would only reveal miner nodes if one sent the node a solved block that that was valid in every way except the block size. While not impossible, I wouldn't call this trivial, as it still requires wasting an entire block's worth of energy.
>> When in "miner mode", the client would reject 4MB blocks and wouldn't build
>> on them. The reference client might even track the miner and the non-miner
>> chain tip.
>>
>> Miners would refuse to build on 5MB blocks, but merchants and general users
>> would accept them.
>
> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
>
I think this could be mitigated by counting confirmations differently. We should think of confirmations as only coming from blocks following the miners' more strict rule set. So if a merchant were to see payment for the first time in a block that met their own size restrictions but not the miners', then they would simply count it as unconfirmed.
If they get deep enough in the chain, though, the client should probably count them as being confirmed anyway, even if they don't meet the client nodes' expectation of the miners' block size limit. This happening probably just means that the client has not updated their software (or -minermaxblocksize configuration, depending on how it is implemented) in a long time.
I actually like Tier's suggestion quite a bit. I think we could have the default client limit set to some higher number, and have miners agree out of band on the latest block size limit. Or maybe even build in a way to vote into the blockchain.
Best,
Stephen