Re: [bitcoin-dev] [bitcoin-core-dev] Bitcoin Core update notice

[gb via bitcoin-dev]

If the bugfix can be backported to earlier versions why is the
hype/hysteria about "everybody" must immediately upgrade to 0.16.3
currently being spread on the forums/reddit?

https://bitcointalk.org/index.php?topic=5034070.0
https://old.reddit.com/r/Bitcoin/comments/9hp90p/1775_nodes_out_of_9616_185_are_currently_on/

I don't see any effort to correct this misinformation either.

Regards.

On Tue, 2018-09-18 at 17:06 -0700, Pieter Wuille via bitcoin-core-dev
wrote:
> Hello all,
> 
> Bitcoin Core 0.16.3 was just released with a fix for
> CVE-2018-17144:
> https://bitcoincore.org/en/2018/09/18/release-0.16.3/
> 
> We urge all network participants to upgrade to 0.16.3[*] as soon
> as possible.
> 
> [*] For those who build from source, the 0.14, 0.15, 0.16, 0.17,
> and master branches on GitHub (https://github.com/bitcoin/bitcoin)
> are fixed as well.
> 
> --
> Pieter
> ___
> bitcoin-core-dev mailing list
> bitcoin-core-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev


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

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

[gb via bitcoin-dev]

You launched the political football by coming here with a verbose
'recommendation'. Without a code submission in form of pull request to
the core repo on github this was never a technical discussion.

On Thu, 2017-11-02 at 19:53 -0400, Scott Roberts via bitcoin-dev wrote:
> Whatever their failings from their previous code or their adversarial
> nature, they got this code right and I'm only presenting it as a real
> and excellent solution for the impending threat to bitcoin. As a big
> core fan, I really wanted to delete the word Cash from my post because
> I was afraid someone would turn this technical discussion into a
> political football.
> 
> On Nov 2, 2017 7:37 PM, "Gregory Maxwell"  wrote:
> On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev
>  wrote:
> > Bitcoin cash will hard fork on Nov 13 to implement a new
> difficulty
> > algorithm.  Bitcoin itself might need to hard fork to employ
> a similar
> > algorithm. It's about as good as they come because it
> followed the
> 
> 
> This is the bitcoin development mailing list, not the "give
> free
> review to the obviously defective proposals of adversarial
> competing
> systems" mailing list. Your posting is off-topic.
> 
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[gb via bitcoin-dev]

It's controversial not contriversial.

And it isn't controversial except among a small clique, which you seem
to be the sole representative of here. It might be time to consider
unsubscribing (again) if you don't seem to know when to shut up and the
moderators are letting you go on an inappropriate crusade here.

On Sun, 2016-10-16 at 22:58 +0200, Tom Zander via bitcoin-dev wrote:
> On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev 
> wrote:
> > It's not the website's fault if wallet devs aren't updating their
> > statuses. Besides, "WIP" can mean an awful lot of things.
> 
> As I said, it would be nice to get an updated version so we can see more 
> than 20% readyness of wallets.
> The wallet devs not caring enough to update the status should be a worrying 
> sign, though.
> 
> > A lot of devs have already worked on SegWit support. This has been
> > covered. Even if they don't support SegWit, the wallets will probably
> > work just fine. (For awhile, Armory did crash when trying to read SegWit
> 
> SegWit is probably the most disruptive and most invasive change ever made to 
> Bitcoin. We have miners actively saying they don't like it and this makes it 
> a contriversial upgrade which means the network may split and other issues.
> 
> Your "wallets will probably work just fine" comment is honestly not the 
> answer to make people put faith in the way that this is being vetted and 
> checked...
> 
> > Also, once again, FlexTrans is off-topic. 
> 
> Its an alternative and brought up in that vain. Nothing more. Feel free to 
> respond to the BIP discussion (134) right on this list if you have any 
> opinions on it. They will be on-topic there. No problems have been found so 
> far.
> 
> Lets get back to the topic. Having a longer fallow period is a simple way to 
> be safe.  Your comments make me even more scared that safety is not taken 
> into account the way it would.
> 
> People are not even acknowledging the damage a contriversial soft fork of 
> the scope and magnitude of SegWit can have, and a simple request to extend 
> the fallow time for safety is really not a big deal.
> SegWit has been in development for 18 months or so, what is a couple of 
> extra week??
> 
> I would just like to ask people to take the safety of Bitcoin serious. This 
> discussion and refusal to extend the safety period is not a good sign.


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

Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

[gb via bitcoin-dev]

On Fri, 2015-12-18 at 15:15 -0500, Jeff Garzik via bitcoin-dev wrote:
> My preference is height activation + one step per block (i.e. also
> height).  Height seems KISS.
> 
> 
Under this scheme the size of the step-per-block increase could be
decreased every 210,000 blocks (at time of reward halvings). 

So, a linear growth rate that decreases every ~4 years, ultimately
grandfathering max_block_size increases on the same block-schedule that
reward decreases.


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

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[gb via bitcoin-dev]

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 42 confirmations. In every block 
> X after 42, it will commit to a hash for all UTXOs generated in 
> block X-42. 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Weekly development meetings on IRC

[gb via bitcoin-dev]

Although the planning for this a bit far along now, one consideration I
might add from experience on working with other transglobal IT projects
is the effect of timezones on local mood/alertness/awareness etc. The
guys at 9am pinging on their first coffee in the antipodes will be in a
different mindset than those at 21:00 in Europe, and this is
unavoidable. What is possible is to schedule the meeting every other
week at a time that is better for the "other" half, whoever that might
be. This comes at the cost of not having an exactly same time set every
week.

On Mon, 2015-09-21 at 15:29 +0200, Wladimir J. van der Laan via
bitcoin-dev wrote:
> On Fri, Sep 18, 2015 at 03:07:10AM +0200, Wladimir J. van der Laan wrote:
> > Hello,
> > 
> > At Monday's code sprint we had a good idea to schedule a regular developer 
> > meeting in #bitcoin-dev.
> > 
> > Attendance is of course voluntary, but it may be good to have a time that 
> > many people are expected to be present and current issues can be discussed.
> > 
> > Any preference for days/times?
> > 
> > What about e.g. every week 15:00-16:00 UTC on Thursday?
> 
> From Jonasschnelli's doodle ( http://doodle.com/poll/cihug53sa8u4h2in#table ) 
> it appears that Thursday 19:00 UTC - 20:00 UTC is the most popular time.
> 
> I think scheduling the meeting in UTC (=Iceland time) makes sense 
> internationally because different locales have different DST or no DST at 
> all, so all in all that makes it more complex. It's true that this can make a 
> convenient time less convenient half of the year, for some people, but I 
> don't think there's a time that works for everyone anyway...
> 
> Wladimir
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Bitcoin, Perceptions, and Expectations

[gb via bitcoin-dev]

Validated - (seen on network) 

Settled/Cleared - 1 conf

Finalised - 6 confs

On Sat, 2015-07-25 at 00:37 +1000, Vincent Truong via bitcoin-dev wrote:
 
 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.
 
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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