Onchain capacity is a red herring. There are so many problems with it and
we don't need to go into it here if it's already been beaten to death.
What we need are the op codes necessary to create a trustless,
disconnected graph of layer two solution.
We all know that some form of covenant techn
Erik/all,
Are you saying that node capacity is the primary technical limiting
factor to increasing adoption of bitcoin payments?
UBER & Lyft payments are actually poor examples because they are not
regular/monthly and I should not have used them (unless refilling
existing accounts, like gift ca
Erik,
Fees AKA costs are the best spam control system and I thank you for
highlighting that.
However, I think that bitcoin has yet to receive sufficient payments
usage to challenge credit card payments system when it comes to a race
to the bottom in terms of processing transactional fees.
In
>
> .
>
> In the USA, where I am, large businesses like UBER, Lyft, and many major
> telecom, cable, & electric utilities process huge volumes of regular and
> irregular credit card payments on a monthly basis. Almost none oft hose
> transactions are completed in bitcoin.
>
Unfortunately block si
Bitcoin already has a spam prevention system called "fees". I don't
believe it's insufficient. The only issue is the stochastic nature of its
effectiveness
Which can be resolved with things like payment pools, tree payments (
https://utxos.org/uses/scaling/), etc.
On Fri, Dec 29, 2023, 9:33
On Fri, Dec 29, 2023 at 1:34 PM Greg Tonoski via bitcoin-dev
wrote:
> There is significant difference when storing data as dummy signatures
> (or OP_RETURN) which is much more expensive than (discounted) witness.
> Witness would not have been chosen as the storage of arbitrary data if
> it cost as
Unfortunately, as near as I can tell there is no sensible way to
prevent people from storing arbitrary data in witnesses ...
To prevent "from storing arbitrary data in witnesses" is the extreme
case of the size limit discussed in this thread. Let's consider it along
with other (less radical) opt
Le 06/02/2023 à 19:05, Erik Aronesty via bitcoin-dev a écrit :
> my favorite one is the javascript exploit for people that like to
> render untrusted blockchain data in their browser
Taking this example to show that from my standpoint it's not a good idea
to store "big things" in the blockchain
there are already images encoded in the chain using multisig. when we
eliminated the max-witness size in 2017, that made it a bit cheaper, that's
all (one tx instead of many)
https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html
my favorite one is the javascript exploit for pe
The inscriptions are designed to be easy to use, they even specify that
mime types should be used. I'd say, the way the data is stored is anything
but 'obscure'. UIs will be popping up to make this really easy. The main
chain can't be censored, what's in a block is in a block. I'm predicting a
huge
its trivial to store images in such a way that they look like legit
transactions.
this was done, in the past, using large numbers of multisig output
addresses that encode the images.
given the goals of the project, introducing this sort of censorship into
bitcoin seems fundamentally undesirable
_
On Fri, Feb 3, 2023 at 10:17 PM Melvin Carvalho via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> napsal:
>
>> I'm curious what opinions exist and what actions might be
pá 27. 1. 2023 v 13:47 odesílatel Robert Dickinson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> napsal:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.
my only concern is that as block space gets limited the likelihood of soft
fork opcode tech improvement proposals getting accepted by the community
goes down
schnorr sigs are extremely useful to me (anon, cheap multisig)
and some sort of vault tech would be very helpful as well
__
On Sat, Jan 28, 2023 at 7:58 AM alicexbt wrote:
>
> Hi Bitcoin Developers,
>
> > Anyone who runs an unpruned bitcoin node should be capacity-planning their
> > disk space assuming that in the future blocks will be more full - as demand
> > for blockspace increases, people will make better use of
I saw the other posts, then storage in witness, no, ordinals no for now,
let's keep things simple and understandable
I forgot to mention that the proposals envision a "local bitcoin" (for a
metaverse for example) wich is a fork of Bitcoin code, but of course not
a fork of Bitcoin, and which of cou
Hi Bitcoin Developers,
> Anyone who runs an unpruned bitcoin node should be capacity-planning their
> disk space assuming that in the future blocks will be more full - as demand
> for blockspace increases, people will make better use of the space that we
> already have and average block weight
On Fri, Jan 27, 2023 at 10:21 AM Andrew Poelstra
wrote:
8<
> Unfortunately, as near as I can tell there is no sensible way to prevent
> people from storing arbitrary data in witnesses without incentivizing
> even worse behavior and/or breaking legitimate use cases.
8<
> There's a reasonable ar
Le 27/01/2023 à 14:21, Andrew Poelstra via bitcoin-dev a écrit :
> if people were storing NFTs and other crap on the
> chain, then the Bitcoin fee market would become entangled with random
> pump&dump markets
So you mean that Bitcoin is out for NFTs, Metaverse and "web3"?
LN is good but I don't
On Fri, Jan 27, 2023 at 09:44:10AM -0300, Robert Dickinson via bitcoin-dev
wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). T
Hello,
“Unlimited storage” isn’t really accurate. It’s witness data in a taproot
transaction, so the block size limit still applies. Anyone who runs an unpruned
bitcoin node should be capacity-planning their disk space assuming that in the
future blocks will be more full - as demand for blocksp
I'm curious what opinions exist and what actions might be taken by core
developers regarding storing unlimited amounts of NFT (or other?) content
as witness data (https://docs.ordinals.com/inscriptions.html). The ordinal
scheme is elegant and genius IMHO, but when I think about the future disk
use
22 matches
Mail list logo
