* [bitcoin-dev] Some thoughts on removing timestamps in PoW
@ 2018-02-19 1:29 Tao Effect
2018-02-19 9:04 ` Damian Williamson
0 siblings, 1 reply; 6+ messages in thread
From: Tao Effect @ 2018-02-19 1:29 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 3799 bytes --]
Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 <https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13>
# Blockchain Timestamps Unnecessary In Proof-of-Work?
*Author: Greg Slepak ([@taoeffect@mastodon.social <mailto:taoeffect@mastodon.social>](https://mastodon.social/@taoeffect <https://mastodon.social/@taoeffect>))*
----
The Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm.
I assert, or rather, pose the hypothesis, that the use of timestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with the same security guarantees without it (except as noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronization.
The alternative difficulty adjustment algorithm would work according to the following principles:
- The incentive for miners is and always has been to maximize profit.
- The block reward algorithm is now modified to issue coins into perpetuity (no maximum). Any given block can issue _up to_ `X` number of coins per block.
- The number of coins issued per block is now tied directly to the difficulty of the block, and the concept of "epocs" or "block reward halving" is removed.
- The chain selection rule remains "chain with most proof of work"
- The difficulty can be modified by miners in an arbitrary direction (up or down), but is limited in magnitude by some maximum percentage (e.g. no more than 20% deviation from the previous block), we call this `Y%`.
### Observations
- Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation
- The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly
- Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today)
- Whether miners choose to produce blocks quickly or slowly is entirely up to them. If they produce blocks quickly, each block has a lower reward, but there are more of them. If they produce blocks slowly, each block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce blocks at a rate that should minimize orphans.
A timestamp may still be included in blocks, but it no longer needs to be used for anything, or represent anything significant other than metadata about when the miner claims to have produced the block.
### Risks and Mitigations
Such a system may introduce risks that require further modification of the protocol to mitigate.
The most straightforward risk comes from the potential increase in total transaction throughput that such a change would introduce (these are the same concerns that exist with respect to raising the blocksize). The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate, potentially resulting in additional centralization pressures not only on miners but also on full nodes who then would have greater difficulty keeping up with the additional bandwidth and storage demands.
Two equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish:
1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up.
2. A sharded protocol, where each shard uses a "sufficiently different" PoW algorithm, would create an exit for users should the primary blockchain become captured by a cartel providing poor quality-of-service.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
[-- Attachment #1.2: Type: text/html, Size: 7247 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW
2018-02-19 1:29 [bitcoin-dev] Some thoughts on removing timestamps in PoW Tao Effect
@ 2018-02-19 9:04 ` Damian Williamson
2018-02-21 21:58 ` Tao Effect
0 siblings, 1 reply; 6+ messages in thread
From: Damian Williamson @ 2018-02-19 9:04 UTC (permalink / raw)
To: Tao Effect, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4541 bytes --]
>1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up.
What you are suggesting, unless I am mistaken, is that new full nodes should have no way of knowing if an output is spent or even if it exists. Since large sections of the blockchain will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters.
Regards,
Damian Williamson
________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Tao Effect via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Monday, 19 February 2018 12:29:50 PM
To: Bitcoin Protocol Discussion
Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW
Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13
# Blockchain Timestamps Unnecessary In Proof-of-Work?
*Author: Greg Slepak ([@taoeffect@mastodon.social<mailto:taoeffect@mastodon.social>](https://mastodon.social/@taoeffect))*
----
The Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm.
I assert, or rather, pose the hypothesis, that the use of timestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with the same security guarantees without it (except as noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronization.
The alternative difficulty adjustment algorithm would work according to the following principles:
- The incentive for miners is and always has been to maximize profit.
- The block reward algorithm is now modified to issue coins into perpetuity (no maximum). Any given block can issue _up to_ `X` number of coins per block.
- The number of coins issued per block is now tied directly to the difficulty of the block, and the concept of "epocs" or "block reward halving" is removed.
- The chain selection rule remains "chain with most proof of work"
- The difficulty can be modified by miners in an arbitrary direction (up or down), but is limited in magnitude by some maximum percentage (e.g. no more than 20% deviation from the previous block), we call this `Y%`.
### Observations
- Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation
- The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly
- Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today)
- Whether miners choose to produce blocks quickly or slowly is entirely up to them. If they produce blocks quickly, each block has a lower reward, but there are more of them. If they produce blocks slowly, each block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce blocks at a rate that should minimize orphans.
A timestamp may still be included in blocks, but it no longer needs to be used for anything, or represent anything significant other than metadata about when the miner claims to have produced the block.
### Risks and Mitigations
Such a system may introduce risks that require further modification of the protocol to mitigate.
The most straightforward risk comes from the potential increase in total transaction throughput that such a change would introduce (these are the same concerns that exist with respect to raising the blocksize). The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate, potentially resulting in additional centralization pressures not only on miners but also on full nodes who then would have greater difficulty keeping up with the additional bandwidth and storage demands.
Two equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish:
1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up.
2. A sharded protocol, where each shard uses a "sufficiently different" PoW algorithm, would create an exit for users should the primary blockchain become captured by a cartel providing poor quality-of-service.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
[-- Attachment #2: Type: text/html, Size: 7984 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW
2018-02-19 9:04 ` Damian Williamson
@ 2018-02-21 21:58 ` Tao Effect
0 siblings, 0 replies; 6+ messages in thread
From: Tao Effect @ 2018-02-21 21:58 UTC (permalink / raw)
To: Damian Williamson; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]
> What you are suggesting, unless I am mistaken, is that new full nodes should have no way of knowing if an output is spent or even if it exists. Since large sections of the blockchain will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters.
So, this might not have been clear, but by "if we are given the liberty of modifying the protocol as we wish" I meant that I was discussing a protocol where these sorts of concerns are not an issue because we are not limited by the constraints of Bitcoin's current design.
There have been plenty of proposals across the web for how to design a blockchain where what you're referring to is not an issue because of merkle commitments, etc., and some blockchains already do this (e.g. I believe Ethereum does this via parity).
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Feb 19, 2018, at 4:04 AM, Damian Williamson <willtech@live.com.au> wrote:
>
> >1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up.
>
> What you are suggesting, unless I am mistaken, is that new full nodes should have no way of knowing if an output is spent or even if it exists. Since large sections of the blockchain will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters.
>
> Regards,
> Damian Williamson
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW
[not found] ` <CAEgR2PEEgoY2y33-rmHuNDxprvAiAzP0H=ByCGmzd+zMA=QFVQ@mail.gmail.com>
@ 2018-02-19 13:41 ` Daniele Pinna
0 siblings, 0 replies; 6+ messages in thread
From: Daniele Pinna @ 2018-02-19 13:41 UTC (permalink / raw)
To: Contact, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5290 bytes --]
Granted that removing the 21M coin cap is basically a non-starter in de
bitcoin community I'd like to respond to a couple points in your proposal.
The Y% difficulty adjustment should still be calculated through some
averaging of a certain number N of past blocks. Otherwise two lucky high
difficulty blocks in a row could potentially grind the network to a halt.
Just imagine what would happen to the bitcoin network if the difficulty
target was magically increased by 40% all of a sudden. This is certainly
not likely but must be considered imo.
The second, and most interesting (to me at least) is how the reward should
scale with difficulty. By making the reward scale concavely
(logarithmically for example) with difficulty as well as depend on past
average difficulty AND total # of mined coins, it might be possible to
retain something close to the 21M coin cap while also disincentivizing
mining blocks with excessively large difficulties.
Let D and D_0 be the difficulty of the mind block and some reference
initial difficulty respectively. S and S_0 the total floating coin supply
and the reference initial supply. Then the reward function could look
something like this:
R(D, S; D_0,S_0) =R_0(S/S_0)*Log[1+D/D_0]/Log[2]
Where R_0(S/S_0) can be some decaying exponential function of the ratio
S/S_0 such that initially (when S=S_0) R_0=12.5.
But... As I said, this is solely for sake of argument.
Daniele
---------- Forwarded message ----------
From: Tao Effect <contact@taoeffect.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc:
Bcc:
Date: Sun, 18 Feb 2018 20:29:50 -0500
Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW
Copied from: https://github.com/WebOfTrustInfo/rebooting-the-
web-of-trust-spring2018/pull/13
# Blockchain Timestamps Unnecessary In Proof-of-Work?
*Author: Greg Slepak ([@taoeffect@mastodon.social](https://mastodon.social/@
taoeffect))*
----
The Bitcoin blockchain has a 10-minute target blocktime that is achieved by
a difficulty adjustment algorithm.
I assert, or rather, pose the hypothesis, that the use of timestamps in
Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with
the same security guarantees without it (except as noted in [Risks and
Mitigations](#risks-and-mitigations)), and therefore does not need miners
to maintain global clock synchronization.
The alternative difficulty adjustment algorithm would work according to the
following principles:
- The incentive for miners is and always has been to maximize profit.
- The block reward algorithm is now modified to issue coins into perpetuity
(no maximum). Any given block can issue _up to_ `X` number of coins per
block.
- The number of coins issued per block is now tied directly to the
difficulty of the block, and the concept of "epocs" or "block reward
halving" is removed.
- The chain selection rule remains "chain with most proof of work"
- The difficulty can be modified by miners in an arbitrary direction (up or
down), but is limited in magnitude by some maximum percentage (e.g. no more
than 20% deviation from the previous block), we call this `Y%`.
### Observations
- Miners are free to mine blocks of whatever difficulty they choose, up to
a maximum deviation
- The blockchain may at times produce blocks very quickly, and at other
times produce blocks more slowly
- Powerful miners are incentivized to raise the difficulty to remove
competitors (as is true today)
- Whether miners choose to produce blocks quickly or slowly is entirely up
to them. If they produce blocks quickly, each block has a lower reward, but
there are more of them. If they produce blocks slowly, each block has a
higher reward, but there are fewer of them. So an equilibrium will be
naturally reached to produce blocks at a rate that should minimize orphans.
A timestamp may still be included in blocks, but it no longer needs to be
used for anything, or represent anything significant other than metadata
about when the miner claims to have produced the block.
### Risks and Mitigations
Such a system may introduce risks that require further modification of the
protocol to mitigate.
The most straightforward risk comes from the potential increase in total
transaction throughput that such a change would introduce (these are the
same concerns that exist with respect to raising the blocksize). The
removal of timestamps would allow a cartel of miners to produce
high-difficulty blocks at a fast rate, potentially resulting in additional
centralization pressures not only on miners but also on full nodes who then
would have greater difficulty keeping up with the additional bandwidth and
storage demands.
Two equally straightforward mitigations exist to address this if we are
given the liberty of modifying the protocol as we wish:
1. Introducing state checkpoints into the chain itself could make it
possible for full nodes to skip verification of large sections of
historical data when booting up.
2. A sharded protocol, where each shard uses a "sufficiently different" PoW
algorithm, would create an exit for users should the primary blockchain
become captured by a cartel providing poor quality-of-service.
--
Please do not email me anything that you are not comfortable also sharing with
the NSA.
[-- Attachment #2: Type: text/html, Size: 8202 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW
2018-02-19 5:10 Ryan J Martin
@ 2018-02-19 5:15 ` Tao Effect
0 siblings, 0 replies; 6+ messages in thread
From: Tao Effect @ 2018-02-19 5:15 UTC (permalink / raw)
To: Ryan J Martin; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 1084 bytes --]
Real quick (I've received some off-list replies and do plan to respond to those), want to be clear: this thread is not meant to be interpreted as a proposal to modify Bitcoin (it is not a BIP), it is just, exactly as the subject says, some thoughts I had that I hadn't seen expressed elsewhere, that I felt like sharing, in case they are at all useful/interesting to anyone.
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Feb 19, 2018, at 12:10 AM, Ryan J Martin <rjmarti2@millersville.edu <mailto:rjmarti2@millersville.edu>> wrote:
>
> To be frank, this kind of thing would be better off attempted as a fork to a new coin. Changing the max number of coins, the block reward, the difficulty algo, mining policy and protocol is going to be a non-starter. Also, what are the proposed quantifiavle benefits from removing timestamps? How would this be done at the protocol level? Are these other changes related to removing timestamps/rationale for other supply changes?
>
> Regards,
> Ryan J. Martin
>
[-- Attachment #1.2: Type: text/html, Size: 4075 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW
@ 2018-02-19 5:10 Ryan J Martin
2018-02-19 5:15 ` Tao Effect
0 siblings, 1 reply; 6+ messages in thread
From: Ryan J Martin @ 2018-02-19 5:10 UTC (permalink / raw)
To: Bitcoin Protocol Discussion, Tao Effect
[-- Attachment #1: Type: text/plain, Size: 4245 bytes --]
To be frank, this kind of thing would be better off attempted as a fork to a new coin. Changing the max number of coins, the block reward, the difficulty algo, mining policy and protocol is going to be a non-starter. Also, what are the proposed quantifiavle benefits from removing timestamps? How would this be done at the protocol level? Are these other changes related to removing timestamps/rationale for other supply changes?
Regards,
Ryan J. Martin
On Feb 18, 2018 10:01 PM, Tao Effect via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13
# Blockchain Timestamps Unnecessary In Proof-of-Work?
*Author: Greg Slepak ([@taoeffect@mastodon.social<mailto:taoeffect@mastodon.social>](https://mastodon.social/@taoeffect))*
----
The Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm.
I assert, or rather, pose the hypothesis, that the use of timestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with the same security guarantees without it (except as noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronization.
The alternative difficulty adjustment algorithm would work according to the following principles:
- The incentive for miners is and always has been to maximize profit.
- The block reward algorithm is now modified to issue coins into perpetuity (no maximum). Any given block can issue _up to_ `X` number of coins per block.
- The number of coins issued per block is now tied directly to the difficulty of the block, and the concept of "epocs" or "block reward halving" is removed.
- The chain selection rule remains "chain with most proof of work"
- The difficulty can be modified by miners in an arbitrary direction (up or down), but is limited in magnitude by some maximum percentage (e.g. no more than 20% deviation from the previous block), we call this `Y%`.
### Observations
- Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation
- The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly
- Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today)
- Whether miners choose to produce blocks quickly or slowly is entirely up to them. If they produce blocks quickly, each block has a lower reward, but there are more of them. If they produce blocks slowly, each block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce blocks at a rate that should minimize orphans.
A timestamp may still be included in blocks, but it no longer needs to be used for anything, or represent anything significant other than metadata about when the miner claims to have produced the block.
### Risks and Mitigations
Such a system may introduce risks that require further modification of the protocol to mitigate.
The most straightforward risk comes from the potential increase in total transaction throughput that such a change would introduce (these are the same concerns that exist with respect to raising the blocksize). The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate, potentially resulting in additional centralization pressures not only on miners but also on full nodes who then would have greater difficulty keeping up with the additional bandwidth and storage demands.
Two equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish:
1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up.
2. A sharded protocol, where each shard uses a "sufficiently different" PoW algorithm, would create an exit for users should the primary blockchain become captured by a cartel providing poor quality-of-service.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
[-- Attachment #2: Type: text/html, Size: 6513 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-02-21 21:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-19 1:29 [bitcoin-dev] Some thoughts on removing timestamps in PoW Tao Effect
2018-02-19 9:04 ` Damian Williamson
2018-02-21 21:58 ` Tao Effect
2018-02-19 5:10 Ryan J Martin
2018-02-19 5:15 ` Tao Effect
[not found] <CAEgR2PGV7NdJ79uh80GdZ5nP2ehkH1J3v=Tv6c0g6OLE+sL7LQ@mail.gmail.com>
[not found] ` <CAEgR2PHSSGx-JHhw+sCdeVTacba=P4X6+ZZhihS85HZsAL1gmg@mail.gmail.com>
[not found] ` <CAEgR2PEUam3rwOxW1kKv6k5=WJ=p2PWzto3UCAuF3zgZn9NkWQ@mail.gmail.com>
[not found] ` <CAEgR2PE0aX+UOoSPyB+YEsT_BiDe3qO20X1EVn763uxOoJHpww@mail.gmail.com>
[not found] ` <CAEgR2PHM1WxNkUvvNKacBD0XX3VFKEyYWaKR+HOF-ZrrijLQ4A@mail.gmail.com>
[not found] ` <CAEgR2PHqDcLaMnoONJgGrC51g+kjhCjU1GnSh+YzU-HLjkUJsw@mail.gmail.com>
[not found] ` <CAEgR2PGfhK0WKVipTpwThnK8d-pPj9O5ZCVna3oO5Wi_rEA-Eg@mail.gmail.com>
[not found] ` <CAEgR2PHuD2ZQeaqo2cArw7rR17755V3jAEHW34B+CUnaBjTqSA@mail.gmail.com>
[not found] ` <CAEgR2PEof7Z1x0CSuEQUbmjs8_s2-y9ipDOa0utEuTnysnqEPA@mail.gmail.com>
[not found] ` <CAEgR2PHvK+HXAKygysUXV0BoG851E-a1kiD7JDVuCDSvAx41RQ@mail.gmail.com>
[not found] ` <CAEgR2PEpHnvCSFLckARHMM_5uhUP8KXE4MjyB1KPOjSRng01tg@mail.gmail.com>
[not found] ` <CAEgR2PHatZ0_0006=7QtapJ=_DV975DPY91Bd0f3yYgE_r+srg@mail.gmail.com>
[not found] ` <CAEgR2PFuOgFbJtfq9CLxNNSn+99Y6yRfYg=BvOCY_=vO+=pukw@mail.gmail.com>
[not found] ` <CAEgR2PFM7W9StLiWGRT8g6-iFR904QJzCUUa_MdT58p1SsYxYw@mail.gmail.com>
[not found] ` <CAEgR2PF7Ke1VENpsq+7jyn=Xen3S5pWBWLwhTJa=eAYT396yNQ@mail.gmail.com>
[not found] ` <CAEgR2PE+BZUXwtaRgKybk5szeSvmg_tQHzxJHO3LQO-QOR2Sxg@mail.gmail.com>
[not found] ` <CAEgR2PE5+xB2hr9-_hRftz_F4kGBTKy_oHpLbdDJyGmJgV_Xbw@mail.gmail.com>
[not found] ` <CAEgR2PH=NuZv0ULP6=tiEjb15_Z37FvfmLBbiRYo1ht+2Radfw@mail.gmail.com>
[not found] ` <CAEgR2PHVWfV5bVBGeCv5oP_k5kfEcs592gv=VKUYBKC8EXZw_Q@mail.gmail.com>
[not found] ` <CAEgR2PFyYgZRyNbOGQhx1PR-rgpXDFgSOGGYUCBkG32YZ2+=KQ@mail.gmail.com>
[not found] ` <CAEgR2PG8enwcyfkTGkPxD9Qcvmvypr5WJCCe=qMg1er0Ty+5Mg@mail.gmail.com>
[not found] ` <CAEgR2PFFFfWeuhyPk6doj-jOeJcxXVfZ5CUDEWZPcnf3BG61=g@mail.gmail.com>
[not found] ` <CAEgR2PFkxbXU_v6DgDCue4_5cM7FftAhNiwPgfvdQ2FLg+3drg@mail.gmail.com>
[not found] ` <CAEgR2PHes8J85d4m6yB0JoPsA95zEts-fsJPaPds0mFHt8dnOA@mail.gmail.com>
[not found] ` <CAEgR2PFALKvgdc7NVCsL=eCyWoBxu8gsFMPcfkffAB9Bay1+cw@mail.gmail.com>
[not found] ` <CAEgR2PE4YMdFnjJ6kYA-CFBY2fW0GED-1RXM8iXzFv_xJEikHw@mail.gmail.com>
[not found] ` <CAEgR2PGG-+epbAsOxVn29qcHcVLJ+X0js5Xzu0sN0uSEPj1hfQ@mail.gmail.com>
[not found] ` <CAEgR2PHx=RmwV5HK-B33v8fbzqWMSAW-6ef-s7iiYGQT=PYVwA@mail.gmail.com>
[not found] ` <CAEgR2PG6+5uT1dQLO9EbqTxB=1xHtS7nmpr4TUDO+bNzAiyhHg@mail.gmail.com>
[not found] ` <CAEgR2PGezGVKYHrHS9RgvyNJiKPA_uqRYbhWjhzCw_PaXtDv+A@mail.gmail.com>
[not found] ` <CAEgR2PFWZebe0fXiUcGD7q371a_OLb2JvJyX+1jZHUYZhChi=w@mail.gmail.com>
[not found] ` <CAEgR2PF0VRxwHNkJinDCOWgVCojg=DSZHqYiYR_Cqa3OUNg8EA@mail.gmail.com>
[not found] ` <CAEgR2PGs18xm6QSCwdzHRZt89pCCXpMFD+YAxZrhztoY8EdGJQ@mail.gmail.com>
[not found] ` <CAEgR2PEEgoY2y33-rmHuNDxprvAiAzP0H=ByCGmzd+zMA=QFVQ@mail.gmail.com>
2018-02-19 13:41 ` Daniele Pinna
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox