Conrad Burchert [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-06-22 to 2017-08-17
💬 Posted a total of 2 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:04:50

- reply

📅 Original date posted:2017-08-17
📝 Original message:Some notes:
Hardforks like Bitcoin ABC without a malleability fix are very unlikely to
have payment channels, so the problem does not exist for those.
The designers of a hardfork which does have a malleability fix will
probably know about payment channels, so they can just build a replay
protection that allows the execution of old commitments. That needs some
kind of timestamping of commitments, which would have to be integrated in
the channel design. The easiest way would be to just write the time of
signing the commitment in the transaction and the replay protection accepts
old commitments, but rejects one's which were signed after the hardfork.
These timestamps can essentially be one bit (before or after a hardfork)
and if the replay protection in the hardfork only accepts old commitments
for something like a year, then it can be reused for more hardforks later
on. Maybe someone comes up with an interesting way of doing this without
using space.
Nevertheless hardforking while having channels open will always be a mess
as an open channel requires you to watch the blockchain. Anybody who is
just not aware of the hardfork or is updating his client a few days too
late, can get his money stolen by an old commitment transaction where he
forgets to retaliate on the new chain. As other's can likely figure out
your client version the risk of retaliation is not too big for an attacker.
2017-08-17 13:31 GMT+02:00 Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
>
> ---------- Forwarded message ----------
> From: Christian Decker <decker.christian at gmail.com>
> Date: Thu, Aug 17, 2017 at 5:39 AM
> Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
> hardforks
> To: Martin Schwarz <martin.schwarz at gmail.com>, lightning-dev at lists.
> linuxfoundation.org
>
>
> Hi Martin,
>
> this is the perfect venue to discuss this, welcome to the mailing list :-)
> Like you I think that using the first forked block as the forkchain's
> genesis block is the way to go, keeping the non-forked blockchain on the
> original genesis hash, to avoid disruption. It may become more difficult in
> the case one chain doesn't declare itself to be the forked chain.
>
> Even more interesting are channels that are open during the fork. In these
> cases we open a single channel, and will have to settle two. If no replay
> protection was implemented on the fork, then we can use the last commitment
> to close the channel (updates should be avoided since they now double any
> intended effect), if replay protection was implemented then commitments
> become invalid on the fork, and people will lose money.
>
> Fun times ahead :-)
>
> Cheers,
> Christian
>
> On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz at gmail.com>
> wrote:
>
>> Dear all,
>>
>> currently the chain_id allows to distinguish blockchains by the hash of
>> their genesis block.
>>
>> With hardforks branching off of the Bitcoin blockchain, how can Lightning
>> work on (or across)
>> distinct, permanent forks of a parent blockchain that share the same
>> genesis block?
>>
>> I suppose changing the definition of chain_id to the hash of the first
>> block of the new
>> branch and requiring replay and wipe-out protection should be sufficient.
>> But can we
>> relax these requirements? Are slow block times an issue? Can we use
>> Lightning to transact
>> on "almost frozen" block chains suffering from a sudden loss of hashpower?
>>
>> Has there been any previous discussion or study of Lightning in the
>> setting of hardforks?
>> (Is this the right place to discuss this? If not, where would be the
>> right place?)
>>
>> thanks,
>> Martin
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
>
> --
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170817/af84de89/attachment.html>

2023-06-07 18:03:35

- reply

📅 Original date posted:2017-06-22
📝 Original message:As soon as there is competition for block space, people will likely
outsource creating the proof of work on the transaction to "transaction
miners". This would likely result in giving a fee to those transaction
miners. If those are the same miners as those mining the block, we are back
at the current system.
Put in other words: We are already doing this, you are paying the miner for
a piece of the proof of work of the block. If you want to mine instead of
paying, just mine a block and use a part of the block reward to pay the fee
for another transaction.
This also does not work to prevent spam. Instead of paying the transaction
fee you can just pay someone to mine proof-of-work on your spam
transactions, resulting in roughly the same cost. There is no reason a
normal user would be better in doing this than a spammer, likely it is the
other way around as the spammer is a more reliable customer for a miner.
2017-06-21 11:55 GMT+02:00 Ilya Eriklintsev via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> Hello everyone,
>
> recently I have got an idea that in my opinion will improve bitcoin
> network, making it better store-of-value for growing cyberspace and
> cryptoeconomy. Sorry for longread below and thank you for your time.
>
> *Decentralized proof-of-work and DDoS resistance for Bitcoin*
>
> *Abstract*
>
> By introducing some new block validation rules it is possible to make
> Bitcoin network more secure, decentralized and DDoS resistant. The idea is
> to modify simple proof-of-work puzzle in such a way that user transactions
> could be hardened with the same proof-of-work algorithm thus incentivising
> all the miners to include that particular transaction. Such mechanism will
> effectively give a handicap to every miner who includes "mined" transaction
> into next block, increasing probability of him getting block reward.
>
> *Problems and motivation*
>
> This document will address the issue of a continuous DDoS attack targeting
> the Bitcoin network, e.g. full nodes mempools constantly being overflowed
> with transactions carrying small value reduce system primary ability to
> transfer value (and hence making it perfect store of value). Valid
> transactions are cheap to create (in the sense of computational effort
> required) and no adequate mechanism exist to make transaction total value
> increase probably of its confirmation by the network.
>
> Currently, miners decide which transactions to include in blocks because
> it's them who are securing Bitcoin network providing proof-of-work
> certificates stored inside every block header. Miners have to store the
> whole blockchain at all times, so one of the costs is storage which grows
> linearly with the transaction size (blockchain size as well). Another cost
> is network bandwidth which depends directly on the size of data to be
> communicated over.
>
> The only incentive a person who wants to transfer his bitcoins is allowed
> to use is setting of transaction fee, that is going directly to the miner.
> This solution probably was intended to utilize free market (as implied by
> Satoshi introducing sequence numbers) to determine appropriate fees, but
> that is obviously not the case, in the current bitcoin network operating in
> full block capacity mode. This fee market deviates significantly from a
> free market premise (also attempts being made to make it closer, e.g. in
> BIP125 where Replace-By-Fee signaling is supposed to help in replacing
> "stuck" transactions with noncompetitive fee).
>
> Currently, bitcoin network is susceptible to the DDoS attack of a kind.
> Adversary creating and translating into the network a lot of transactions
> carrying small value (e.g. only miners fee), will be able to impair the
> ability to transfer value for everyone in the world, should he has enough
> money to pay the fees. Miners would continue to work providing security for
> the network and new blocks will consist of transaction transferring
> negligible value. It's a major drawback because the cost of such attack
> doesn't grow asymmetrically with the cost of BTC asset.
>
> *Proposed solution*
>
> So how do we incentivize all miners to include our transaction carrying a
> lot of value in the next block? The only thing a miner supposed to do to
> get a reward is to produce Hashcash proof-of-work, thus providing
> cryptographic security guarantees for the whole Bitcoin blockchain. What if
> including our transaction in a block would reduce effort requirements for
> the miner produce valid block?
>
> We could do so by extending the concept of proof-of-work, in such a way
> that we do not sacrifice security at all. Here are both descriptions
> proof-of-work as-is and to-be:
>
> Standart proof-of-work: hash(previous block hash + current block target +
> current block metadata + current block transactions) < target
>
> Decentralized proof-of-work: hash(previous block hash + current block
> target + current block metadata + current block transactions) - sum( FFFF -
> hash( previous block hash + raw_tx ) ) < target
>
> It is possible to imagine completely mining agnostic proof-of-work, for
> example, the following PoW would do:
>
> Distributed (mining-agnostic) proof-of-work: sum( FFFF - hash( previous
> block hash + current block target + current block metadata + signed_tx ) )
> < target
>
> Described protocol change could be implemented as user activated soft-fork
> (described in BIP148), introducing new blocks with the modified
> proof-of-work concept.
>
> *Economic reasoning*
>
> An adversary whose goal is to prevent the network from transferring value
> will have to compete with good users hash rate using same equipment good
> miners will use. And it's far more complicated than competing with others
> using the money to pay transaction fees.
>
> In order to investigate probable consequences of protocol upgrade and
> stability of implied economical equilibrium, we need an adequate game
> theoretical model. Such model and numerical simulation results should be
> obtained and studied before any protocol change could be considered by the
> community.
>
> To me it seems like a win-win solution for everyone owning BTC:
>
> Miners benefit: as the result DDoS attack will be stopped, Bitcoin becomes
> perfect store-of-value finally. Political decentralization of hash rate
> will be incentivized as mining equipment becomes relevant to every user.
> Users benefit: miners will have direct incentives to include transactions
> deemed important by their sender and supported by some amount of
> proof-of-work.
>
> Sincerely yours, Ilya Eriklintsev.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170622/234987bf/attachment-0001.html>