sickpig at gmail.com [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-02-10 to 2018-09-22
💬 Posted a total of 14 messages
📚 Participated in the following categories: Bitcoin-development, 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 12:45:07

- reply

📅 Original date posted:2015-11-19
📝 Original message:
Hi Pierre
you could start here
https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
https://github.com/ElementsProject/elements
On Thu, Nov 19, 2015 at 1:29 PM, Pierre <pm+lists at acinq.fr> wrote:
> Hi guys,
>
> Do you know of any available resources on "segregated witness" ? I
> couldn't find any.
>
> Cheers,
>
> Pierre
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/ca14f084/attachment.html>

2023-06-09 12:43:27

- reply

📅 Original date posted:2015-06-23
📝 Original message:
On 23 Jun 2015 12:41, "Rusty Russell" <rusty at rustcorp.com.au> wrote:
>
> That's an open question, and one I'm about to start a conversation on
> with CJP (author of Amiko pay) on the new list.
we're already on the new list or am I missing something?
> Thanks!
> Rusty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150623/ac137566/attachment.html>

2023-06-09 12:43:27

- reply

📅 Original date posted:2015-06-23
📝 Original message:
On Tue, Jun 23, 2015 at 1:32 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> "sickpig at gmail.com" <sickpig at gmail.com> writes:
>> we're already on the new list or am I missing something?
>
> Yes, you were one of the early subscribers. Welcome :)
thanks Rusty
> But last I looked there were only a 15 of us, so I'll wait a bit longer
> before starting real discussion.
sure, makes perfect sense.

2023-06-07 17:46:36

- reply

📅 Original date posted:2015-12-18
📝 Original message:Anthony,
On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev wrote:
> > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote:
> > > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
> > > equivalent to the 2-4-8 "compromise" proposal [...]
> > isn't SegWit gain ~75%? hence 2mb x 1.75 = 3.5.
>
> Segwit as proposed gives a 75% *discount* to witness data with the
> same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up
> of 650kB of base block data plus 1.4MB of witness data; where 650kB +
> 1.4MB/4 = 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus
> 2.8MB of witness, for 1.3MB+2.8MB/4 = 2MB at a 2MB limit.
>
> > 4x is theoric gain you get in case of 2-2 multisig txs.
>
> With segregated witness, 2-2 multisig transactions are made up of 94B
> of base data, plus about 214B of witness data; discounting the witness
> data by 75% gives 94+214/4=148 bytes. That compares to about 301B for
> a 2-2 multisig transaction with P2SH rather than segwit, and 301/148
> gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed
> to get the numbers above.
>
> You get further improvements with, eg, 3-of-3 multisig, but to get
> the full, theoretical 4x gain you'd need a fairly degenerate looking
> transaction.
>
> Pay to public key hash with segwit lets you move about half the
> transaction data into the witness, giving about a 1.6x improvement by
> my count (eg 1.6MB = 800kB of base data plus 800kB of witness data,
> where 800kB+800kB/4=1MB), so I think a gain of between 1.6 and 2.0 is
> a reasonable expectation to have for the proposed segwit scheme overall.
>
>
many thanks for the explanation.
so it should be fair to say that BIP 102 + SW would bring a gain between
2*1.6 and 2*2.
Just for the sake of simplicity if we take the middle of the interval we
could say
that BIP102 + SW will bring us a max block (virtual) size equal to 1MB * 2
* 1.8 = 3.6
Is it right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/7a7b71da/attachment-0001.html>

2023-06-07 17:46:35

- reply

📅 Original date posted:2015-12-17
📝 Original message:On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
> equivalent to the 2-4-8 "compromise" proposal (which by the way I never
> liked, because I don't think anybody should be in a position to
> "compromise" anything and because I don't see how "let's avoid an
> unavoidable economic change for a little bit longer" arguments can
> reasoably claim that "we need to kick the can down the road exactly 3 more
> times" or whatever is the reasoning behind it).
>
isn't SegWit gain ~75%? hence 2mb x 1.75 = 3.5.
4x is theoric gain you get in case of 2-2 multisig txs.
am I missign something obvious?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/54f03105/attachment-0001.html>

2023-06-07 17:46:23

- reply

📅 Original date posted:2015-12-18
📝 Original message:On Fri, Dec 18, 2015 at 8:56 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > - only assuming robust adoption rates by up-layer ecosystem software, and
>
> That's not required. Everyone who individually switches to new
> transactions gets to do 1.75x more transactions for the same price
> (and at the same time gets safer contracts, better script
> upgradability, and more security models at their disposal), completely
> independent of whether anyone else in the ecosystem does the same.
>
>
So hypothetically if wallets/payments processors/full nodes adoption
will take 6 month to get to 50% after the segwit soft-fork activation, this
means that actual network capacity will be increased by:
1.75 x 0.5 + 1 x 0.5 = 1.375
after six month.
An hard-fork on the others side would bring 1.75 since the activation, am I
right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/79231514/attachment.html>

2023-06-07 15:41:12

- reply

📅 Original date posted:2015-06-29
📝 Original message:Hi Peter,
> ==References==
>
> 1) "First-Seen-Safe Replace-by-Fee",
> Peter Todd, Bitcoin-development mailing list, May 25th 2015,
>
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07829.html
>
> 2) "Cost savings by using replace-by-fee, 30-90%",
> Peter Todd, Bitcoin-development mailing list, May 25th 2015,
>
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07813.html
>
> 3) "F2Pool has enabled full replace-by-fee",
> Peter Todd, Bitcoin-development mailing list, June 19th 2015,
>
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08422.html
>
> 4) "F2Pool has enabled full replace-by-fee",
> Adrian Macneil, Director of Engineering, Coinbase,
> Bitcoin-development mailing list, June 19th 2015,
>
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08443.html
just a minor nit pick, you should update "References" links using the new
mailing list archive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150629/538a6134/attachment.html>

2023-06-07 15:38:05

- reply

📅 Original date posted:2015-06-15
📝 Original message:Hi Raystonn
On Mon, Jun 15, 2015 at 9:36 PM, Raystonn . <raystonn at hotmail.com> wrote:
>
> I am only partially through the content at the below link, and I am very impressed. Has Justus Ranvier began work on implementation of the ideas contained therein?
I don't know if he or someone else has begun writing code to implement
what was described in the liked post, but I'm sure he will reply to
you since he's subscribed to this mailing list.
>
>
>
> From: sickpig at gmail.com
> Sent: Monday, June 15, 2015 12:18 PM
> To: Raystonn .
> Cc: Bitcoin Dev
> Subject: Re: [Bitcoin-development] The Bitcoin Node Market
>
>
> Sorry for top posting and the brevity but I'm typing from my phone
>
> You shoud be interested in this post by Justus Ranvier then:
>
> https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
>
> On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn at hotmail.com> wrote:
>>
>> I have been toying with an idea and figured I'd run it by everyone here
>> before investing further time in it. The goal here is to make it
>> sustainable, and perhaps profitable, to run full nodes on the Bitcoin
>> Network in the long term.
>>
>> - Nodes can participate in a market wherein they are paid by nodes, wallets,
>> and other services to supply Bitcoin Network data. Payment should be based
>> on the cost imposed on the Node to do the work and send the data, but can be
>> set in any way the node operator desires. It's a free market.
>> - Nodes that are mostly leeching data from the Bitcoin Network, such as
>> those that do not receive inbound connections to port 8333, will send
>> payments to the nodes they connect to, but will likely receive no payments
>> from other nodes, wallets, and other services.
>> - Nodes that are providing balanced full service to the Bitcoin Network will
>> tend to have a balance of payments coming in and going out with regards to
>> other balanced full service nodes, leaving them revenue neutral there. But
>> they will receive payments from leech nodes, wallets, and other services.
>>
>> The net effect here is that the cost to run nodes will be shared by those
>> who are using the Bitcoin network but not contributing by running a full
>> node. A market will develop for fees to connect to the Bitcoin Network
>> which should help cover the cost of running the Network. It's still
>> possible to continue offering access to your node for free as there is
>> nothing forcing you to charge a fee. But this isn't very sustainable
>> long-run. Market efficiencies should eventually mean nodes take in only
>> what is required to keep the Network operational.
>>
>> Raystonn
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 15:38:04

- reply

📅 Original date posted:2015-06-15
📝 Original message:Sorry for top posting and the brevity but I'm typing from my phone
You shoud be interested in this post by Justus Ranvier then:
https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn at hotmail.com> wrote:
> I have been toying with an idea and figured I'd run it by everyone here
> before investing further time in it. The goal here is to make it
> sustainable, and perhaps profitable, to run full nodes on the Bitcoin
> Network in the long term.
>
> - Nodes can participate in a market wherein they are paid by nodes,
> wallets,
> and other services to supply Bitcoin Network data. Payment should be based
> on the cost imposed on the Node to do the work and send the data, but can
> be
> set in any way the node operator desires. It's a free market.
> - Nodes that are mostly leeching data from the Bitcoin Network, such as
> those that do not receive inbound connections to port 8333, will send
> payments to the nodes they connect to, but will likely receive no payments
> from other nodes, wallets, and other services.
> - Nodes that are providing balanced full service to the Bitcoin Network
> will
> tend to have a balance of payments coming in and going out with regards to
> other balanced full service nodes, leaving them revenue neutral there. But
> they will receive payments from leech nodes, wallets, and other services.
>
> The net effect here is that the cost to run nodes will be shared by those
> who are using the Bitcoin network but not contributing by running a full
> node. A market will develop for fees to connect to the Bitcoin Network
> which should help cover the cost of running the Network. It's still
> possible to continue offering access to your node for free as there is
> nothing forcing you to charge a fee. But this isn't very sustainable
> long-run. Market efficiencies should eventually mean nodes take in only
> what is required to keep the Network operational.
>
> Raystonn
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150615/d624c8b0/attachment.html>

2023-06-07 15:23:30

- reply

📅 Original date posted:2014-07-14
📝 Original message:On Mon, Jul 14, 2014 at 1:26 PM, Mike Hearn <mike at plan99.net> wrote:
> Nice work, but please don't call it the "Bitcoin protocol spec". Your
> document is not a spec.
fair objection, fwiw.
> It is an attempt to describe in English the Bitcoin
> protocol, but anyone who implemented it based on your description would get
> it wrong. For example you didn't mention the SIGHASH_SINGLE bug and many
> other important areas like the difficulty transitions are also left
> unspecified.
at the end of the day it's opensource so it could always be improved via pull
request on github.
Krzysztof, in that regard I would add a licence file to make
integration of changes
made by others smoother.
> As a loose description of the protocol for newbies it's an invaluable
> resource and perhaps we should link to it from the developer guide. As
> something that claims to be a specification it is quite possibly dangerous -
> the only spec that matters is the C++ original.
just out of curiosity, do you think it will be possible to create any
other proper
protocol specifications rather than the C++ original?
> On Mon, Jul 14, 2014 at 11:54 AM, Krzysztof Okupski
> <k.okupski at googlemail.com> wrote:
>>
>> Dear all,
>>
>> thank you for your invaluable feedback. As requested, the spec
>> will from now on be under version control. It can be found under:
>>
>> https://github.com/minium/Bitcoin-Spec
>>
>> The old link to the PDF will be, just in case, kept updated as well.
>>
>>
>> Warm greetings,
>> Krzysztof Okupski

2023-06-07 15:13:33

- reply

📅 Original date posted:2014-02-10
📝 Original message:Hi,
On Mon, Feb 10, 2014 at 12:28 PM, Drak <drak at zikula.org> wrote:
> What is the official response from the Bitcoin Core developers about MtGox's
> assertion that their problems are due to a fault of bitcoin, as opposed to a
> fault of their own?
>
> The technical analysis preluding this mess, was that MtGox was at fault for
> their faulty wallet implementation.
this seems a fair explanation of what happened:
http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_chatter_about_what_is_going_on_at_mtgox/cf99yac