George Balch [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 18:10:25

- reply

📅 Original date posted:2018-01-29
📝 Original message:The terms "simple ordering of blocks" and timestamp are essentially the
same thing.
On Jan 29, 2018 1:16 PM, "Neiman via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> First time posting here, please be gentle.
>
> I'm doing a research project about blockchain timestamping. There are many
> such projects, including the fantastic OpenTimestamps.
>
> All of the projects essentially save some data in a block, and rely on the
> block timestamp as a proof that this data existed at some specific time.
>
> But how accurate are Bitcoins timestamps?
>
> I didn't find any discussion or research regarding Bitcoin timestamp
> accuracy (also not in the history of this mailing list). I share here a
> simple analysis of timestamp accuracy, and a suggestion how to improve it.
>
> Basic observations and questions:
> -------------------------------------------
> *1.* It seems to me that the timestamp is not the time that the block was
> created. Ideally, it's the time that the miner started to try to mine the
> block. However, as timestamps may also be used as a source of variety for
> hashes, the exact meaning of its value is unclear.
>
> If this is true, then there's a strange phenomena to observe in
> blockchain.info and blockexplorer.com: the timestamps of blocks equals
> the receiving times.
>
> Am I wrong in my understanding, or is there a mistake in those websites?
>
> *2.* Timestamps are not necessary to avoid double-spending. A simple
> ordering of blocks is sufficient, so exchanging timestamps with enumeration
> would work double-spending wise. Permissioned consensus protocols, such as
> hyperledger, indeed have no timestamps (in version 1.0).
>
> As far as I could tell, timestamps are included in Bitcoin's protocol
> *only* to adjust the difficulty of PoW.
>
> Direct control of timestamp accuracy:
> -----------------------------------------------
> The only element in the protocol that I found to control timestamp
> accuracy is based on the network time concept.
>
> The Bitcoin protocol defines “network time” for each node. The network
> time is the median time of the other clients, but only if
> 1. there are at least 5 connected, and
> 2. the difference between the median time and the nodes own system
> time is less than 70 minutes.
>
> Then new blocks are accepted by the peers if their timestamps is
> 1. less than the network time plus 2 hours, and
> 2. greater than the median timestamp of previous 11 blocks.
>
> The first rule supplies a 2 hour upper bound for timestamp accuracy.
>
> However, the second rule doesn't give a tight lower bound. Actually, no
> lower bound is given at all if no assumption is made about the median. If
> we assume the median to be accurate enough at some timepoint, then we're
> only assured that any future timestamp is no bigger than this specific
> median, which is not much information.
>
> Further analysis can be made under different assumptions. For example,
> what's the accuracy if holders of 51% of the computational power create
> honest timestamps? But unfortunately, I don't see any good reason to work
> under such an assumptions.
>
> The second rule cannot be strengthened to be similar to the first one
> (i.e., nodes don't accept blocks less than network time minus 2 hours). The
> reason is that nodes cannot differentiate if it's a new block with
> dishonest timestamp, an old block with an old timestamps (with many other
> blocks coming) or simply a new block that took a long time to mine.
>
> Indirect control of timestamps accuracy:
> --------------------------------------------------
> If we assume that miners have no motive to increase difficulty
> artificially, then the PoW adjusting algorithm yields a second mechanism of
> accuracy control.
>
> The adjustment rules are given in pow.cpp (bitcoin-core source, version
> 0.15.1), in the function 'CalculateNextWorkRequired', by the formula (with
> some additional adjustments which I omit):
>
> (old_target* (time_of_last_block_in_2016_blocks_interval -
> time_of_first_block_in_2016_blocks_interval) )/time_of_two_weeks
>
> It uses a simple average of block time in the last 2016 blocks. But such
> averages ignore any values besides the first and last one in the interval.
> Hence, if the difficulty is constant, the following sequence is valid from
> both the protocol and the miners incentives point of views:
>
> 1, 2, 3,…., 2015, 1209600 (time of two weeks), 2017, 2018, 2019,….,
> 4031, 1209600*2, 4033, 4044, …
>
> If we want to be pedantic, the best lower bound for a block timestamp is
> the timestamp of the block that closes the adjustment interval in which it
> resides.
>
> Possible improvement:
> -----------------------------
> We may consider exchanging average with standard deviation in the
> difficulty adjustment formula. It both better mirrors changes in the hash
> power along the interval, and disables the option to manipulate timestamps
> without affecting the difficulty.
>
> I'm aware that this change requires a hardfork, and won't happen any time
> soon. But does it make sense to add it to a potential future hard fork?
>
> _______________________________________________
> 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/20180129/71830c72/attachment-0001.html>

2023-06-07 18:10:19

- reply

📅 Original date posted:2018-01-28
📝 Original message:If miners leave transactions out of a block they do pay a cost by not being
rewarded those fees. If they include their own spam transactions to get
back the fee they gain nothing. Since blocks can have fees resulting in
hundreds of thousands of dollars, it would seem unlikely that miners incur
a huge cost for not including transactions.
On Sun, Jan 28, 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>> Miners can fill their blocks with transactions paying very high fees at
>> no cost because they get the fees back to themselves. They can do this for
>> different purposes, like trying to increase the recommended fee. Here I
>> propose a backwards-compatible solution to this problem.
>>
>> The solution would be to reward the fees of the current block to the
>> miner of the next block (or X blocks after the current one). That way, if a
>> miner floods its own block with very high fee transactions, those fees are
>> no longer given back to itself, but to the miner of future blocks which
>> could potentially be anyone. Flooding blocks with fake txs is now
>> discouraged. However, filling blocks with real transactions paying real
>> fees is still encouraged because you could be the one to mine the block
>> that would claim this reward.
>>
>> The way to implement this in a backwards-compatible fashion would be to
>> enforce miners to set an anyone-can-spend output in the coinbase
>> transaction of the block (by adding this as a rule for verifying new
>> blocks). The miner of 100 blocks after the current one can add a secondary
>> transaction spending this block's anyone-can-spend coinbase transaction
>> (due to the coinbase needing 100 blocks to mature) and thus claiming the
>> funds. This way, the block reward of a block X is always transferred to the
>> miner of block X+100.
>>
>> Implementing this would require a soft-fork. Since that secondary
>> transaction needs no signature whatsoever, the overhead caused by that
>> extra transaction is negligible.
>>
>> Possible Downside: When the fork is activated, the miners won’t get any
>> reward for mining blocks for a period of 100 blocks. They could choose to
>> power off the mining equipment for maintenance or to save power over that
>> period, so the hashrate could drop temporarily. However, if the hashrate
>> drops too much, blocks would take much longer to mine, and miners wouldn’t
>> want that either since they want to go through those 100 reward-less blocks
>> as soon as possible so they can start getting rewards from mining again.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> Lucas Clemente Vella
> lvella at gmail.com
>
> _______________________________________________
> 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/20180128/dc779353/attachment.html>