Nostr notes by

📅 Original date posted:2015-11-19 📝 Original message: Hi ...

2023-06-09T14:45:07+02:00

In reply to nevent1q…yd4y
_________________________

📅 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>;

📅 Original date posted:2015-12-18 📝 Original ...

2023-06-07T19:46:36+02:00

In reply to nevent1q…jp3d
_________________________

📅 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>;

📅 Original date posted:2015-12-17 📝 Original message:On ...

2023-06-07T19:46:35+02:00

In reply to nevent1q…wm2l
_________________________

📅 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>;

📅 Original date posted:2015-06-15 📝 Original message:Sorry ...

2023-06-07T17:38:04+02:00

In reply to nevent1q…k372
_________________________

📅 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>;

📅 Original date posted:2014-02-10 📝 Original message:Hi, On ...

2023-06-07T17:13:33+02:00

In reply to nevent1q…ln7h
_________________________

📅 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