<unnamed>

Public Key

npub1d4tcv42hqfxl2fm9tqep3mellmqcfa6z8fn022zdj2ug289u5scqe7wy8f

Profile Code

nprofile1qqsx64ux24tsyn04yaj4svscaullasvy7apr5eh49pxe9wy9rj72gvqpzpmhxue69uhkummnw3ezuamfdejsx4etuh

Publishing to

nostr.wine

Last Notes

2023-06-09 12:45:07 UTC

- 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-07 17:46:36 UTC

- 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 UTC

- 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 15:38:05 UTC

- 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 UTC

- 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:13:33 UTC

- 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