to " OP_NOTIF
> OP_RESERVED OP_ENDIF".
>
>
>
> On 2023-10-21 07:09:13 user Ethan Heilman via bitcoin-dev
> wrote:
>
> Hi everyone,
>
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_dr
of 520 Bytes.
>
> I don't think there's a new limit related to tapscript? In the very
> beginning there was no limit, but a 5k limit was put into place, then 520
> the same commit that OP_CAT was
> disabled: 4bd188c4383d6e614e18f79dc337fbabe8464c82
>
> On Sat, Oct 21, 2023 at 1:09
Hi everyone,
We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
OP_CAT was available in early versions of Bitcoin. It was disabled as
it allowed the construction of a script whose evaluation could create
>To implement Winternitz we need some kind of limited-repeat construct, which
>is not available in SCRIPT, but may be emulatable with enough `OP_IF` and
>sheer brute force.
But what you gain in smaller signatures, you lose in a more complex
and longer SCRIPT, and there are limits to SCRIPT size
>Yes, quite neat indeed, too bad Lamport signatures are so huge (a couple
>kilobytes)... blocksize increase *cough*
Couldn't you significantly compress the signatures by using either
Winternitz OTS or by using OP_CAT to build a merkle tree so that the
full signature can be derived during script
I'm only going to talk about cashfusion and not the knapsack paper.
The language they use to describe the cashfusion protocol is very
broad and could describe many things. Because it is hard so vague I
don't want to dismiss the cashfusion approach out of hand. For
instance they say: "inputs of
I hope you are having an great afternoon ZmnSCPxj,
You make an excellent point!
I had thought about doing the following to tag nodes
|| means OP_CAT
`node = SHA256(type||SHA256(data))`
so a subnode would be
`subnode1 = SHA256(1||SHA256(subnode2||subnode3))`
and a leaf node would be
`leafnode =
To avoid derailing the NO_INPUT conversation, I have changed the
subject to OP_CAT.
Responding to:
"""
* `SIGHASH` flags attached to signatures are a misdesign, sadly
retained from the original BitCoin 0.1.0 Alpha for Windows design, on
par with:
[..]
* `OP_CAT` and `OP_MULT` and `OP_ADD` and
>I don't find too compelling the potential problem of a 'bad wallet designer',
>whether lazy or dogmatic, misusing noinput. I think there are simpler ways to
>cut corners and there will always be plenty of good wallet options people can
>choose.
I want to second this. The most expensive part
Attack 1:
I partition (i.e. eclipse) a bunch of nodes from the network this partition
contains no mining power . I then mine 145 blocks for this partition. I
don't even need 51% of the mining power because I'm not competing with any
other miners. Under this rule this partition will hardfork from
Good morning to you as well ZmnSCPxj,
My above email contains an error. The SPV client needs to only
download S+1, not S+1 and S+2.
I agree with you that a weakness of this approach is a miner can make
SPV clients do substantially more work. However:
1. Mining a block which will never be
Hi ZmnSCPxj,
Let's see if I understand what you are saying. In your scenario chain
A consists of honest miners (10% of the hash rate) and chain B (90%
of the hash rate) consists of dishonest miners who are inflating the
coin supply.
Chain A: S, S+1
Chain B: S, S+1 (invalid), S+2, S+3, S+4, S+5,
I'm probably repeating a point which has been said before.
>I suppose a minority miner that wants to disrupt the network could simply
>create a *valid* block at block N+1 and deliberately ignore every other valid
>block at N+1, N+2, N+3 etc. that it did not create itself.
If this minority miner
Dear All,
The Call for Proposals (CFP) for 'Scaling Bitcoin 2017: Stanford' is now
open.
Please see https://scalingbitcoin.org for details
*Important Dates*
Sept 25th - Deadline for submissions to the CFP
Oct 16th - Applicant acceptance notification
Hope to see you in California (Nov 4-5
My OP_CAT usecase only needs to glue together hash outputs, so two 32
Bytes inputs generating a 64 Byte output. However increasing this
would enable additional space savings. I would push for an OP_CAT
which can generate an output of no greater than 512 Bytes. Is there
are maximum byte vectors
>It'd help your case if you gave us some examples of such scripts being
used.
I want OP_CAT so that I can securely and compactly verify many hashes and
hash preimages. This would shrink offchain Tumblebit transactions
significantly.
For instance if I want a transaction TxA which checks that a
I strongly encourage Bitcoin to move from 80-bit collision resistance
(RIPEMD-160) to 128-bit collision resistance (SHA-256).
On Sat, Feb 25, 2017 at 5:14 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> On Feb 25, 2017 14:09, "Steve Davis via bitcoin-dev"
ice Wonder via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 02/25/2017 08:10 AM, Ethan Heilman via bitcoin-dev wrote:
>
>> SHA1 is insecure because the SHA1 algorithm is insecure, not because
>>>
>> 160bits isn't enough.
>>
>> I woul
>SHA1 is insecure because the SHA1 algorithm is insecure, not because
160bits isn't enough.
I would argue that 160-bits isn't enough for collision resistance. Assuming
RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), collisions
can be generated in 2^80 queries (actually detecting
I assume this has been well discussed in at some point in the Bitcoin
community, so I apologize if I'm repeating old ideas.
Problem exploitable nodes:
It is plausible that people running these versions of bitcoind may not
be applying patches. Thus, these nodes may be vulnerable to known
exploits.
om> wrote:
> On Jun 29, 2016 07:05, "Ethan Heilman via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> >It's also not clear to me why the HMAC, vs just
>> > SHA256(key|cipher-type|mesg). But that's probably just my crypto
>> &
>It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg).
>But that's probably just my crypto ignorance...
SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of
the length extension property of SHA256.
If I have a tag y = SHA256(key|cipher-type|mesg), I can
"*Abstract: *Digital currencies like Bitcoin rely on cryptographic
primitives to operate. However, past experience shows that cryptographic
primitives do not last forever: increased computational power and advanced
cryptanalysis cause primitives to break frequently, and motivate the
development of
I believe libsecp256k1 just performs Elliptic Curve operations
required by Bitcoin. OpenSSL is used for all other crypto.
For instance the PRNG appears to be OpenSSL:
https://github.com/bitcoin/bitcoin/blob/master/src/random.h
On Mon, Jan 18, 2016 at 8:39 PM, Andrew C via bitcoin-dev
>Ethan: your algorithm will find two arbitrary values that collide. That isn't
>useful as an attack in the context we're talking about here (both of those
>values will be useless as coin destinations with overwhelming probability).
I'm not sure exactly the properties you want here and
Based on current GH/s count of 775,464,121 Bitcoin tests 2^80 every 19 days.
log2(775464121*(1000*1000*1000*60*60*24*19)) = ~80.07
I don't fully understand the security model of segwit, so my analysis
will assume that any collision is bad.
>But it also requires O(2^80) storage, which is utterly
26 matches
Mail list logo
