> that does not change the fact that Alice -> Bob -> Zack was mined in the
> blockchain, and those transactions exist
If you use it in that way, then cut-through is pointless. The whole point of
using it is scaling. If you have only "Alice -> Zack" transaction, that is
included in some block,
On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote:
> > Given the current concerns with blockchain size increases due to
> > inscriptions, and now that the lightning network is starting to gain more
> > traction, perhaps people are now more willing to consider a smaller
> > b
y's Topics:
1. Re: Concern about "Inscriptions" (symphonicbtc)
--
Message: 1
Date: Mon, 21 Aug 2023 22:34:03 +
From: symphonicbtc
To: John Tromp
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Messag
; Today's Topics:
>
>1. Re: Concern about "Inscriptions" (symphonicbtc)
>
>
> --
>
> Message: 1
> Date: Mon, 21 Aug 2023 22:34:03 +0000
> From: symphonicbtc
> To: John Tromp
> Cc: Bitcoin Protocol Discussion
elimination or control acquisition; and not necessary by a national-state
government.
Chris
--- Forwarded Message ---
Von: Russell O'Connor
Datum: Am Montag, 21. August 2023 um 16:47
Betreff: Re: [bitcoin-dev] Concern about "Inscriptions"
An: martl.ch...@proton.me , Bitcoin Prot
indeed, i once added a proof-of work requirement to public keys on an open
relay server protocol, in additon to posk, in order to make it harder to
roll new keys and access the network as a spammer/scammer. not hard to
embed anything in a public key, but you can't embed too much, especially if
yo
It is important to also note that proof of secret key schemes are highly data
inefficient and likely would have a higher cost for users than simply allowing
arbitrary data to continue. In ECDSA, purposely re-using k values allows you to
encode data in both k and the entire secret key, as both be
> If we ban "arbitrary data", however you want to define it, then actors will
> simply respond by encoding their data within sets of public keys. Public
> key data is indistinguishable from random data, and, unless we are willing
> to pad the blockchain with proof of knowledge of secret keys, ther
Good morning Russel and List,
That is correct. There is a counterparty-compatible project called STAMPS that
breaks up image data into chunks and then embeds the chunks in bare multisig
outputs. here is an example on one:
https://mempool.space/tx/ee9ed76fa2318deb63a24082a8edc73e4ea39a5252bfb1c1
It's been said before, but I'll say it again:
If we ban "arbitrary data", however you want to define it, then actors will
simply respond by encoding their data within sets of public keys. Public
key data is indistinguishable from random data, and, unless we are willing
to pad the blockchain with
It is already more than a half year since the probably mayor Bitcoin script
exploit started.
These exploits are nothing new in the Bitcoin history and mostly are due to the
loose flexibility of the system in regards of processing predicatives (Bitcoin
script). The very first mayor bug; if you w
-----
>>
>> Message: 1
>> Date: Wed, 02 Aug 2023 13:50:30 +
>> From: Einherjar mailto:realeinher...@proton.me>>
>> To: bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>, Keagan McClelland
>> mailto:kea
uts
> (Peter Todd)
>
>
> --
>
> Message: 1
> Date: Wed, 02 Aug 2023 13:50:30 +0000
> From: Einherjar
> To: bitcoin-dev@lists.linuxfoundation.org, Keagan McClelland
>
> Subject: Re:
<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment-0001.sig>
--
Message: 2
Date: Tue, 1 Aug 2023 22:58:53 -0700
From: Keagan McClelland
To: Hugo L , Bitcoin Protocol Discussion
have a very good idea of what pools do
> full-rbf.
> Why don't you already have this data?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> -- next part --
> A non-text attachment was scrubbed...
> Name: signature.asc
> Typ
About price space in the UTXO set:
I am highly concerned with that proposal.
The reason is this could restrict users to do proper UTXO management and lead
to doxing and privacy issues. Now there are few costs associated to having lots
of UTXOs, mainly fees associated with spending low-valued UTX
t;1. Re: Concern about "Inscriptions". (rot13maxi)
>>
>>
>> --
>>
>> Message: 1
>> Date: Sun, 30 Jul 2023 18:34:12 +
>> From: rot13maxi
>> To: L?o Haf , "vju...@gaze
Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>1. Re: Concern about "Inscriptions". (rot13maxi)
>
>
> --
>
> Message: 1
> Date: Sun, 30 Jul 2023 18:34:12 +0000
> From: rot13maxi
> To: L?o Haf , "vju...@gazeta.pl"
>
Hello,
> This cat and mouse game can be won by bitcoin defenders. Why ? Because it is
> easier to detect these transactions and make them a standardization rule than
> to create new types of spam transactions.
One of the things discussed during the mempoolfullrbf discussion is that a
small (~1
According to you, the rules of standardization are useless but in this case
why were they introduced? The opreturn limit can be circumvented by miners, yet
it is rare to see any, the same for maxancestorcount, minrelayfee or even the
dust limit.
This cat and mouse game can be won by bitcoin de
> not taking action against these inscription could be interpreted by spammers
> as tacit acceptance of their practice.
Note that some people, even on this mailing list, do not consider Ordinals as
spam:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html
See? It
> and I would like to understand why this problem has not been addressed more
> seriously
Because if nobody has any good solution, then status quo is preserved. If
tomorrow ECDSA would be broken, the default state of the network would be "just
do nothing", and every solution would be backward-c
I understand your point of view. However, inscription represent by far the
largest spam attack due to their ability to embed themselves in the witness
with a fee reduction.
Unlike other methods, such as using the op_return field which could also be
used to spam the chain, the associated fees an
Hello,
I am writing to you today because I am concerned about a significant bug that
seems to be overlooked in recent versions of the software. The bug in question
concerns the "inscriptions" developed by @rodarmor, and it worries me because,
in just a few months, they have already reached a si
24 matches
Mail list logo
