Skip to content

Instantly share code, notes, and snippets.

View jonatack's full-sized avatar

Jon Atack jonatack

View GitHub Profile
@amitiuttarwar
amitiuttarwar / transaction_rebroadcasting.md
Last active January 6, 2020 20:16

Background: Currently, a node will only rebroadcast a transaction if it is the originating wallet. This is awful for privacy.

PR #16698 reworks the rebroadcast logic to significantly improve privacy.

Overview of changes

  • Instead of the wallet directly relaying transactions to peers, the wallet will submit unconfirmed txns to the node, and the node will apply logic to trigger txn rebroadcasts.
  • The node will apply rebroadcast conditions to all transactions.
  • The wallet will attempt to resubmit unconfirmed transactions to the node on a scheduled timer. This is only useful if the txn is dropped from the local mempool before it gets mined.
  • The mempool tracks locally submitted transactions (wallet & rpc) to ensure they are succesfully rebroadcast. Success is defined as receiving a GETDATA for the txn.
@AdamISZ
AdamISZ / SNICKER_BIP_draft.mediawiki
Last active April 3, 2023 20:09
SNICKER BIP draft 





  BIP: ??
  Layer: Applications
  Title: SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
  Author&#58; Adam Gibson <AdamISZ@protonmail.com>
  Comments&#45;Summary&#58; No comments yet.
  Comments&#45;URI&#58; &#45;
  Status&#58; Proposed
  Type&#58; Informational
  Created&#58; &#45;




  


  




    


          
    

      

        
        

          

              @niftynei
          

          

            
                niftynei
                / dot.txt
            
            

              Created
              September 5, 2019 17:39
            

              
                notes from outputs investigation
              
          

        

      

        

  

    
    


        



  


  

        

          
          wallet/db.c     -> table schemas + migrations
        

        

          
          wallet/wallet.c -> SQL statements 
        

        

          
          

        

        

          
          table: outputs
        

        

          
          question: what are the values for 'status'
        

        

          
          	output_state_available= 0,
        

        

          
          	output_state_reserved = 1,
        

        

          
          	output_state_spent = 2,
        

        

          
          	/* Output has been included in a signed funding tx that we've shared
        

        

          
          	 * with a peer; not yet mempooled. Eligible for burning */
        

  





    


  




    


          
    

      

        
        

          

              @hebasto
          

          

            
                hebasto
                / bitcoincore-hmp.md
            
            

              Created
              April 4, 2020 09:59
            

              
                 The Bitcoin Core on Heterogeneous Multi-Processing platforms 
              
          

        

      

        

  

      

    
The Bitcoin Core on Heterogeneous Multi-Processing platforms


Consider a system on the heterogeneous computing ARM big.LITTLE architecture, e.g., ODROID-HC1 powered by Samsung Exynos 5 Octa 5422.


As the Bitcoin Core is a highly computationally intensive application, the usage of ultra-low power and slower LITTLE cores could lead to a substantial lagging and errors (see: bitcoin/bitcoin#16008).


Also there are report about other flaws in LITTLE cores design.


The suggested solution of the described problem is to force the CPU core affinity of the Bitcoin Core processes. On Linux this could be achieved by the [taskset](https://linux.die.net/man/1/t



  


  




    


          
    

      

        
        

          

              @jnewbery
          

          

            
                jnewbery
                / shared_ptr.cpp
            
            

              Created
              April 18, 2020 15:42
            

              
                Passing shared pointers
              
          

        

      

        

  

    
    


        



  


  

        

          
          #include <iostream>
        

        

          
          #include <memory>
        

        

          
           
        

        

          
          struct Base
        

        

          
          {
        

        

          
              Base() { std::cout << "  Base::Base()\n"; }
        

        

          
              ~Base() { std::cout << "  Base::~Base()\n"; }
        

        

          
          };
        

        

          
          

        

        

          
          struct TraceByVal
        

  





    


  




    


          
    

      

        
        

          

              @ariard
          

          

            
                ariard
                / digital-card.txt
            
            

              Created
              May 6, 2020 16:56
            

              
                Celebrating the 1-year of Bitcoin PR Review Club
              
          

        

      

        

  

    
    


        



  


  

        

          
          jonatack:
        

        

          
          

        

        

          
          U2FsdGVkX18XDMZfMBvtOjbdzP9FglsfNI1IkmfUsmjhUJc1x8YghQL9jjBRA22G
        

        

          
          LMC9KLt7L/7sFJfVm7rEW+yeoWXL6S/K1NWdOvoy6O5pfQF2NMltA6Mzb1q4huVM
        

        

          
          x+BW7DNEBF9nDknRwFiAD079WOvLyLbWvPHk1FJp9hW5qRgU/629/XQ0pQX1eqdf
        

        

          
          OLVS5AGuTxBgc8AE6tp4i+x7mC037bTBuI9c6X4mngfYpfu9PkSK+DzQx6pXqgTh
        

        

          
          uvEprusb8PzsWmUSNbFN4umr9bAbUeezWig7mWNbIEbpBR/jD4YSeTXaBXfP2fvB
        

        

          
          BJU/38DWll06Ki46CE/tkTMSjuUg2E5T2hTDppSAC9j6OuhLtt8+ZKLtt2X2tCm8
        

        

          
          vdERbOHFdZu/Npsj6vLg8SWsKoen5LvGbRWfuXTWEa9FlTu9t7PMbcc5Zbk/5DKr
        

        

          
          yY3jW/4u/bWuZlYca3U8dSZEjGZod+paht4acXoJRUy58RWl3Lg72FZXCuzw7Ph2
        

  





    


  




    


          
    

      

        
        

          

              @troygiorshev
          

          

            
                troygiorshev
                / PeerLogging.md
            
            

              Created
              June 3, 2020 14:27
            

              
                Peer Logging
              
          

        

      

        

  

      

    
Peer Logging


The Bitcoin P2P network is fundamental to the strength of Bitcoin itself.  However, as it stands we know very little about the peers we connect to.  This makes it difficult to have data-driven conversations about making changes to the P2P protocol.  Additionally, we connect and disconnect from peers in a naïve fashion, simply because we are lacking in the information we would need to make better decisions.


We need more data.


To remedy this problem, I propose the following extensions to Bitcoin Core's per-peer logging abilities.


    

  1. Message Capture
    2. 




  


  




    


          
    

      

        
        

          

              @Sjors
          

          

            
                Sjors
                / overview.md
            
            

              Last active
              December 1, 2023 02:37
            

              
                Hardware Wallet Support in GUI and RPC, using HWI
              
          

        

      

        

  

      

    
Project: https://github.com/bitcoin/bitcoin/projects/15


Final User Experience


A user plugs in their hardware wallet and creates a new wallet. It automatigically detects the device and imports the keys:




The user can verify a receive address on their device with just a click:



  


  




    


          
    

      

        
        

          

              @adamjonas
          

          

            
                adamjonas
                / p2p_prioritization.md
            
            

              Last active
              December 8, 2020 17:21
            

          

        

      

        

  

      

    
This is not an exhaustive list. This is mostly from looking at PRs or IRC meetings. Any mistakes are my own.


Backports


    

  • [MERGED] 0.19: Add txids with non-standard inputs to reject filter #19681
    • 

  • [MERGED] 0.20: Add txids with non-standard inputs to reject filter #19680
    • 

  • 0.20: Backport wtxid relay #19606
    • 

  • bitcoin/bitcoin#19569 (comment) (to be opened by jnewbery) with #19610
    • 



In progress/priorities


    

  • [MERGED] Transaction overhaul (#19184 - sipa) (Review by sdaftuar, ajtowns, ariard)
    • 




  


  




    


          
    

      

        
        

          

              @ajtowns
          

          

            
                ajtowns
                / FEATURE.md
            
            

              Created
              January 14, 2021 07:57
            

          

        

      

        

  

      

    
What do you think of just generalising feature negotiation so it's
comprehensive?


Suppose "VERSION 80000+" specifies:


initiator sends a VERSION message
responder sends a VERSION message


after having both send and received a VERSION message specifying
a version >= 80000, both nodes must specify FEATURE support by