Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

[Peter Todd via bitcoin-dev]

On Tue, Jan 30, 2018 at 03:30:21AM +, CANNON via bitcoin-dev wrote:
> On 01/30/2018 01:43 AM, CANNON via bitcoin-dev wrote:
> > 
> > 
> >  Forwarded Message 
> > Subject: RE: NIST 8202 Blockchain Technology Overview
> > Date: Mon, 29 Jan 2018 12:25:05 +
> > From: Yaga, Dylan (Fed) 
> > To: CANNON 
> > 
> > Thank you for your comments.
> > You, along with many others, expressed concern on section 8.1.2.
> > To help foster a full transparency approach on the editing of this section, 
> > I am sending the revised section to you for further comment. 
> > 
> > 8.1.2   Bitcoin Cash (BCH)
> > In 2017, Bitcoin users adopted an improvement proposal for Segregated 
> > Witness (known as SegWit, where transactions are split into two segments: 
> > transactional data, and signature data) through a soft fork. SegWit made it 
> > possible to store transactional data in a more compact form while 
> > maintaining backwards compatibility.  However, a group of users had 
> > different opinions on how Bitcoin should evolve  and developed a hard fork 
> > of the Bitcoin blockchain titled Bitcoin Cash. Rather than implementing the 
> > SegWit changes, the developers of Bitcoin Cash decided to simply increase 
> > the blocksize. When the hard fork occurred, people had access to the same 
> > amount of coins on Bitcoin and Bitcoin Cash.
> > 
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> 
> This is much better than the original. My question, the part where it says 
> segwit makes transactions more compact, I thought that transactions are not 
> more compact but rather they just take advantage of extra blockspace beyond 
> that of 1 MB? Yes they would appear to be more compact to un-upgraded nodes 
> due to the witness being stripped, but the transactions are not actually more 
> compact right?

That's absolutely right; this is why segwit is a blocksize increase first and
foremost rather than some kind of transaction size optimization.

It'd be good to get that corrected as well.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

[Eric Voskuil via bitcoin-dev]

On 01/29/2018 05:59 PM, Gregory Maxwell wrote:
> On Mon, Jan 29, 2018 at 11:21 PM, Eric Voskuil  wrote:
>> Block space created by a miner is property that belongs to the miner, it
>> can be sold or not sold.
> 
> That case would be stronger when there is no more subsidy, but we
> collectively the uses of Bitcoin are currently paying miners around
> $130k USD per block in the form of inflation for the job of honestly
> complying with the Bitcoin protocol.

The miner who creates a block owns the block, he/she has selected the
transactions and directs the reward. The case for this could hardly be
stronger.

The fact that there is subsidy implies that *part* of the cost of
creating the block is offset. But by not accepting the highest fee
transactions the miner is still accepting a net loss by purchasing the
space for himself. The hash power generated by the miner to create the
block contributes to confirmation security to a greater degree than for
which he has been rewarded.

You seem to be implying that there is dishonesty involved in purchasing
block space, or that it is somehow possible to earn reward while not
complying with the protocol. There is no honest or dishonest compliance
with a protocol, there is just compliance or non-compliance.

> I don't think you can argue that they have any more right to do that
> than any of us have a right to run software that invalidates their
> coinbase outputs when they do; which would be the sort of retaliation
> they might get targeted with.

Everyone can do whatever they want with their own machines, and I
haven't argued otherwise. As far as "rights" go, Bitcoin doesn't care.
I'm not one who has regularly raised hard fork fears while at the same
time threatening them. My objective is to dispel flawed reasoning, not
to negotiate for the rights of some group over another.

Some economic theories that get thrown around are baffling, this idea of
"retaliation" among them. Presumably the objective is to reduce
transaction confirmation costs. The theory would be that mining empty
blocks or mining own transactions is "unfairly" increasing revenue to
miners. Despite the incorrectness of this theory, the proposed cure
attempts to reduce returns to miners. However the consequence of
reducing returns to miners is simply a reduction of hash power (as the
least efficient miners become insolvent). Miners will continue to earn
the same rate of return on their capital as always. And the cost of
transactions will remain the same...

The presumed mechanism of the proposed retaliation is also baffling. A
miner (or anyone) can always create transactions, pay fees, and send
them out to the network. Given that we presume transactions without
identity, it is not possible (or desirable) to detect the source of
transactions. Maybe the assumption is that sending such transactions out
to the network would not satisfy the miner's objective, since the fees
cannot be "recovered". But this is the original flaw. Fees spent to
one's self cannot be recovered either! So if a miner wants to blow money
by filling up blocks with market fee transactions, they will be able to
do so at the same cost no matter how one tries to "retaliate".

e



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

[CANNON via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/30/2018 01:43 AM, CANNON via bitcoin-dev wrote:
> 
> 
>  Forwarded Message 
> Subject: RE: NIST 8202 Blockchain Technology Overview
> Date: Mon, 29 Jan 2018 12:25:05 +
> From: Yaga, Dylan (Fed) 
> To: CANNON 
> 
> Thank you for your comments.
> You, along with many others, expressed concern on section 8.1.2.
> To help foster a full transparency approach on the editing of this section, I 
> am sending the revised section to you for further comment. 
> 
> 8.1.2 Bitcoin Cash (BCH)
> In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness 
> (known as SegWit, where transactions are split into two segments: 
> transactional data, and signature data) through a soft fork. SegWit made it 
> possible to store transactional data in a more compact form while maintaining 
> backwards compatibility.  However, a group of users had different opinions on 
> how Bitcoin should evolve  and developed a hard fork of the Bitcoin 
> blockchain titled Bitcoin Cash. Rather than implementing the SegWit changes, 
> the developers of Bitcoin Cash decided to simply increase the blocksize. When 
> the hard fork occurred, people had access to the same amount of coins on 
> Bitcoin and Bitcoin Cash.
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

This is much better than the original. My question, the part where it says 
segwit makes transactions more compact, I thought that transactions are not 
more compact but rather they just take advantage of extra blockspace beyond 
that of 1 MB? Yes they would appear to be more compact to un-upgraded nodes due 
to the witness being stripped, but the transactions are not actually more 
compact right?
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJab+afAAoJEAYDai9lH2mwCDAP/RRpExXmnPzlvxuhhJ+8gSlc
QRZHVa0nJ2SETTZnQSa+0t8dBO9ROYSnDHuMEqz/ba8o00Rce8icxQvCGOO29OSK
Cru7/UJzYTwnt5mK2ljpUB1Fsx96fAPxfg4QMeDCRe+O5LLkH1als1GGVOwlFnLu
BAV0MoCljWzBxokf0ax8+ZHHYEaKe+Fj9PKby7CZrqQKoL9PkI/n7EvqICUdTCu5
tAz9SNIBVtUxgGx/ZY96hvBx0zorV1IQEWchQ50oh/V+TgmnOW4njQOKc4TcSgfp
TKpRFs8Zd7TzeIS/85GX0APGypchxdjlBaV0EORTO9GYFo7nKlzHkIGOF9Er+E6q
II4qjbKLc5d/wwCIA8MHFW0Vxwv2+0ztApaWAFW42+LeHERaPCzi4NEy5quqvmsE
IiTaGebl2XbTd0I+aB6WWsScTUmfXrt+NL05kwE0KDylY/mSwYMgYjP95X1Mci7X
rcJRf6/pP607EiHlq3MmDlyt4TrYBp9FVVjdjvM+sD8wz72FhWeYJQdyF8t1ToOD
U/ItNsxl5Jx9JvCkBXoX+6MMZ91W7D2x04Ur3OMRmy/lOoztOYAdlKy0tMyRqfCi
L81apfjvmTaR2OTWhCawgZGLXGJcfOG5ECuXC90B6il5Jsts/XwyFMN2Fa1iZB50
cZwF3ySKxoVtpsf/vTW7
=feRa
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 2 step confirmation system

[Weiwu Zhang via bitcoin-dev]

On Wed, 24 Jan 2018, rmcc via bitcoin-dev wrote:


I know from speaking to my friends not involved with Bitcoin that two of
their major concerns are as follows: 
1. They are afraid if they fat finger the address there is nothing they can
do about it and not get their Bitcoin back.


I can empathize with this. A friend of mine, an artificial intelligence
expert of the biggest bank in our country with a degree in math and IQ
of 150, copied his merchant's Bitcoin address as his and sent to a
colleague to ask for a repayment. As a result, the merchant got paid
twice. That was back a few years ago when Bitcoin could be used for
purchasing goods.

There are a few ways to address this issue.

For starter, the beneficiary's wallet can generate a signed payment
request instead of just an address. The AI expert, in his case,
wouldn't be able to generate a payment request for the merchant
because he doesn't have the merchant's key. The payment request can
have a timestamp for the sender to spot the reuse of old request. There
are advanced methods to go down this route, e.g. in the cases where
there is an invoice, or buyer's public key is known, these can be
associated with the payment request or be used in some homomorphic
magic to generate very special addresses to receive the money.

Then, there is the option of sending the transaction (in a private
channel) to the beneficiary instead of broadcasting the
transaction. The beneficiary, we trust, will not broadcast the
transaction if he would not receive money as a result of it or he sees
the transaction wasn't constructed correctly to his wish. In fact, he
may not be able to even see the transaction without the right private
key to generate a decoding session key. This method solves another
use-case: deniable payment. It's not unusual for a WeChat user to deny
another WeChat user's Red Packt ("I don't take bribes, sir!"). If it is
with Bitcoin, the beneficiary certainly does not want to pay the
transaction fee again just to nullify the previous payment to him. In
a more illustrative example, I like to give away free Bitcoins after
my lectures, but many of the students won't redeem their share because
money isn't the only motivation for their studies. I admit that money
is my motivation after all and I wish to reclaim the money that was
not redeemed by students. (I stopped this practise when giving away
Bitcoin costs more than the amount given.)

Finally, there is multi-sig. I'll cover that in answering the 2nd
section of your email.


2. They would like to at least have the option to use some sort of 2 step
confirmation system when dealing ith people they do not know. For example,
after sending the Bitcoin to a seller they would like to be able to do a
final approval of the tm transaction. If the 2 people involved in the
transaction approve of it within X hours, the coin returns to the original
person. This system would basically act as an escrow.


There is the case of escrow with an arbitrator and escrow without an
arbitrator. We know that the beneficiary can always send the money
back by looking up the input address. Given that he alone has this
power, whether or not the other person agrees, to reimburse, it is a
moot point to require two people to co-sign anything. Therefore, the
case without arbitrageur is usually depended on time or revealing an x
to a known hash. This can go complicated so I'll turn around
and talk about the case with arbitrageur.

The case with an arbitrator was explained by Rhavar. It can be
elaborately built in a sheltered model, where a compromised arbitrator
can only revert transactions, not to steal. You can build fine-tuned
features with Rhavar's model, like setting a 90-day grace period where
the beneficiary cannot claim the money, in order to leave ample time
for the arbitrator to revert the transaction should he need to do so.

As Rhavar pointed out, it's too costly to be practical for daily
transactions. Back in 2012 when I learned about multi-sig, I hopped
multi-sig grew popular before the blockchain gets full so that people
have the opportunity to witness the power of Bitcoin. It unfortunately
didn't happen.

All of the methods I mentioned does not require any change to the
Bitcoin network or Bitcoin Blockchain. The wallet is the weakest link
in this chain. A wallet developer can go ahead and implement all these
without negotiating with Bitcoin developers.

P.S. I remark that I consistently use the word beneficiary because the
other choices like "receiver" or "recipient" are often meant for the
receiving of messages (e.g. in a private channel), who doesn't have to
be the beneficiary (e.g. an arbitrator receives a lot of
messages).

I check mail lists weekly so, sorry for the late reply.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview

[CANNON via bitcoin-dev]

 Forwarded Message 
Subject: RE: NIST 8202 Blockchain Technology Overview
Date: Mon, 29 Jan 2018 12:25:05 +
From: Yaga, Dylan (Fed) 
To: CANNON 

Thank you for your comments.
You, along with many others, expressed concern on section 8.1.2.
To help foster a full transparency approach on the editing of this section, I 
am sending the revised section to you for further comment. 

8.1.2   Bitcoin Cash (BCH)
In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness 
(known as SegWit, where transactions are split into two segments: transactional 
data, and signature data) through a soft fork. SegWit made it possible to store 
transactional data in a more compact form while maintaining backwards 
compatibility.  However, a group of users had different opinions on how Bitcoin 
should evolve – and developed a hard fork of the Bitcoin blockchain titled 
Bitcoin Cash. Rather than implementing the SegWit changes, the developers of 
Bitcoin Cash decided to simply increase the blocksize. When the hard fork 
occurred, people had access to the same amount of coins on Bitcoin and Bitcoin 
Cash.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

[Gregory Maxwell via bitcoin-dev]

On Mon, Jan 29, 2018 at 11:21 PM, Eric Voskuil  wrote:
> Block space created by a miner is property that belongs to the miner, it
> can be sold or not sold.

That case would be stronger when there is no more subsidy, but we
collectively the uses of Bitcoin are currently paying miners around
$130k USD per block in the form of inflation for the job of honestly
complying with the Bitcoin protocol.

I don't think you can argue that they have any more right to do that
than any of us have a right to run software that invalidates their
coinbase outputs when they do; which would be the sort of retaliation
they might get targeted with.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

[Eric Voskuil via bitcoin-dev]

On 01/29/2018 01:22 PM, Gregory Maxwell wrote:
> On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev
>  wrote:
>> I'm not sure who cooked up this myth about miners gaining advantage over
>> those who buy block space by mining empty space, rejecting higher-fee
>> transactions, and/or mining "recovery" transactions, but the idea is
>> complete nonsense.
> 
> I agree.
> 
> Steel-manning it, I guess I could argue that empty blocks are slightly
> more conspicuous and might invite retaliation especially given the
> high levels of mining centralization creates retaliation exposure. ...
> but dummy transactions are hardly less conspicuous, many nodes log now
> when blocks show up containing txn that they've never seen before.
> Moreover, inexplicably underfilled blocks are produced (e.g. by
> bitmain's antpool) and no retaliation seems to be forthcoming.

It's not clear to me what would be the reason for retaliation, given
there is no more harm in a miner purchasing a block than Coinbase
submitting enough transactions to fill a block. Both pay the market rate
for the space. But since the former results in a loss, a financial
consequence ("retaliation") is inherent.

If a farmer destroys his/her own apple crop he loses money. It may be
very conspicuous, but nobody would retaliate as only the farmer's own
property was affected. Customers would just get their apples elsewhere.
Block space created by a miner is property that belongs to the miner, it
can be sold or not sold.

e



signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

[George Balch via bitcoin-dev]

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@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.
>
> 

Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

[Bryan Bishop via bitcoin-dev]

On Mon, Jan 29, 2018 at 7:34 AM, Neiman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But how accurate are Bitcoins timestamps?
>

A perspective on block timestamp and opentimestamps can be found here:
https://lists.w3.org/Archives/Public/public-blockchain/2016Sep/0076.html

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

[Gregory Maxwell via bitcoin-dev]

On Mon, Jan 29, 2018 at 9:40 PM, Tier Nolan via bitcoin-dev
 wrote:
> For check locktime, the median of the last 11 blocks is used as an improved
> indicator of what the actual real time is.  Again, it assumes that a
> majority of the miners are honest.

It would be more accurate to say that the median is not used for
improved accuracy but to mitigate a consensus incompatibility:

If the block's own timestamp were used for nlocktime and time based
nlocks were common on the network each miner would maximize their fee
income by setting the value as high as they could get away with.  What
concerned us wasn't so much that this would make the times less
accurate (though it would) but rather that it would create an
incentive for a runaway situation that could harm network stability
(e.g. with all miners cranking times against the 2hr window, then
creating pressure for miners to accept further and further in the
future; each responding to his own local incentives).

This incentive incompatibility could have been addressed e.g. by using
the prior block's time, but since the protocol doesn't require times
to be monotone (and for good reason!) the simple implementation of
that wouldn't have been a soft-fork.  The 11 block MTP worked out
nicely because the protocol already required new times to be larger
than that.

The timestamps in Bitcoin aren't intended to be particularly accurate.
They're used only for controlling the difficulty, and the adjustment
window is large enough that there isn't much distortion that can be
accomplished there.  It's not clear to me that much better can really
be done... if there were tighter time requirements in the protocol
miners would address them by running NTP which as an _astounding_ lack
of security in terms of how it is commonly deployed.  As far as I
know, I'm the only person whos ever mined blocks with their own
stratum 1 time source.

If times need to be accurate Bitcoin would need to use a rather
different design (e.g. each block would commit to the observation time
of the prior N blocks, and an iterative algorithm would solve for each
blocks time and each miners local offset).

IIRC open-timestamp calendar servers provide more precise
time-stamping under the assumption that the calendar server is
behaving correctly.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

[Tier Nolan via bitcoin-dev]

On Mon, Jan 29, 2018 at 1:34 PM, Neiman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> *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).
>

The timestamps simply needs to be reasonably accurate.  Their main purpose
is to allow difficulty updates.

They can also be used to check that the node has caught up.


> 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, …
>

Much of Bitcoin operates on the assumption that a majority of miners are
honest.  If 50%+ of miners set their timestamp reasonably accurately (say
within 10 mins), then the actual timestamp will move forward at the same
rate as real time.

Dishonest miners could set their timestamp as low as possible, but the
median would move foward if more than half of the timestamps move forward.


> 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.
>

If you are assuming that the miners are majority dishonest, then they can
set the limit to anything as long as they don't move it more than 2 hours
into the future.

The miners could set their timestamps so that they increase 1 week fake
time every 2 weeks real time and reject any blocks more than 2 hours ahead
of their fake time.  The difficulty would settle so that one block occurs
every 20 mins.


>
> 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?
>

For check locktime, the median of the last 11 blocks is used as an improved
indicator of what the actual real time is.  Again, it assumes that a
majority of the miners are honest.

>
>
> ___
> 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] Proposal: rewarding fees to next block miner

[Gregory Maxwell via bitcoin-dev]

On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev
 wrote:
> I'm not sure who cooked up this myth about miners gaining advantage over
> those who buy block space by mining empty space, rejecting higher-fee
> transactions, and/or mining "recovery" transactions, but the idea is
> complete nonsense.

I agree.

Steel-manning it, I guess I could argue that empty blocks are slightly
more conspicuous and might invite retaliation especially given the
high levels of mining centralization creates retaliation exposure. ...
but dummy transactions are hardly less conspicuous, many nodes log now
when blocks show up containing txn that they've never seen before.
Moreover, inexplicably underfilled blocks are produced (e.g. by
bitmain's antpool) and no retaliation seems to be forthcoming.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: rewarding fees to next block miner

[Eric Voskuil via bitcoin-dev]

Your statements contradict each other.

This is not a question of whether it is a "huge" cost, but whether there
is an problem of incentive compatibility, which there is not. Miners
incur the opportunity cost of the space that they mine that does not
include the most optimal fees, which is equal in value to those forgone
fees.

If miners exclude available higher-fee transactions, or mine empty
space, or mine their own "recovery" transactions, they are merely
purchasing block space at market rates, just like everyone else.

The only difference is that they are getting nothing in return, while
everyone else is presumably getting a useful monetary transfer. In other
words, they are losing value to do this. Therefore the incentive is to
not do so. But again, the option to do so is perfectly incentive compatible.

I'm not sure who cooked up this myth about miners gaining advantage over
those who buy block space by mining empty space, rejecting higher-fee
transactions, and/or mining "recovery" transactions, but the idea is
complete nonsense.

e

On 01/28/2018 05:44 PM, George Balch via bitcoin-dev wrote:
> 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
>  > 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
>  >:
> 
> 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@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> 
> 
> -- 
> Lucas Clemente Vella
> lve...@gmail.com 
> 
> ___
> 

[bitcoin-dev] How accurate are the Bitcoin timestamps?

[Neiman via bitcoin-dev]

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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev