Rune Kjær Svendsen [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-03-11 to 2016-04-17
💬 Posted a total of 13 messages
📚 Participated in the following categories: Bitcoin-development, PATCH, RFC, BIP proposal, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 19:40:59

- reply

📅 Original date posted:2015-09-19
📝 Original message:We need to distinguish between two different things here:
1) A 51% attack, where the majority of mining power is *malicious* (hence “attack”)
and
2) A fork that exists because of a disagreement in the network, with total mining power split in two camps, each camp mining peacefully on their own chain
These are two very different scenarios.
Some claim that including the UTXO set hash in the block creates a vulnerability where miners can include the wrong UTXO hash, and mine on that, but this is only possible if a 51% attack is in effect. And if a 51% attack is in effect, it’s a moot point, because Bitcoin is useless anyway, because that 51% malicious mining power could just as well be used for mining empty blocks on top of the official chain. Or blocks containing randomly generated transactions, without confirming any legitimate transactions. This is why we say that a majority of honest miners is a hard requirement for Bitcoin. A majority of dishonest miners can only be circumvented through centralisation, and then we don’t have Bitcoin any longer.
Scenario 2 is unproblematic regardless of whether we include the UTXO hash in the block (and make it consensus-critical) or not, since the majority mining power on either chain isn’t malicious.
It is correct that if you’re a full node, and a 51% attack is in effect, you are able to verify that miners are honest (ie. you know whether a 51% attack is in effect or not). But this doesn’t change the fact that the Bitcoin network is unreliable, at best, when a majority of mining power is used for malicious purposes.
/Rune
> On 19 Sep 2015, at 04:30, Justus Ranvier via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 18/09/15 15:17, Rune Kjær Svendsen via bitcoin-dev wrote:
>> Bitcoin does not function if the majority of mining power is dishonest. There is no way around that. It’s how proof-of-work functions.
>
>
> None of those statements are true.
>
> If a majority of Bitcoin miners are mining invalid blocks, then they
> aren't Bitcoin miners any more and are no longer relevant to the Bitcoin
> consensus.
>
> There does exist a problem that light clients aren't always able to tell
> the difference between chains that are valid and chains that are not
> valid, but it's is possible to create simple proofs that would do so:
>
> https://gist.github.com/justusranvier/451616fa4697b5f25f60
>
>
> If those changes would be implemented, then any node that knew a chain
> was invalid could produce a compact proof that anyone else in the
> network could verify, regardless of how much proof of work was used to
> create the invalid chain.
>
> Committed UTXO sets would need safe to rely upon if a similar set of
> proofs that a particular set was invalid existed.
>
> --
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus at openbitcoinprivacyproject.org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
> <0xEAD9E623.asc>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:40:56

- reply

📅 Original date posted:2015-09-18
📝 Original message:There are a couple of points I’d like to address.
Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not function if the majority of mining power is dishonest. There is no way around that. It’s how proof-of-work functions. And if we lose proof-of-work, we lose Bitcoin.
Secondly, I’m not suggesting that UTXO set hashes *replace* block hashes, or even that it should be in the block header (probably in the coinbase somewhere). I suggest it as an *addition* to the existing consensus rules. Full nodes can still verify the chain with the added step of hashing the UTXO set for every block. Of course, this can easily be deferred to after proof-of-work has been verified already, such that no work is wasted. Unless a 51% attack is in effect. But I argue that this is a moot point, since Bitcoin is useless anyway under such circumstances.
Lastly, I’m not suggesting miners discard the blockchain history. A miner has an incentive to be absolutely sure that the chain he’s building on is the right one. If he’s wrong, he loses money/income. There’s simply no reason for a professional miner *not* to do the full initial sync, which only needs to be done once. Non-miners, who just want to check the balance of their wallet, however, really don’t need to retrieve information about Hal Finney sending bitcoins to Satoshi in 2010. In any case, this practice isn’t sustainable.
In the end, it isn’t possible to control whether a miner verifies the entire blockchain anyway (anyone can send the UTXO set over the wire). Not letting the proof-of-work cover the UTXO hash doesn’t solve this problem, it only makes it impossible to know whether a given UTXO set is the one that the majority is mining on without retrieving the entire blockchain, and doing the verification yourself. People can choose to skip that regardless of what we do.
Furthermore, all nodes have the option of deciding which level of security they want. We’re not lessening security of the protocol, we’re strengthening the security of something that’s already possible to do (build on top of an unverified blockchain), but we’d rather want that people not do.
/Rune
> On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Full nodes using UTXO set commitments is a change to the bitcoin
> security model.
>
> Currently an attacker with >50% of the network hashrate can rewrite history.
>
> If full nodes rely on UTXO set commitments such an attacker could create
> an infinite number of bitcoins (as in many times more than the current
> 21 million bitcoin limit).
>
> Before we consider mechanisms for UTXO set commitments, we should
> seriously discuss whether the security model reduction is reasonable.
>
> On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote:
>> Currently, when a new node wants to join the network, it needs to retrieve the entire blockchain history, starting from January 2009 and up until now, in order to derive a UTXO set that it can verify new blocks/transactions against. With a blockchain size of 40GB and a UTXO size of around 1GB, the extra bandwidth required is significant, and will keep increasing indefinitely. If a newly mined block were to include the UTXO set hash of the chain up until the previous block — the hash of the UTXO set on top of which this block builds — then new nodes, who want to know whether a transaction is valid, would be able to acquire the UTXO set in a trustless manner, by only verifying proof-of-work headers, and knowing that a block with an invalid UTXO set hash would be rejected.
>>
>> I’m not talking about calculating a complicated tree structure from the UTXO set, which would put further burden on already burdened Bitcoin Core nodes. We simply include the hash of the current UTXO set in a newly created block, such that the transactions in the new block build *on top* of the UTXO set whose hash is specified. This actually alleviates Bitcoin Core nodes, as it will now become possible for nodes without the entire blockchain to answer SPV queries (by retrieving the UTXO set trustlessly and using this to answer queries). It also saves bandwidth for Bitcore Core nodes, who only need to send roughly 1GB of data, in order to synchronise a node, rather than 40GB+. I will continue to run a full Bitcoin Core node, saving the entire blockchain history, but it shouldn’t be a requirement to hold the entire transaction history in order to start verifying new transactions.
>>
>> As far as I can see, this also forces miners to actually maintain an UTXO set, rather than just build on top of the chain with the most proof-of-work. Producing a UTXO set and verifying a block against a chain is the same thing, so by including the hash of the UTXO set we force miners to verify the block that they want to build on top of.
>>
>> Am I missing something obvious, because as far as I can see, this solves the problem of quadratic time complexity for initial sync: http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
>>
>> The only added step to verifying a block is to hash the UTXO set. So it does require additional computation, but most modern CPUs have a SHA256 throughput of around 500 MB/s, which means it takes only two seconds to hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s). A small sacrifice for the added ease of initial syncing, in my opinion.
>>
>> /Rune
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:40:55

- reply

📅 Original date posted:2015-09-18
📝 Original message:Currently, when a new node wants to join the network, it needs to retrieve the entire blockchain history, starting from January 2009 and up until now, in order to derive a UTXO set that it can verify new blocks/transactions against. With a blockchain size of 40GB and a UTXO size of around 1GB, the extra bandwidth required is significant, and will keep increasing indefinitely. If a newly mined block were to include the UTXO set hash of the chain up until the previous block — the hash of the UTXO set on top of which this block builds — then new nodes, who want to know whether a transaction is valid, would be able to acquire the UTXO set in a trustless manner, by only verifying proof-of-work headers, and knowing that a block with an invalid UTXO set hash would be rejected.
I’m not talking about calculating a complicated tree structure from the UTXO set, which would put further burden on already burdened Bitcoin Core nodes. We simply include the hash of the current UTXO set in a newly created block, such that the transactions in the new block build *on top* of the UTXO set whose hash is specified. This actually alleviates Bitcoin Core nodes, as it will now become possible for nodes without the entire blockchain to answer SPV queries (by retrieving the UTXO set trustlessly and using this to answer queries). It also saves bandwidth for Bitcore Core nodes, who only need to send roughly 1GB of data, in order to synchronise a node, rather than 40GB+. I will continue to run a full Bitcoin Core node, saving the entire blockchain history, but it shouldn’t be a requirement to hold the entire transaction history in order to start verifying new transactions.
As far as I can see, this also forces miners to actually maintain an UTXO set, rather than just build on top of the chain with the most proof-of-work. Producing a UTXO set and verifying a block against a chain is the same thing, so by including the hash of the UTXO set we force miners to verify the block that they want to build on top of.
Am I missing something obvious, because as far as I can see, this solves the problem of quadratic time complexity for initial sync: http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s
The only added step to verifying a block is to hash the UTXO set. So it does require additional computation, but most modern CPUs have a SHA256 throughput of around 500 MB/s, which means it takes only two seconds to hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s). A small sacrifice for the added ease of initial syncing, in my opinion.
/Rune

2023-06-07 17:28:34

- reply

📅 Original date posted:2015-01-17
📝 Original message:Hi list
Found this on reddit: http://impulse.is/
PDF: http://impulse.is/impulse.pdf
I'd love to hear this list's thoughts.
/runeks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150117/813343df/attachment.html>

2023-06-07 17:02:32

- reply

📅 Original date posted:2013-05-31
📝 Original message:Hello dear list
I have an application that wants to keep up with new blocks as they come
in. For that I can use the -blocknotify option with bitcoind, which will
execute my application for each new block.
The problem is that my app isn't necessarily quick enough to finish its
work before a new block comes in and the app is executed again. This means
the that bitcoind might keep executing my application even though the
previous instance hasn't finished, and that's fairly inefficient
resource-wise, as many instances of the application will be running
simultaneously.
I've discussed this with wumpus on bitcoin-dev, and we figured out a
solution that might be better. It could replace -blocknotify or we could
put it in a new function called -batchblocknotify
The idea is that when bitcoind is executed with the -batchblocknotify
option, and it's missing a lot of blocks, upon the first incoming block,
the command specified by -batchblocknotify is executed, and if additional
blocks come in while this command is still running, we add the block hashes
to a list instead of executing the command again. When the previous command
finishes, we execute it again and pass two parameters to it: 1. the first
block hash in the list of queued blocks, and 2. the number of blocks that
have come in while the last command was executing.
This prevents bitcoind from "fork bombing" the system, and allows the
command to handle incoming blocks in batches.
Would this make sense as an approach?
I've been looking at the code and I'm not sure how to implement it.
As far as I can see, I need to pass an object - whose state is retained
between calls - to the thread function (runCommand) that runs the command,
which contains a variable that keeps track of whether a previously executed
command is still running, and that contains a list of block hashes that
haven't been processed. And I'm not sure how to do this.
The runCommand thread is started in SetBestChain() in
main.cpp. SetBestChain() is executed by ConnectBestBlock() in main.cpp.
ConnectBestBlock() is executed by CBlock::AddToBlockIndex() in main.cpp.
CBlock::AddToBlockIndex() is executed by CBlock::AcceptBlock() in main.cpp.
CBlock::AcceptBlock() is executed by ProcessBlock() in main.cpp.
ProcessBlock() is executed by ProcessMessage() in main.cpp. And so on, and
so forth.
What's the right way to create an object that can be passed to the
runCommand thread, whose state is retained, so it can hold information
about whether the -batchblocknotify command is still executing, and contain
a list of blocks that are waiting to be passed to the -batchblocknotify
command?
I assume I shouldn't add a new parameter to the ProcessMessage() function,
which passes it to ProcessBlock(), which passes it to AcceptBlock() which
passes it to AddToBlockIndex()... and so on.
Would it be appropriate to store this object inside the CValidationState
class that is passed to SetBestChain()?
I'm not quite so how to go about this.
/Rune
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130531/73ed57be/attachment.html>

2023-06-07 13:35:42

- reply

📅 Original date posted:2013-03-11
📝 Original message:On Mon, Mar 11, 2013 at 12:01 PM, Jorge Timón <jtimonmv at gmail.com> wrote:
> On 3/10/13, Peter Todd <pete at petertodd.org> wrote:
> > It's also been suggested multiple times to make transaction outputs with
> > a value less than the transaction fee non-standard, either with a fixed
> > constant or by some sort of measurement.
>
> As said on the bitcointalk thread, I think this is the wrong approach.
> This way you effectively disable legitimate use cases for payments
> that "are worth" less than the fees like smart property/colored coins.
> While the transactions pay fees, they should not be considered spam
> regardless of how little the quantities being moved are.
>
> Then your only concern are unspent outputs and comparing fees with
> values doesn't help in any way.
> Just activate a non-proportional
> demurrage (well, I won't complain if you just turn bitcoin into
> freicoin, just think that non-proportional would be more acceptable by
> most bitcoiners) that incentives old transactions to be moved and
> destroys unspent transactions with small amounts that don't move to
> another address periodically. This has been proposed many times before
> too, and I think it makes a lot more sense.
>
>From an economic point of view this *does* make sense, in my opinion.
Storing an unspent transaction in the block chain costs money because we
can't prune it. However, it would completely destroy confidence in Bitcoin,
as far as I can see. It makes sense economically, but it isn't feasible if
we want to maintain people's confidence in Bitcoin.
I like Jeff's proposal of letting an alt-coin implement this. If it gets to
the point where Bitcoin can't function without this functionality, it'll be
a lot easier to make the transition, instead of now, when it's not really
needed, and the trust in Bitcoin really isn't that great.
/Rune
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130311/28af919c/attachment.html>