Vincent Truong [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 20:29:54

- reply

📅 Original date posted:2021-03-03
📝 Original message:I must remind everyone of Mike Hearn's proposal not many years ago, which
ought to be on everyone's mind right now. "Every soft fork should be a hard
fork, and that soft forks are inherently dangerous because old nodes are
tricked to not know what the new nodes are doing" (paraphrased). Whether
taproot is dangerous is not the issue; whether old nodes should or should
not ignore new rules, is.
Flag day activation of a soft fork is basically proposing a hard fork, but
without saying or doing it at full commitment. May as well just do a flag
day hard fork.
Bitcoin Cash/Bcash has already tested for you how a market driven hard fork
should work. Bitcoin didn't die. We should be learning from the mistakes
made in those early hard forks to not repeat them when Bitcoin hard forks -
like having replay protection written before deployment.
If it's not evident within the first 6-12 blocks which fork is winning,
then the market will trade it out. Just like what happened with Bitcoin
Cash/Bcash.
Not only that, it stops the drama of Bitcoin Core devs from "being in
control" of consensus. The market will choose, you just create the safest
way for users to participate. The market is consensus. Rough consensus is
just the conversation starter.
On Thu, 4 Mar 2021, 1:39 am Chris Belcher via bitcoin-dev, <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The bitcoin world is close to total gridlock on the question of how to
> activate taproot. There's no agreement on activation[1][2], and if an
> agreement isn't reached then nothing happens. That would be really
> terrible because we'd miss out on the benefits of taproot and
> potentially other future soft forks.
>
> A major problem with BIP8 is that it would result to a situation where
> different parts of the bitcoin ecosystem run different consensus rules.
> Some people will run LOT=true and others LOT=false. Worst of all, it
> becomes vulnerable to a twitter/reddit/social media blitz which could
> attempt to move the date of miner activation around.
>
> Twitter and reddit drama provide a perfect cover for social attacks on
> bitcoin.
>
> Forced signalling leads to brinksmanship. Where two or more sides
> (backed up by social media drama) enter into a game of chicken with
> deployed nodes. If one of them doesn't concede then we get a damaging
> chain split. And the $1 trillion in value that the bitcoin network
> protects is put at risk. From the point of view of a miner or big
> exchange stuck in the middle, if they look at the ecosystem of twitter
> and reddit (especially if you think about all the problems with bots and
> sockpuppets) they have no idea which consensus rules they should
> actually follow and exactly what date they take effect. Miners,
> exchanges, merchants and the rest of the ecosystem exist to serve their
> customers and users, and trouble happens when they don't know what their
> customers really want. Social media attacks are not just a theoretical
> concern; back during the block size drama, the bitcoin reddits were
> targetted by bots, sockpuppets and brigading[3].
>
> Enter flag day activation. With a flag day there can be no
> brinksmanship. A social media blitz cant do anything except have its own
> followers fork away. Crucially, miner signalling cant be used to change
> the activation date for nodes that didn't choose to and just passively
> follow signalling. Changing the activation date requires all those users
> to actually run different node software.
>
> Flag day activation works simply: we choose a block height and after
> that block height the new taproot rules become enforced.
>
>
> Supporters of the permissionless, "users rule" approach of LOT=true
> should be happy because it completely takes miners out of activation.
>
> Supporters of the safe, conservative approach of LOT=false can be made
> happy with a few ways of derisking:
>
> * Getting mining pools, businesses and users to look at the code and ask
> if they (a) think its either neutral or good for their business or use
> case and (b) they believe others view it similarly and that the
> consensus changes proposed have a good social consensus around them.
>
> * Setting the flag day far in the future (18 months or 2 years in the
> original proposal[3]).
>
>
> == What if flag day activation is used maliciously? ==
>
> What if one day the Core developer team is co-opted and uses the flag
> day method to do something bad? For example, a soft fork where sending
> to certain blacklisted addresses is not allowed. The bitcoin user
> community who wants to resist this can create their own
> counter-soft-fork full node, where the first block after the flag day
> MUST pay to one of those addresses on the blacklist. This forces a chain
> split between the censorship rules and the no-censorship rules, and its
> pretty obvious that the real bitcoin which most people follow will be
> the chain without censorship.
>
> For example, if a group of users didn't agree with taproot then they
> could create their own counter-flag-day-activation which requires that a
> transaction is included that does an invalid-spend from a taproot output
> in the first block after the flag day height.
>
> This is always possible with any user activated soft fork. In BIP8
> LOT=true it could be done by rejecting block headers with certain
> version bits signalled.
>
>
> == But it will take so long! ==
>
> We seem to be at a deadlock now. This will take less time than any other
> method, because other methods might never happen. BIP8 is dead and from
> what I see there's no other credible plan.
>
> We've already waited years for taproot. I remember listening to talks
> about bitcoin from 2015 of people discussing Schnorr signatures. And
> given how slow segwit and p2sh adoption were its pretty likely that
> we'll waiting a while for taproot to be actually adopted.
>
>
> == A social media blitz could still try to activate it early ==
>
> The brinksmanship only works because miner signalling can make many
> other nodes activate early, even if those other nodes didn't do
> anything. There can't be a game of chicken that puts the bitcoin network
> at risk.
>
> If a group of people did adopt alternative node software which has a
> shorter flag day, they actually have a risk of slow blocks. Because they
> cant trick or force any other nodes to come along with them, they are
> likely to only have a small economy and therefore would lose a lot of
> hashrate. Imagine trading bitcoins for cash in person and instead of
> waiting 10 minutes for a confirmation you have to wait 3 hours because
> the blocks are slow.
>
> Also, the argument for downloading and running a different software only
> to speed up activation is pretty weak. Taproot would activate in ~18
> months, so why are you so impatient that you need it in 6 months? And
> risk slow blocks for you while doing so? The big difference with BIP148
> the segwit UASF, is that people *had to* run some other software
> otherwise they would get *no soft fork at all*.
>
>
> == Without miner signalling how do we know the new rules are even
> activated? ==
>
> When did you see miners signalling their support for the inflation
> schedule?
>
> Bitcoin's rules are enforced by wallets backed by full nodes. You'll
> always know if your own full node is enforcing the new rules. The thing
> that matters isnt miner signalling but your own full node, and the nodes
> of those you trade with.
>
> Flag day activation is quite similar to the way block reward halvenings
> work. At and after block height 630000 miners are only allowed to create
> 6.25 BTC rather than 12.5 BTC. Everyone knows that if miners continued
> to create 12.5 BTC or more they would be unable to sell or spend those
> coins anywhere.
>
> In 2017 when segwit was being activated people created a huge list of
> various bitcoin companies, merchants and wallets:
>
> https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/
> Looking at that list, you would know that if someone stole coins from a
> segwit address they would be unable to deposit them in many exchanges
> and merchants: Bitrefill, Bitstamp, Kraken, Localbitcoins, Paxful,
> Vaultoro, HitBTC, etc.
>
> Then what happened is only a month after S2X was beaten this guy moved
> 40000 BTC to a segwit address, confident about the power of the network
> to protect his coins.
>
> https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_famous_user_loaded_moved_his_40k_btc/
>
> If there's ever any doubt about flag day activation we can always draw
> up a similar list, although if there's broad consensus about it then
> there's no reason why bitcoin businesses wouldn't upgrade to the latest
> Core, like they did with every other previous soft fork.
>
>
> == This gives the impression that Core developers control the protocol ==
>
> This objection has a mirror image argument: BIP8 with LOT=false gives
> the impression that miners control the protocol(!)
>
> Eventually some group has to make a decision. We will ask the bitcoin
> economy and users what they think of flag day activation. It's pretty
> clear that nobody seriously objects to taproot, and as described above
> if Core developers did something evil the community could resist it with
> a counter-flag-day-activation.
>
>
>
> == TL;DR ==
>
> I believe flag day activation is the way forward. It should answer all
> the objections and risks which make other methods too controversial.
> Let's go ahead and bring taproot to bitcoin!
>
>
>
> == References ==
>
> [1] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
> luke-jr posts saying LOT=false in his view reintroduces a bug, he
> compares it to introducing an inflation bug and just hoping that miners
> will not exploit it.
>
> [2] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html
> This whole thread has many people disagreeing with LOT=true
>
> [3] -
>
> https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_instantaneous_vote_behavior_in/
>
>
> https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please_have_a_civil_discussion_about/cxjnz1d/?context=1
>
>
> https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_to_destroy_bitcoin_on_this_thread/cz6ccka/?context=3
>
> [4] -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018495.html
> Matt Corallo's flag day activation proposal
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210304/8c0b88e9/attachment.html>

2023-06-07 19:46:12

- reply

📅 Original date posted:2015-12-12
📝 Original message:Dormant threshold is way too low. There's many news articles about people
forgetting that they used to mine bitcoins and then suddenly remembered.
This will continue to happen for much longer than 8 years as people
rediscover bitcoin when it goes further mainstream. You can't expect them
to have run a node/kept their utxo before they were aware of this change
and then realise miners have discarded their utxo. Oops?
Since we can't predict when mainstream will happen, you instead need a
threshold where the key holder is likely dead. That should be like 80 years
or 120 years, so 4.2m to 6.3m confirmations.
Next paragraph is off topic:
IMO it would be even better for these dormant & dead key holder's utxos to
also re-enter the economy as miner fees; let 1 dormant utxo to be mined per
block. It would need a hard fork. But then maybe people would stop being so
stupid with burning bitcoins/sending it to 1BitcoinEater, or mining a
million bitcoins from day 1 and leaving it, if they know it'll eventually
go into another miner's pockets. This could be used to fund cheap
transactions forever, and miners would be incentivised to hold copies of
these dormant utxos since it could become theirs one day. But this would be
even more controversial than just expiring them as we are in no short
supply of people who believe in Bitcoin's deflationary, fossil fuel
(burnable) economy, rather than a cyclical economy that better resembles
how we treat lost gold today...
On Dec 13, 2015 10:29 AM, "gb via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The general concept has merit and the basic outline here seems sound
> enough. I have harboured a notion for having "archived UTXO" for some
> time, this is essentially it. The retrieval from archive cost is on the
> UTXO holder not the entire storage network, which is then only bearing
> full 'instant' retrieval costs for N blocks.
>
> On Sat, 2015-12-12 at 15:09 -0500, jl2012--- via bitcoin-dev wrote:
> > It is a common practice in commercial banks that a dormant account might
> > be confiscated. Confiscating or deleting dormant UTXOs might be too
> > controversial, but allowing the UTXOs set growing without any limit
> > might not be a sustainable option. People lose their private keys.
> > People do stupid things like sending bitcoin to 1BitcoinEater. We
> > shouldn’t be obliged to store everything permanently. This is my
> > proposal:
> >
> > Dormant UTXOs are those UTXOs with 420000 confirmations. In every block
> > X after 420000, it will commit to a hash for all UTXOs generated in
> > block X-420000. The UTXOs are first serialized into the form:
> > txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
> > After some confirmations, nodes may safely delete the UTXO records of
> > block X permanently.
> >
> > If a user is trying to redeem a dormant UTXO, in addition the signature,
> > they have to provide the scriptPubKey, height (X), and UTXO value as
> > part of the witness. They also need to provide the Merkle path to the
> > dormant UTXO commitment.
> >
> > To confirm this tx, the miner will calculate a new Merkle hash for the
> > block X, with the hash of the spent UTXO replaced by 1, and commit the
> > hash to the current block. All full nodes will keep an index of latest
> > dormant UTXO commitments so double spending is not possible. (a
> > "meta-UTXO set")
> >
> > If all dormant UTXOs under a Merkle branch are spent, hash of the branch
> > will become 1. If all dormant UTXOs in a block are spent, the record for
> > this block could be forgotten. Full nodes do not need to remember which
> > particular UTXO is spent or not, since any person trying to redeem a
> > dormant UTXO has to provide such information.
> >
> > It becomes the responsibility of dormant coin holders to scan the
> > blockchain for the current status of the UTXO commitment for their coin.
> > They may also need to pay extra fee for the increased tx size.
> >
> > This is a softfork if there is no hash collision but this is a
> > fundamental assumption in Bitcoin anyway. The proposal also works
> > without segregated witness, just by replacing "witness" with "scriptSig"
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151213/8ec46cd1/attachment.html>

2023-06-07 19:45:52

- reply

📅 Original date posted:2015-12-08
📝 Original message:I suppose whether the wallet devs want to implement the soft fork or not is
irrelevant. They only need to indicate if they are ready i.e. they've
tested the new soft fork, hard fork or feature and validated that it
doesn't break their nodes or wallet software.
On Dec 9, 2015 6:40 AM, "Chris Priest" <cp368202 at ohiou.edu> wrote:
> I proposed in my Wildcard Inputs BIP that the version field be split
> in two. The first 4 bytes are version number (which in practice is
> being used for script version), and the second 4 bits are used for
> transaction type.
>
> I don't think the BIP9 mechanism really applies to transactions. A
> block is essentially a collection of transactions, therefore voting on
> the block applies to the many parties who have transactions in the
> block. A transaction on the other hand only effects at most two
> parties (the sender and the receiver). In other words, block are
> "communal" data structures, transactions are individual data
> structures. Also, the nature of soft forks are that wallets can choose
> to implement a new feature or not. For instance, if no wallets
> implement RBF or SW, then those features effectively don't exist,
> regardless of how many nodes have upgraded to handle the feature.
>
> Any new transaction feature should get a new "type" number. A new
> transaction feature can't happen until the nodes support it.
>
> On 12/8/15, Vincent Truong via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > So I have been told more than once that the version announcement in
> blocks
> > is not a vote, but a signal for readiness, used in isSupermajority().
> > Basically, if soft forks (and hard forks) won't activate unless a
> certain %
> > of blocks have been flagged with the version up (or bit flipped when
> > versionbits go live) to signal their readiness, that is a vote against
> > implementation if they never follow up. I don't like this politically
> > correct speech because in reality it is a vote... But I'm not here to
> argue
> > about that... I would like to see if there are any thoughts on
> > extending/copying isSupermajority() for a new secondary/non-critical
> > function to also look for a similar BIP 9 style version bit in txns.
> > Apologies if already proposed, haven't heard of it anywhere.
> >
> > If we are looking for a signal of readiness, it is unfair to wallet
> > developers and exchanges that they are unable to signal if they too are
> > ready for a change. As more users are going into use SPV or SPV-like
> > wallets, when a change occurs that makes them incompatible/in need of
> > upgrade we need to make sure they aren't going to break or introduce
> > security flaws for users.
> >
> > If a majority of transactions have been sent are flagged ready, we know
> > that they're also good to go.
> >
> > Would you implement the same versionbits for txn's version field, using 3
> > bits for versioning and 29 bits for flags? This indexing of every txn
> might
> > sound insane and computationally expensive for bitcoin Core to run, but
> if
> > it isn't critical to upgrade with soft forks, then it can be watched
> > outside the network by enthusiasts. I believe this is the most
> politically
> > correct way to get wallet devs and exchanges involved. (If it were me I
> > would absolutely try figure out a way to stick it in isSupermajority...)
> >
> > Miners can watch for readiness flagged by wallets before they themselves
> > flag ready. We will have to trust miners to not jump the gun, but that's
> > the trade off.
> >
> > Thoughts?
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/86112498/attachment-0001.html>

2023-06-07 19:45:52

- reply

📅 Original date posted:2015-12-08
📝 Original message:So I have been told more than once that the version announcement in blocks
is not a vote, but a signal for readiness, used in isSupermajority().
Basically, if soft forks (and hard forks) won't activate unless a certain %
of blocks have been flagged with the version up (or bit flipped when
versionbits go live) to signal their readiness, that is a vote against
implementation if they never follow up. I don't like this politically
correct speech because in reality it is a vote... But I'm not here to argue
about that... I would like to see if there are any thoughts on
extending/copying isSupermajority() for a new secondary/non-critical
function to also look for a similar BIP 9 style version bit in txns.
Apologies if already proposed, haven't heard of it anywhere.
If we are looking for a signal of readiness, it is unfair to wallet
developers and exchanges that they are unable to signal if they too are
ready for a change. As more users are going into use SPV or SPV-like
wallets, when a change occurs that makes them incompatible/in need of
upgrade we need to make sure they aren't going to break or introduce
security flaws for users.
If a majority of transactions have been sent are flagged ready, we know
that they're also good to go.
Would you implement the same versionbits for txn's version field, using 3
bits for versioning and 29 bits for flags? This indexing of every txn might
sound insane and computationally expensive for bitcoin Core to run, but if
it isn't critical to upgrade with soft forks, then it can be watched
outside the network by enthusiasts. I believe this is the most politically
correct way to get wallet devs and exchanges involved. (If it were me I
would absolutely try figure out a way to stick it in isSupermajority...)
Miners can watch for readiness flagged by wallets before they themselves
flag ready. We will have to trust miners to not jump the gun, but that's
the trade off.
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/7274423d/attachment.html>

2023-06-07 19:41:02

- reply

📅 Original date posted:2015-09-23
📝 Original message:All,
Current meeting time visualised globally.
http://everytimezone.com/#2015-9-24,420,4ia
jl,
I think I found a good compromise: if the US want to accommodate Asia and
willing to sacrifice preference, 23:00 to 00:00 UTC might work.
http://everytimezone.com/#2015-9-24,660,4ia
It isn't easy to grab everyone's preference and accommodate everyone, so
this might work in theory but people may not be free to show up. US should
be ok. UK can participate or catch some nice z. Asia will need a bit of
early bird time but it's not as crazy as 3am. AU also fits in there nicely.
A meeting like this once a month should be enough probably (say, do this on
the first week of the month, and run every other week on the main
schedule). But I don't know whether there are enough people in Asia/AU to
make it worth it. Asia/AU people, thoughts?
On Sep 23, 2015 9:01 PM, "jl2012 via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There could not be a worse timing than this for those in China (3-4am),
> Japan/Korea (4-5am), and Australia (3-6am depends on which part of the
> country). Maybe we have no dev in this part of the planet? Is there any
> chance to review the timing in a weekly or monthly basis (also with a
> doodle vote?)
>
> Will there be any agenda published before the meetings? If I'm really
> interested in the topics, I'll have some reasons to get up in the middle of
> the night.
>
> Wladimir J. van der Laan via bitcoin-dev 於 2015-09-22 10:36 寫到:
>
>> Hello,
>>
>> There was overwhelming response that weekly IRC meetings are a good thing.
>>
>> Thanks to the doodle site we were able to select a time slot that
>> everyone (that voted) is available:
>>
>> Thursday 19:00-20:00 UTC, every week, starting September 24 (next
>> Thursday)
>>
>> I created a shared Google Calendar here:
>>
>> https://www.google.com/calendar/embed?src=MTFwcXZkZ3BkOTlubGliZjliYTg2MXZ1OHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
>>
>> The timezone of this calendar is Reykyavik (Iceland) which is UTC+0.
>> However, you can use the button on the lower right to add the calendar
>> to your own calendar, which will then show the meeting in your own
>> timezone.
>>
>> See you then,
>>
>> Wladimir
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150924/41e7146a/attachment-0001.html>

2023-06-07 19:40:58

- reply

📅 Original date posted:2015-09-18
📝 Original message:This way lets us protect from 51% overwrites for a whole year:
1. Hash utxo set as is today, H1, and store it in a block.
2. At the same time, store a copy of the utxo set for H1 on disk, D1
3. After 1 year, create D2, then wait for H2 (if a fork happens then
recreate D2 and see which wins)
4. The block with H2 must hash on top of H1
4. Blocks before H1 can be safely pruned by the network, only keeping D1
for reference/validation, plus blocks the node wants to keep (data/colored
coins)
5. After 1 year, repeat for H3.
7. D1 can also be dropped after a few days once D3 is up, since the H1
securing D1 would have been pruned with H3's usage of D2 by then.
This reduces the security model from 'always secure' to 'secure, as of last
year'. An attacker will need to have hidden hashing power to overwrite a
years worth of blocks. Which I think would be hard enough.
The attacker can also try to undo a freshly built Hn, but because we can
build Dn first and wait for Hn, the nodes should be expecting the same
hash. They also serve as automated checkpoints to prevent them from
overwriting all of it.
On Sep 19, 2015 6:38 AM, "Jorge Timón" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> s/move the genesis block forward/move your genesis checkpoint forward/
> On Sep 18, 2015 4:37 PM, "Jorge Timón" <jtimon at jtimon.cc> wrote:
>
>> Well, with utxo commitments at some point maybe is enough to validate the
>> full headers history but only the last 5 years of ttansaction history
>> (assuming utxo commitments are buried 5 years worth of blocks in the past).
>> This scales much better than validating the full history and if we get a 5
>> year reorg something is going really wrong anyway...
>> Maybe after validating the last 5 years you also want to validate the
>> rest of the history backards to get the "fully-full node" security.
>> Of course 5 years it's just an arbitrary number: 2 or maybe even 1 would
>> probably be secure enough for most people. I've referred to this idea as
>> "hard checkpoints" or "moving the genesis block forward" in the past.
>> On Sep 18, 2015 4:18 PM, "Rune Kjær Svendsen" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150919/91e1268c/attachment-0001.html>

2023-06-07 19:40:01

- reply

📅 Original date posted:2015-09-11
📝 Original message:Would this alter the way txns will be prioritised in order to try to win?
You would always pick txns with the best BTCDD to maximize your chances of
being the block to build on.
I see this as potentially being a bad outcome for bitcoin's fungibility.
On Sep 12, 2015 5:26 AM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Yes, this proposal is a policy that everyone would be free to ignore. I
> should have introduced the situation in which this *unenforceable* policy
> makes sense to me. Here it is:
>
> Every miner is listening for valid block solutions but might receive two
> valid blocks and then they have to decide which one to use. Choosing the
> one you saw first is the default behavior. In that situation, we'd all
> like everyone to choose the same block. I propose that a better heuristic
> than "first seen" is to compare the BTCDD, *but only of transactions you
> already have in your mempool*, and
>
> *weight the BTCDD so that txns you got earlier are more important.*
> The heuristic is most useful when the two blocks are received within a
> small window of time, opting for the first-seen rule otherwise. I assume
> many miners have an idea of how long it takes for anyone's new block to get
> across the network, and more specifically, the range of times it takes for
> new solutions to get to themselves. During this little time window, the
> chances are 50/50 that they'll choose the right block. If the default
> behavior were to use BTCDD during that time window (one second? I have no
> idea!), then the chances would be significantly better.
>
> I think Jorge is right that it doesn't benefit miners. It doesn't hurt
> them either, unless they are trying to do selfish mining. Well, it
> benefits them in terms of increased bitcoin stability by A) making it
> easier for clients to decide which block is valid when they see two
> competing with each other, B) motivating miners to add transactions instead
> of mining empty blocks, C) severely decreasing the utility of any global
> private network of nodes intended to spread selfishly-mined blocks, and D)
> motivating miners to stay well-connected so that they get transactions
> quickly.
>
> I sent this to the list because it is only useful if it is set as default
> behavior since most miners leave the defaults alone, and the benefits don't
> materialize unless a majority follows the policy.
>
> On Fri, Sep 11, 2015 at 11:37 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>>
>> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca at gmail.com>
>> wrote:
>> >
>> > It's pretty obvious that Dave is suggesting an alternate tie-breaker:
>>
>> I thought he was proposing a new consesnsus rule. I see, this would be
>> just a policy validation that everybody would be free to ignore (like the
>> "first seen" spend conflict tx replacement policy).
>>
>> I don't see how miners would benefit from running this policy so I would
>> not expect them to run it in the long run (like the "first seen" spend
>> conflict tx replacement policy).
>> If miners don't use it, I don't see how users can benefit from running
>> that policy themselves.
>> They will still have to keep waiting some block confirmation to
>> exponentially reduce the chances of a successful double-spend attack with
>> each new confirmation (as explained in the bitcoin white paper).
>>
>> > Mind you, that risk doesn't apply if we prefer non-empty blocks to
>> > empty blocks and leave it at that, or only switch if the new block
>> > doesn't double spend transactions in the old one, so it's a fixable
>> > issue.
>>
>> How do you know which of 2 blocks with the same height is "newer"?
>>
>> > On 11 September 2015 at 12:32, Jorge Timón
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > >
>> > > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
>> > > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > >>
>> > >> Rather than (promising to, and when they don't actually, at least
>> > >> pretending to) use the first-seen block, I propose that a more
>> sophisticated
>> > >> method of choosing which of two block solutions to accept.
>> > >
>> > > There's already a criterion to chose: the one with more work (in valid
>> > > blocks) on top of it.
>> > >
>> > >
>> > > _______________________________________________
>> > > bitcoin-dev mailing list
>> > > bitcoin-dev at lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > >
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150912/222cba76/attachment-0001.html>

2023-06-07 17:43:13

- reply

📅 Original date posted:2015-07-24
📝 Original message:"Fast transactions"
Fast transactions implies it is slower than Visa, and Visa is 'instant' by
comparison from the spender's POV. Bitcoin is still very instant because
wallets still send notifications/pings when transactions are first seen,
not when it goes into a block. We shouldn't mislead people into thinking a
transaction literally takes 10 minutes to travel the globe.
Maybe this feels like PR speak. But being too humble about Bitcoin's
attributes isn't a good idea either.
If we're going to look at perception, image and expectations, perhaps we
can start to look at redefining some terminology too. Like confirmations,
which is an arbitrary concept. Where possible we should describe it with
finance terminology.
"0 conf transaction"
0 conf is the 'transaction' - just the act of making an exchange. It
doesn't imply safe and I believe using the word 'settle' in place of
confirmations will automatically click with merchants.
"1st conf"
A 'confirmation' is a 'settlement'. If it is 'settled', it implies final
(except by court order), whereas confirmation usually means 'ah, I've seen
it come through'. I rarely hear any sales clerk call credit card
transactions confirmed. More often you will hear 'approved' instead.
Although 1st conf can be overtaken, so...
"n confirmations"
This term can probably stay since I can't come up with a better word.
Settlements only happen once, putting a number next to it breaks the
meaning of the word. "Settled with 4 confirmations" seems pretty clear.
Alternatively I think instead of displaying a meaningless number we ought
to go by a percentage (the double spend improbability) and go by
'confidence'. "Settled with 92% confidence." Or we can pick an arbitrary
number like 6 and use 'settling...' and 'settled' when reached.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150725/77062ad2/attachment.html>

2023-06-07 17:36:32

- reply

📅 Original date posted:2015-06-03
📝 Original message:Some changes:
Votes need to be 100%, not 50.01%. That way small miners have a fair
chance. A 50.01% vote means large miners call the shots.
Users (people who make transactions) need to vote. A vote by a miner
shouldn't count without user votes. Fee incentives should attract
legitimate votes from miners. A cheating miner will be defeated by another
miner who includes those votes, and take the fees.
This lets wallet providers and exchanges cast votes (few wallets will
implement prompts and will just auto vote, so if you don't agree, switch
wallets. Vote with your wallet).
~Vince
On Jun 3, 2015 12:34 PM, "Stephen Morse" <stephencalebmorse at gmail.com>
wrote:
> Pindar,
>
> yes and it's a good idea to separate the hard/soft fork upgrades. The
>> point being here is that we're also establishing a process for the
>> community to self-determine the way forward in a transparent and verifiable
>> manner.
>>
>> What's not to like? :)
>>
>> I'll probably have some time on Sunday to help hack something up but I
>> don't think this is that heavy a coding lift? What am I missing?
>>
>
> As Matt mentioned, many members of the bitcoin community would be hesitant
> about giving miners this much power. It essentially lets them vote to
> change the rules of the system. But miners are not the only part of this
> ecosystem, and they are not the only ones affected by the choice of block
> size limit, so they probably shouldn't be the only ones with a vote.
> Instead, we vote with the software we run, and all upgrade.
>
> So, while I think an idea like this has its merits, I would bet that it's
> fairly unlikely to get enough support to be merged into bitcoin core.
>
> Best,
> Stephen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150603/9795292e/attachment.html>