gb [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-05-11 to 2018-09-21
💬 Posted a total of 16 messages
📚 Participated in the following categories: Bitcoin-development, Bulk, bitcoin-dev, bitcoin-core-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 14:49:18

- reply

📅 Original date posted:2018-03-01
📝 Original message:
.... and any thoughts on protections against flood pinging?
On Thu, 2018-03-01 at 09:45 -0500, Jim Posen wrote:
> The main benefit is that this should make it quicker to send a
> successful payment because latency is lower than sending an actual
> payment and the sender could ping all possible routes in parallel,
> whereas they can't send multiple payments in parallel. The main
> downside I can think of is that, by the same token, it is faster and
> cheaper for someone to extract information about channel capacities on
> the network with a binary search.
>
>
> -jimpo
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:45:22

- reply

📅 Original date posted:2015-12-12
📝 Original message:
On Sun, 2015-12-13 at 01:03 +0000, Denis Gorbachev wrote:
> Hi everybody,
>
>
> Do you think it's a good idea to write a GUI for LN node management?
>
Yes.
>
> Which features would you like to see there?
> --
All of them.
>
> @DenGorbachev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:43:26

- reply

📅 Original date posted:2015-06-23
📝 Original message:
lightning

2023-06-07 20:07:31

- reply

📅 Original date posted:2017-11-02
📝 Original message: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" <greg at xiph.org> wrote:
> On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:54:04

- reply

📅 Original date posted:2016-10-16
📝 Original message: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.

2023-06-07 19:46:12

- reply

📅 Original date posted:2015-12-12
📝 Original message: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

2023-06-07 19:40:54

- reply

📅 Original date posted:2015-09-21
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:43:13

- reply

📅 Original date posted:2015-07-24
📝 Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:42:45

- reply

📅 Original date posted:2015-07-22
📝 Original message:Why RSA?
>
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.
>
> * Each server S publishes a RSA public key, KS
> * Each client receives a list of available servers and their pubkeys
> * For each wallet address, addr_i, a client chooses a server S_i, and a
> RSA keypair (K_addr_i, k_addr_i)
> * The client creates a list of encrypted requests. Each request contains
> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> * The client chooses a main server M, and sends the list of encrypted
> requests to M
> * M dispatches the client's requests to the corresponding servers S_i
> (without the client's IP address.)
> * Each server decrypts the requests it receives, performs the request,
> and encrypts the result with K_addr_i
> * M receives encrypted responses, and forwards them to the client.
> * The client decrypts the encrypted response with k_addr_i
>

2023-06-07 17:36:01

- reply

📅 Original date posted:2015-05-31
📝 Original message:Aren't you calculating bandwidth for a singly-connected node? A "highly
connected" miner could have 30-100 node connections so you probably need
to increase your traffic estimates by that factor.
I.e. For 100MB blocks, 30-100 Mbps and $60-$100 per day data costs.
> You should be able to handle 20MB blocks no problem; if I round up to
> 100MB per block that works out to 1.3Mbps.
>
>
> We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars
> per GB for
> 100Mbps connectivity at Aliyun.
>
>
> That speed will handle 20MB blocks no problem.
>
>
> If each 20MB block is 100MB of data up/down the wire (I'm vastly
> over-estimating, after optimization it should be 40MB) then you'll be
> paying...uhhh:
>
>
> 0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13
> $ / GB = $57
>
>
> Less than $2 per day in bandwidth.
>
> For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
>
>
> That's OK, you'll 1.3Mbps or less
> --
> --
> Gavin Andresen
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:34:57

- reply

📅 Original date posted:2015-05-11
📝 Original message:Hi,
the attached document is a simplified costing analysis that may serve a
useful approach for network scaling discussions.
Regards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: costing.pdf
Type: application/pdf
Size: 112525 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150512/c0c16c3f/attachment.pdf>