Skip to content

Instantly share code, notes, and snippets.

View Varunram's full-sized avatar

Varunram Ganesh Varunram

110 followers · 64 following
View GitHub Profile
@nothingmuch
nothingmuch / preferred value series mixing.md
Last active December 29, 2021 16:28

Unequal Amount Mixing for ZeroLink using Preferred Value Series Fixed Denominations

This is a quick sketch of several modifications to zerolink. This document tries to articulate an as of yet unproven intuition is that combined together they can allow unequal input amounts as well as relaxation of the post-mix no linking restriction, while retaining the same conservative assumptions about mixed output indistinguishability.

Disallowing post-mix linking is arguably bad for fungibility, since users are likely to bypass this restriction by transferring to other wallets. Therefore, if I am able to justify this change this seems like a much more substantial contribution to usability and fungibility. That said even if it can't be shown to be reasonable to do so, some of these ideas still have merit on their own, so not all would be lost.

Proposed Protocol Changes

"Soft Fork" changes

@dymurray
dymurray / satoshi.py
Created November 16, 2018 20:04
import ecdsa
import ecdsa.ellipticcurve as EC
curve = ecdsa.SECP256k1
x = int('11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c', 16)
y = int('b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3', 16)
point = EC.Point(curve.curve, x, y)
pubkey = ecdsa.VerifyingKey.from_public_point(point, curve)
hash1 = 90774958364900180671716888080665726921328827653065727390791155349203800699667
@nothingmuch
nothingmuch / turing completeness on predicates.md
Last active August 20, 2018 19:50
this is a response to a tweet - https://twitter.com/BMBernstein/status/1030935693911093250

turing completeness is needed if a contract can only be specified in terms of a universal turing machine acting on some input, i.e. some equivalent of an eval function, but a blockchain can never reach consensus on a predicate that doesn't halt

specifying predicates as total functions guarantees by construction that any specifiable predicate is will terminate over the entire domain of possible inputs

logically it follows that you only really need a total language to specify arbitrary predicates, but in practice that might still not be enough because even if a predicate provably terminates, it doesn't mean it does so in a reasonable time frame, nor does it guarantee that the input domain is sufficient for specifying all the things a blockchain might reach consensus about

an ideal language for such transactions would therefore not only guarantee termination, it would also give strong bounds on the complexity, be efficient to evaluate in practice, and place no arbitrary restrictions on the input domain, but t

@jonasschnelli
jonasschnelli / BIPoverhaul.mediawiki
Last active November 14, 2022 13:22 





  BIP: 324
  Layer: Peer Services
  Title: Version 2 Peer-to-Peer Message Transport Protocol
  Author&#58; Jonas Schnelli <[email protected]>
          Dhruv Mehta <[email protected]>
  Status&#58; Draft
  Type&#58; Standards Track
  Created&#58; 2019&#45;03&#45;08
  License&#58; PD




  


  




    


          
    

      

        
        

          

              @tnakagawa
          

          

            
                tnakagawa
                / bipschnorr-Multisignature.md
            
            

              Last active
              October 11, 2018 07:36
            

          

        

      

        

  

      

    
  


  




    


          
    

      

        
        

          

              @harding
          

          

            
                harding
                / qc-upgrade-path.md
            
            

              Created
              July 23, 2018 11:44
            

              
                Description of Tim Ruffing's upgrade path to post-quantum in presence of QC attackers
              
          

        

      

        

  

      

    
Background: future fast Quantum Computers (QCs) are hypothesized to be
much faster at solving various forms of the Discrete Log Problem (DLP)
than classical computers (e.g. what we use now).  Bitcoin uses the DLP
in what's called a trapdoor function: a function that's easy to compute
one way (a private key generating a public key) but hard to compute the
other way (using a public key to recover the original private key).
Fast QCs break that trapdoor, hypothetically allowing the operator of
the QC to steal the bitcoins from anyone whose public key is publicly
known.



  


  




    


          
    

      

        
        

          

              @achow101
          

          

            
                achow101
                / alert-vulns.md
            
            

              Last active
              July 12, 2022 02:03
            

          

        

      

        

  

      

    
Vulnerabilities in the Bitcoin Alert system


Background


The Alert System previously utilized by Bitcoin has several issues (some of which may be classified as vulnerabilities). These issues no longer exist in Bitcoin as of network protocol version 700013 which was released with Bitcoin Core 0.13.0. Many altcoins and Bitcoin client implementations were notified of the Alert System's removal and have since removed the alert system themselves or transitioned to using an Alert system that does not share an Alert Key with Bitcoin.


All of the issues described below allow an attacker in possession of the Alert Key to perform a Denial of Service attack on nodes that still support the Alert system. These issues involve the exhaustion of memory which causes node software to crash or be killed due to excessive memory usage.


Many of these issues were not known until the Alert System was removed as developers inspected the code for vulnerabilities prior to releasing the Alert Key. Due to these issues, the publicat



  


  




    


          
    

      

        
        

          

              @fernandonm
          

          

            
                fernandonm
                / bitcoin_derivatives.md
            
            

              Last active
              May 29, 2019 08:03
            

              
                Trust-minimized derivatives
              
          

        

      

        

  

      

    
Trust-minimized derivatives


Options contracts can be implemented as trust-minimized smart contracts using Bitcoin script. These contracts don't require oracles feeding the price into the blockchain or any other trusted third party. Recipients will only trust miners to mine (and not reverse) transactions paying a reasonable feerate, securing their payouts.


The underlier of these derivatives can be any digital asset available on a blockchain that can do HLTCs.


Call options


The buyer of an American-style call binary option pays a premium (eg: 0.1 BTC) for <seller secret> wich gives the right to buy Q units (quantity) of the underlying asset (100 LTC) at a specified strike price (0.016 BTC per LTC) at any time until the expiration date.



  


  




    


          
    

      

        
        

          

              @sipa
          

          

            
                sipa
                / golomb_loss.md
            
            

              Last active
              July 30, 2023 18:25
            

              
                Minimizing the redundancy in Golomb Codes Sets
              
          

        

      

        

  



    


          
    

      

        
        

          

              @taariq
          

          

            
                taariq
                / Discreet_log_adaptor_sigs.md
            
            

              Last active
              May 22, 2018 18:59
            

              
                Mimblewimble Discreet Log Contracts with Adaptor Signatures by Ruben Somsen
              
          

        

      

        

  

      

    
Hi all,


Tadge Dryja's Discreet Log Contracts (DLC) can be combined with Andrew Poelstra's Adaptor Signatures (AS). I'm simply describing the combination of the two existing concepts without any fundamental changes, but I thought it was worth writing out explicitly since I haven't seen any write-up. Hopefully it doesn't contain any errors.


Starting from Schnorr signature [R, s].


In DLC, the oracle will reveal one of multiple possible s values as part of signing the outcome of an event. This s is essentially a private key for which the public key S can be calculated ahead of time (because R is committed to in advance).


In AS, instead of just R (essentially a public key), you add a second public key P of which the payer wishes to obtain the private key p from the payee. Only by revealing p can the payee make the signature valid, and thus receive the payment.