Thomas Guyot-Sionnest [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-08-21 to 2018-06-05
💬 Posted a total of 11 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:12:52

- reply

📅 Original date posted:2018-06-05
📝 Original message:On 30/05/18 12:17 PM, Darren Weber via bitcoin-dev wrote:
>
> Apologies for brevity, noob here and just throwing out an idea in case
> it's useful (probably already covered somewhere, but I haven't got
> time to do all the necessary background research).
>
> From https://github.com/bitcoin/bitcoin/issues/13342
>
> Suggestion: To make it more difficult for a malicious attacker to
> reap quick rewards by double-spending large amounts with a relatively
> brief majority of the network hashing power, introduce a hash workload
> that is proportional to the sum of transactions in a block (probably
> the sum of the absolute values, and a "proportionality function" could
> be linear or exponential). The motivation is to make it more
> difficult for malicious attacks to hash-power their way through a few
> large transactions. Obviously, there are costs in greater transaction
> delays (and fees?) for larger amounts (absolute value).
>
> If there is original value in the idea, I can try to make time to
> follow-up with a better BIP proposal.
>
Hi Darren,
I'm wondering how do you think this can be implemented... The problem
being that you cannot just decide to exclude transactions because you
found a lesser difficulty hash since that hash includes all transactions
already... Miners will either include or not these transactions based on
economical value, and since most of the rewards still comes from block
rewards there would be very little right now except with very high fees.
Even worse, it may have detrimental side-effects: since there is no
distinctions between destination and change addresses, one can only
assume the transaction amount is the full input amount. Therefore users
would be inclined to keep large amount in lots of smaller addresses to
avoid being penalized on small transactions, increasing the UTXO size
for everybody.
And besides, this is a huge change to swallow, requiring very good
consensus and a hard fork. IMHO I wouldn't even waste time on this.
Regards,
--
Thomas

2023-06-07 18:07:13

- reply

📅 Original date posted:2017-10-24
📝 Original message:On 23/10/17 07:52 AM, Kosta Zertsekel via bitcoin-dev wrote:
> >> On Oct 22, 2017, at 13:11, Kosta Zertsekel wrote:
> >> I wonder why automake has become the build system for Bitcoin Core?
> >> I mean - why not cmake which is considered better?
> >> Can you please point to the relevant discussion or explanation?
>
> > On Mon, Oct 23, 2017 at 6:24 AM, Jeffrey Paul <jp at eeqj.com
> <mailto:jp at eeqj.com>> wrote:
> > Considered by whom? Automake is the standard and I prefer it as it
> requires
> > no additional install on most systems. For that, I consider it better.
>
> Well, here are some quotes about CMake build tools...
>
> [...]
>
> All of them (CMake, Meson, Ninja) had a goal to replace automake.
> Was there any discussion about choosing the best build system for
> Bitcoin Core?
What exact problem are you trying to fix for bitcoin-core?
Each build system have their pros and cons, and what you need it the
right tool for the job. Unless there is a specific problem to solve and
that cmake can solve it without causing other issues, why would you want
to change?
Or better yet, convert yourself bitcoin-core to cmake and show the
developers that it makes build config simpler without scarifying
features (cross-platform builds, gitian...) then maybe they'll adopt it.
Regards,
--
Thomas

2023-06-07 18:05:14

- reply

📅 Original date posted:2017-09-01
📝 Original message:On 01/09/17 02:15 PM, Cserveny Tamas via bitcoin-dev wrote:
> Yes. I meant the single thread as an analogy, if a block is found,
> other blocks are worthless. (more or less) Longest chain wins.
>
> My line of though was, that currently the only way to scale with the
> traffic (and lowering the fees) is increasing the block size (which is
> hard as I learned from recent events), or reducing the complexity
> which is less secure (most likely more controversial)
>
It wouldn't be less secure as long as you adjust the confirmation
accordingly. If we decided to mine one block every minute, then your
usual 6 confirmation should become 60 confirmation. In the end, the same
amount of work will have been done to prove the transaction is legit and
so it's just as secure... Actually, one could argue since the average
hash rate over 60 block is more accurate than over 6, it's actually more
secure if you also pay attention to hash rate variation as part of the
confirmation... That help in the scenario a very large pool goes dark to
mine a sidechain.
--
Thomas

2023-06-07 18:05:14

- reply

📅 Original date posted:2017-09-01
📝 Original message:On 01/09/17 01:15 PM, Lucas Clemente Vella via bitcoin-dev wrote:
>
> > The current chain is effectively single threaded.
>
> This is not true, since xthin/compactblocks have been introduced we
> completely removed this bottle-neck.
> The transactions will be validated continuously, in parallel and
> not just
> when a block is found.
>
>
> If I understood correctly, OP was not talking about the process inside
> a node being single threaded, but instead that the whole bitcoin
> distributed system behaves as single threaded computation. OP seems to
> be describing a system closer to what IOTA uses, by distributing among
> the miners the task of validating the transactions. Although, without
> more specific details, it is hard to judge the benefits.
>
If the goal is reducing the delay for validation then I don't get what
advantage there would be vs. reducing the difficulty.
Also it is my understanding that with the Lightning network transactions
could be validated instantly by third parties and could be subject to
smaller fees overall...
Regards,
--
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170901/44c8986f/attachment-0001.html>

2023-06-07 18:05:02

- reply

📅 Original date posted:2017-08-26
📝 Original message:I don't think you fully understand the way bitcoin works. There are no
"accounts" and no need to know the private key to change transactions in
the chain. What you need is to keep track of all unspent outputs (block
number, index, value and script/witness) so that they can be verified
once a transaction refers to it.
Everything you suggest about moving those funds to a "genesis account"
is nonsense and cannot work.
--
Thomas
On 26/08/17 05:01 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote:
>
> Solving the Scalability Problem Part II
> --------------------------------------------------------------------
> 
> In the previous post I showed a way to minimize the blocks on the
> block chain, to lower the amount of space it takes on the hard drive,
> without losing any relevant information.
> I added a note, saying that the transaction chain needs to be
> rewritten, but I did not give much detail to it. 
> Here is how that would work: 
> The Genesis Account:
> ----------------------------------------- 
> The problem with changing the transaction and block chain, is that it
> cannot be done without knowing the private key of the sender of the of
> the funds for each account. There is however a way to circumvent that
> problem. That is to create a special account called the “Genesis
> Account”, this account’s Private Key and Public Key will be available
> to everyone. 
> But this account will not be able to send or receive any funds in a
> normal block, it will be blocked--blacklisted. So no one can
> intentionally use it. The only time this account will be used is in
> the pruning block, a.k.a Exodus Block. 
> When creating the new pruned block chain and transaction chain, all
> the funds that are now in accounts must be legitimate, and it would be
> difficult to legitimize them unless they were sent from a legitimate
> account, with a public key, and a private key which can be verified.
> That is where the Genesis account comes in. All funds in the Exodus
> Block will show as though they originated and were sent from the
> Genesis Account using its privatekey to generate each transaction. 
> The funds which are sent, must match exactly the funds existing in the
> most updated ledger in block 1000 (the last block as stated in my
> previous post). 
> In this way the Exodus Block can be verified, and the Genesis Account
> cannot give free money to anyway, because if someone tried to, it
> would fail verification. 
>
> 
> Now the next problem is that the number of Bitcoins keeps expanding
> and so the funds in the Genesis Account need to expand as well. That
> can be done by showing as though this account is the account which is
> mining the coins, and it will be the only account in the Exodus Block
> which “mines” the coins, and receives the mining bonus. In the Exodus
> Block all coins mined by the real miners will show as though they were
> mined by Genesis and sent to the miners through a regular transaction.
>
> 
>
> Adam Shem-Tov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170826/6d12fc6c/attachment.html>

2023-06-07 18:05:00

- reply

📅 Original date posted:2017-08-27
📝 Original message:How do you trust your <1000 block blockchain if you don't
download/validate the whole thing? (I know it should be easy to spot
that by looking at the blocks/tx or comparing to other nodes, but from a
programmatic point of view this is much harder). You can of course
include a checkpoint in the code to tell which recent block is valid
(which is already done afaik), but you still need all blocks from that
checkpoint to validate the chain (not 10!). If you rely on such
checkpoint, why not just include the UTXO's as well so you can start
mid-way based on code trust?
Indeed pruning doesn't allow you to start mid-way yet but there are much
easier solutions to that than what you propose.
--
Thomas
On 26/08/17 06:32 PM, Adam Tamir Shem-Tov wrote:
> Thank you Thomas for your response.
>
> 1) Implement solution is impossible... I have given a solution in part
> II. By adding a Genesis Account which will be the new sender.
>
> 2)Keeping older blocks: Yes as I said 10 older blocks should be kept,
> that should suffice. I am not locked on that number, if you think
> there is a reason to keep more than that, it is open to debate.
>
> 3) Why 1000? To be honest, that number came off the top of my head.
> These are minor details, the concept must first be accepted, then we
> can work on the minor details.
>
> 4)Finally it's not just the addresses and balance you need to save...
> I think the Idea of the Genesis Account, solves this issue.
>
> 5) The problem with node pruning is that it is not standardized, and
> for a new node to enter the network and to verify the data, it needs
> to download all data and prune it by itself. This will drastically
> lower the information needed by the full nodes by getting rid of the
> junk. Currently we are around 140GB, that number is getting bigger
> exponentially, by the number of users and transactions created. It
> could reach a Terrabyte sooner than expected, we need to act now.
>
> On your second email:
> When I say account: I mean private-public key.
> The way bitcoin works, as I understand it, is that the funds are
> verified by showing that they have an origin, this "origin" needs to
> provide a signature, otherwise the transaction won't be accepted.
> If I am proposing to remove all intermediate origins, then the funds
> become untraceable and hence unverifiable. To fix that, a new
> transaction needs to replace old ones. A simplified version: If there
> was a transaction chain A->B->C->D, and I wish to show only A->D, only
> a transaction like that never actually occurred, it would be
> impossible to say that it did without having A's private key, in order
> to sign this transaction. In order to create this transaction, I need
> A's private key. And if I wish this to be publicly implemented I need
> this key to be public, so that any node creating this Exodus Block can
> sign with it. Hence the Genesis Account. And yes, it is not really an
> account.

2023-06-07 18:04:59

- reply

📅 Original date posted:2017-08-26
📝 Original message:Pruning is already implemented in the nodes... Once enabled only unspent
inputs and most recent blocks are kept. IIRC there was also a proposal
to include UTXO in some blocks for SPV clients to use, but that would be
additional to the blockchain data.
Implementing your solution is impossible because there is no way to
determine authenticity of the blockchain mid way. The proof that a block
hash leads to the genesis block is also a proof of all the work that's
been spent on it (the years of hashing). At the very least we'd have to
keep all blocks until a hard-coded checkpoint in the code, which also
means that as nodes upgrades and prune more blocks older nodes will have
difficulty syncing the blockchain.
Finally it's not just the addresses and balance you need to save, but
also each unspent output block number, tx position and script that are
required for validation on input. That's a lot of data that you're
suggesting to save every 1000 blocks (and why 1000?), and as said
earlier it doesn't even guarantee you can drop older blocks. I'm not
even going into the details of making it work (hard fork, large block
sync/verification issues, possible attack vectors opened by this...)
What is wrong with the current implementation of node pruning that you
are trying to solve?
--
Thomas
On 26/08/17 03:21 PM, Adam Tamir Shem-Tov via bitcoin-dev wrote:
>
> Solving the Scalability issue for bitcoin 
>
> I have this idea to solve the scalability problem I wish to make public.
>
> If I am wrong I hope to be corrected, and if I am right we will all
> gain by it. 
>
> Currently each block is being hashed, and in its contents are the hash
> of the block preceding it, this goes back to the genesis block.
>
> 
>
> What if we decide, for example, we decide to combine and prune the
> blockchain in its entirety every 999 blocks to one block (Genesis
> block not included in count).
>
> 
>
> How would this work?: Once block 1000 has been created, the network
> would be waiting for a special "pruned block", and until this block
> was created and verified, block 1001 would not be accepted by any nodes.
>
> This pruned block would prune everything from block 2 to block 1000,
> leaving only the genesis block. Blocks 2 through 1000, would be
> calculated, to create a summed up transaction of all transactions
> which occurred in these 999 blocks.
>
> 
>
> And its hash pointer would be the Genesis block.
>
> This block would now be verified by the full nodes, which if accepted
> would then be willing to accept a new block (block 1001, not including
> the pruned block in the count).
>
> 
>
> The new block 1001, would use as its hash pointer the pruned block as
> its reference. And the count would begin again to the next 1000. The
> next pruned block would be created, its hash pointer will be
> referenced to the Genesis Block. And so on..
>
> 
>
> In this way the ledger will always be a maximum of 1000 blocks.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170826/5f836930/attachment-0001.html>

2023-06-07 18:04:58

- reply

📅 Original date posted:2017-08-22
📝 Original message:I'm just getting the proposal out... if we decide to go forward (pretty
huge "if" right now) whenever it kicks in after 15, 50 or 100 years
should be decided as early as possible.
Are CheckLockTimeVerify transactions accepted yet? I thought most
special transactions were only accepted on Testnet... In any case we
should be able to scan the blockchain and look for any such transaction.
And I hate to make this more complex, but maybe re-issuing the tx from
coinbase could be an option?
--
Thomas
On 22/08/17 06:58 PM, Rodney Morris via bitcoin-dev wrote:
> Thomas et.al <http://et.al>.
>
> So, in your minds, anyone who locked up coins using CLTV for their
> child to receive on their 21st birthday, for the sake of argument, has
> effectively forfeit those coins after the fact? You are going to
> force anyone who took coins offline (cryptosteel, paper, doesn't
> matter) to bring those coins back online, with the inherent security
> risks?
>
> In my mind, the only sane way to even begin discussing an approach
> implementing such a thing - where coins "expire" after X years - would
> be to give the entire ecosystem X*N years warning, where N > 1.5. I'd
> also suggest X would need to be closer to the life span of a human
> than zero. Mind you, I'd suggest this "feature" would need to be
> coded and deployed as a future-hard-fork X*N years ahead of time.
> A-la Satoshi's blog post regarding increasing block size limit, a good
> enough approximation would be to add a block height check to the code
> that approximates X*N years, based on 10 minute blocks. The
> transparency around such a change would need to be radical and absolute.
>
> I'd also suggest that, similar to CLTV, it only makes sense to discuss
> creating a "never expire" transaction output, if such a feature were
> being seriously considered.
>
> If you think discussions around a block size increase were difficult,
> then we'll need a new word to describe the challenges and vitriol that
> would arise in arguments that will follow this discussion should it be
> seriously proposed, IMHO.
>
> I also don't think it's reasonable to conflate the discussion herein
> with discussion about what to do when ECC or SHA256 is broken. The
> weakening/breaking of ECC poses a real risk to the stability of
> Bitcoin - the possible release of Satoshi's stash being the most
> obvious example - and what to do about that will require serious
> consideration when the time comes. Even if the end result is the same
> - that coins older than "X" will be invalidated - everything else
> important about the scenarios are different as far as I can see.
>
> Rodney
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/8c69cf2e/attachment.html>

2023-06-07 18:04:57

- reply

📅 Original date posted:2017-08-22
📝 Original message:On 22/08/17 06:17 PM, Daniele Pinna via bitcoin-dev wrote:
> Also.... how is this not a tax on coin holders? By forcing people to
> move coins around you would be chipping away at their wealth in the
> form of extorted TX fees.
>
As if the fee for one tx per decade (or more if we'd like) matters, plus
it could be very low priority. In fact we could re-allow free
transactions based on old priority rules (oldest outputs gets higher
priority... I would suggest considering reduction in utxo size as well
but that's another topic).
Actually, to ensure miners allow these transaction one rule could be
that the block must contain free transactions on old utxo's ("old" TBD)
to reclaim from the scavenged pool... One side effect is that mining
empty blocks before previous block TX can be validated would reduce the
reward.
I'd love to find clever approach where we could somehow make a
verifiable block check that old tx refresh are included... I haven't put
much thoughts into it yet but if there was a way a two-step transaction
where 1. a fee is paid to register an UTXO refresh (miners would be
encouraged to accept it and increase their immediate revenue), and 2.
the fee must be returned from the pool on a later block. The idea is to
allow free scavenging of own addresses while discouraging miners from
refusing free transactions so they could eventually reclaim the coins. I
can't think of a way that limits the burden on consensus rules...
--
Thomas

2023-06-07 18:04:54

- reply

📅 Original date posted:2017-08-22
📝 Original message:In any case when Hal Finney do not wake up from his 200years
cryo-preservation (because unfortunately for him 200 years earlier they
did not know how to preserve a body well enough to resurrect it) he
would find that advance in computer technology made it trivial for
anyone to steal his coins using the long-obsolete secp256k1 ec curve
(which was done long before, as soon as it became profitable to crack
down the huge stash of coins stale in the early blocks)
I just don't get that argument that you can't be "your own bank". The
only requirement coming from this would be to move your coins about once
every 10 years or so, which you should be able to do if you have your
private keys (you should!). You say it may be something to consider when
computer breakthroughs makes old outputs vulnerable, but I say it's not
"if" but "when" it happens, and by telling firsthand people that their
coins requires moving every once in a long while you ensure they won't
do stupid things or come back 50 years from now and complain their
addresses have been scavenged.
--
Thomas
On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
> I agree, it is only a good idea in the event of a quantum computing
> threat to the security of Bitcoin.
>
> On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> This seems to be drifting off into alt-coin discussion. The idea
> that we can change the rules and steal coins at a later date
> because they are "stale" or someone is "hoarding" is antithetical
> to one of the points of bitcoin in that you can no longer control
> your own money ("be your own bank") because someone can at a later
> date take your coins for some reason that is outside your control
> and solely based on some rationalization by a third party. Once
> the rule is established that there are valid reasons why someone
> should not have control of their own bitcoins, what other reasons
> will then be determined to be valid?
>
> I can imagine Hal Finney being revived (he was cryo-preserved at
> Alcor if you aren't aware) after 100 or 200 years expecting his
> coins to be there only to find out that his coins were deemed
> "stale" so were "reclaimed" (in the current doublespeak - e.g.
> stolen or confiscated). Or perhaps he locked some for his
> children and they are found to be "stale" before they are
> available. He said in March 2013, "I think they're safe enough"
> stored in a paper wallet. Perhaps any remaining coins are no
> longer "safe enough."
>
> Again, this seems (a) more about an alt-coin/bitcoin fork or (b)
> better in bitcoin-discuss at best vs bitcoin-dev. I've seen it
> discussed many times since 2010 and still do not agree with the
> rational that embracing allowing someone to steal someone else's
> coins for any reason is a useful change to bitcoin.
>
>
>
>
> On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Okay so I quite like this idea. If we start removing at height
> 630000 or 840000 (gives us 4-8 years to develop this
> solution), it stays nice and neat with the halving interval.
> We can look at this like so:
>
> B - the current block number
> P - how many blocks behind current the coin burning block is.
> (630000, 840000, or otherwise.)
>
> Every time we mine a new block, we go to block (B-P), and
> check for stale coins. These coins get burnt up and pooled
> into block B's miner fees. This keeps the mining rewards up in
> the long term, people are less likely to stop mining due to
> too low fees. It also encourages people to keep moving their
> money around the enconomy instead of just hording and leaving it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/bc4992c0/attachment.html>

2023-06-07 18:04:52

- reply

📅 Original date posted:2017-08-21
📝 Original message:On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote:
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>>:
>
> [...] But the fact is that if we want to make bitcoins last forever,
> we have the accept unbounded UTXO growth, which is unscalable. So
> the only solution is to limit UTXO growth, meaning bitcoins cannot
> last forever. This proposed solution however does not prevent
> Bitcoin from lasting forever.
>
>
> Unless there is a logical contradiction in this phrasing, the proposed
> solution does not improves scalability:
> - "Bitcoins lasting forever" implies "unscalable";
> - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
> forever";
> - Thus: "not prevent Bitcoin from lasting forever" implies "unscalable".
>
> In practice, the only Bitcoin lost would be those whose owners forgot
> about or has lost the keys, because everyone with a significant amount
> of Bitcoins would always shift them around before it loses any luster (I
> wouldn't bother to move my Bitcoins every 10 years). I don't know how to
> estimate the percentage of UTXO is actually lost/forgotten, but I have
> the opinion it isn't worth the hassle.
>
> As a side note, your estimate talks about block size, which is
> determines blockchain size, which can be "safely" pruned (if you are not
> considering new nodes might want to join the network, in case the full
> history is needed to be stored somewhere). But UTXO size, albeit related
> to the full blockchain size, is the part that currently can not be
> safely pruned, so I don't see the relevance of the analysis.
I think if we wanted to burn lost/stale coins a better approach would be
returning them to miner's as a fee - there will always be lost coins and
miners will be able to get that additional revenue stream as the mining
reward halves. I also don't think we need to worry about doing a gradual
value loss neither, we should just put a limit on UTXO age in block
count (actually I would round it up to 210k blocks as explained below...).
So lets say for example we decide to keep 5 210k blocks "generations"
(that's over 15 years), then on the first block of the 6th generation
all UTXO's from the 1st generation are invalidated and returned into a
"pool".
Given these (values in satoshis):
Pool "P" (invalided UTXO minus total value reclaimed since last halving)
Leftover blocks "B" (210,000 minus blocks mined since last halving)
Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
miner's reward and tx fees.
If the last block of a generation does not get the remainder of the pool
(FLOOR(P/1) == P) it should get carried over.
This would ensure we can clear old blocks after a few generations and
that burnt/lost coins eventually get back in circulation. Also it would
reduce the reliance of miners on actual TX fees.
To avoid excessive miner reward initially, for the first few iterations
the value of B could be increased (I haven't calculated the UTXO size of
the first 210k blocks but it could be excessively high...) or the value
each block can reclaim could be caped (so we would reclaim at an
artificial capacity until the pool depletes...).
Regards,
--
Thomas