Eduardo Palena

Cybersecurity | Digital Forensics | Bitcoin (BTC)

Menu
  • Home
  • Presentazione
  • Categorie
    • Bitcoin (BTC)
    • Come si fa
    • Crittografia
    • Cryptocurrency
    • Cybersecurity
    • Digital Forensics
    • Firewall
    • Legale
    • Per i genitori
    • Tecnologia e ricerca
  • Contatti
  • Cerca nel sito
Menu

Cosa sono i BIP ?

Posted on 03/11/202216/11/2022 by Eduardo Palena

Bitcoin Improvement Proposals (BIPs) sono documenti di progettazione aperta per l’introduzione di nuovi standard e funzionalità per Bitcoin, come nuovi tipi di transazione come SegWit o le loro proprietà come replace-by-fee (RBF).
Il BIP, come modificato, da allora è diventato il modo standard per comunicare formalmente idee sui potenziali miglioramenti di Bitcoin.
Il concetto di BIP è stato introdotto il 19-08-2011 da Amir Taaki, nella forma del primo BIP.
Il secondo BIP, BIP2 è stato pubblicato 5 anni dopo.

Questo è il processo per una nuova implementazione:

In questo articolo vediamo solo gli standard di portafogli e di transazione.

Portafogli deterministici gerarchici:
BIP32 – Portafogli deterministici gerarchici
BIP39 – Codice mnemonico per la generazione di chiavi deterministiche
BIP43 – Campo scopo per portafogli deterministici
BIP44 – Gerarchia multi-account per portafogli deterministici
BIP49 – Schema di derivazione per conti basati su P2WPKH annidati in P2SH
BIP84 – Schema di derivazione per conti basati su P2WPKH

Standard di transazione
BIP16 – Paga per script hash
BIP141 – Testimone segregato (livello di consenso)
BIP173 – Formato indirizzo Base32 per output di controllo nativi v0-16
BIP125 – Segnalazione opt-in per la sostituzione completa del canone

Portafogli deterministici gerarchici

BIP32 – Portafogli deterministici gerarchici
Questo BIP descrive una struttura generale del portafoglio deterministico gerarchico (portafoglio HD).
In particolare, definisce come derivare le chiavi private e pubbliche di un wallet da un master seed binario (m) e da un insieme ordinato di indici (il cosiddetto percorso BIP32):

m / indice1 / indice2 / … / indicen

Derivazione temprata e non temprata
Esistono due possibili tipi di derivazione BIP32, temprata o non temprata. Nella notazione del percorso BIP32 standard, la derivazione rafforzata a un livello particolare è indicata da un apostrofo. Ad esempio, per i primi tre livelli viene utilizzato il seguente esempio di derivazione hardened, mentre per gli ultimi due livelli viene utilizzata la derivazione non hardened:

m / 44′ / 0′ / 1′ / 1 / 33

Con le chiavi non protette, puoi provare che una chiave pubblica figlio è collegata a una chiave pubblica principale utilizzando solo le chiavi pubbliche. Puoi anche derivare chiavi figlio pubbliche da una chiave padre pubblica, che abilita i portafogli di sola visualizzazione. Con le chiavi figlio rafforzate, non è possibile dimostrare che una chiave pubblica figlio sia collegata a una chiave pubblica padre.

Per motivi di sicurezza, l’utilizzo di chiavi temprate è più sicuro, ma esistono casi d’uso per l’utilizzo di chiavi non temprate. Una chiave pubblica estesa padre insieme a una chiave privata figlio non protetta possono esporre la chiave privata padre. Ciò significa che le chiavi pubbliche estese devono essere trattate con maggiore attenzione rispetto alle normali chiavi pubbliche. È anche il motivo dell’esistenza di chiavi rinforzate e del motivo per cui vengono utilizzate per il livello di account nell’albero. In questo modo, una perdita di chiavi private specifiche dell’account (o inferiori) non rischia mai di compromettere il master o altri account.

BIP39 – Codice mnemonico per la generazione di chiavi deterministiche
Questo BIP descrive l’implementazione di un seme di ripristino e la sua relazione con il seme master binario BIP32. Si compone di due parti:
generazione del seme di recupero
convertendolo in un seme master binario che include un’applicazione opzionale di una passphrase durante la conversione.

BIP43 – Campo scopo per portafogli deterministici
BIP32 da solo offre troppi gradi di libertà su come implementare un portafoglio. Questo è il motivo per cui BIP43 introduce una regola per cui il primo indice di derivazione chiamato scopo dovrebbe corrispondere a un BIP che descrive la struttura del portafoglio ai livelli successivi. Pertanto, se, ad esempio, un portafoglio conforme a BIP39 utilizza il percorso di derivazione m/44’/…, suggerisce che la sua struttura sia descritta da BIP44.

m / scopo

BIP44 – Gerarchia multi-account per portafogli deterministici
Questo BIP definisce un’implementazione di un portafoglio HD basato su BIP32 e BIP43. In particolare, descrive la struttura del wallet multi-coin per gli indirizzi P2PKH (es. 1-addresses in Bitcoin) e l’algoritmo per il rilevamento del wallet:

m / 44′ / coin_type’ / account’ / change / address

dove per le costanti per coin_type index sono definite da SLIP44.

BIP49 – Schema di derivazione per conti basati su P2WPKH annidati in P2SH
Questo BIP definisce un’implementazione di un portafoglio HD per gli indirizzi SegWit P2WPKH-in-P2SH (es. 3-indirizzi in Bitcoin). Fatta eccezione per il tipo di indirizzo, è simile a BIP44:

m / 49′ / coin_type’ / account’ / change / address

BIP84 – Schema di derivazione per conti basati su P2WPKH
Questo BIP definisce un’implementazione di un portafoglio HD per indirizzi SegWit P2WPKH nativi (es. bc1-addresses in Bitcoin). Fatta eccezione per il tipo di indirizzo, è simile a BIP44:

m / 84′ / coin_type’ / account’ / cambio / indirizzo

Standard di transazione
BIP16 – Paga per script hash
Questo BIP descrive il tipo di transazione P2SH (ad es. 3 indirizzi in Bitcoin). Il suo attuale utilizzo principale sono le transazioni MultiSig e SegWit.

BIP141 – Testimone segregato (livello di consenso)
Questo BIP ha abilitato SegWit come soft-fork in Bitcoin. È anche un prerequisito per la rete Lightning in quanto risolve il problema della malleabilità dei tipi di transazione pre-segwit.

In particolare, BIP141 definisce il seguente nuovo tipo di transazione: P2WPKH, P2WPKH-in-P2SH, P2WSH, P2WSH-in-P2SH.

BIP173 – Formato indirizzo Base32 per output di controllo nativi v0-16
Questo BIP propone un nuovo formato per gli indirizzi SegWit nativi, chiamato Bech32.

BIP125 – Segnalazione opt-in per la sostituzione completa del canone
Questo BIP descrive la politica di segnalazione Sostituisci per tariffa (RBF). Consente agli spendenti di aggiungere un segnale a una transazione che indica che vogliono essere in grado di sostituire quella transazione fino a quando non viene confermata.

Elenco dei BIP [ aggiornato al 3/11/2022]

NumeroStratoTitoloProprietarioTipoStato
1Scopo e linee guida del BIPAmir TaakProcessiSostituito
2Processo BIP, rivistoLuke DashjrProcessiAttivo
8Versione bit con bloccaggio per altezzaShaolin Fry, Luke DashjrInformativoBrutta copia
9Bit di versione con timeout e ritardoPieter Wuille, Peter Todd, Greg Maxwell, Rusty RussellInformativoFinale
10ApplicazioniDistribuzione delle transazioni multi-sigAlan ReinerInformativoRitirato
11ApplicazioniTransazioni standard M-di-NGavin AndresenStandardFinale
12Consenso (forcella morbida)OP_VALGavin AndresenStandardRitirato
13ApplicazioniFormato indirizzo per l’hash pay-to-scriptGavin AndresenStandardFinale
14Servizi alla pariVersione protocollo e User AgentAmir Taaki, Patrick StratemanStandardFinale
15ApplicazioniAliasAmir TaakStandardDifferito
16Consenso (forcella morbida)Paga su Script HashGavin AndresenStandardFinale
17Consenso (forcella morbida)OP_CHECKHASHVERIFY (CHV)Luke DashjrStandardRitirato
18Consenso (forcella morbida)hashScriptCheckLuke DashjrStandardProposto
19ApplicazioniTransazioni standard M-di-N (SigOp basso)Luke DashjrStandardRespinto
20ApplicazioniSchema URILuke DashjrStandardSostituito
21ApplicazioniSchema URINils Schneider, Matt CoralloStandardFinale
22API/RPCgetblocktemplate – FondamentiLuke DashjrStandardFinale
23API/RPCgetblocktemplate – Estrazione in poolLuke DashjrStandardFinale
30Consenso (forcella morbida)Transazioni duplicatePieter WuilleStandardFinale
31Servizi alla parimessaggio PongMike HearnStandardFinale
32ApplicazioniPortafogli gerarchici deterministiciPieter WuilleInformativoFinale
33Servizi alla pariNodi stratificatiAmir TaakStandardRespinto
34Consenso (forcella morbida)Blocco v2, Altezza in CoinbaseGavin AndresenStandardFinale
35Servizi alla parimessaggio di mempoolJeff GarzikStandardFinale
36Servizi alla pariServizi personalizzatiStefano TommasoStandardRespinto
37Servizi alla pariFiltraggio della fioritura di connessioneMike Hearn, Matt CoralloStandardFinale
38ApplicazioniChiave privata protetta da passphraseMike Caldwell, Aaron VoisineStandardBrutta copia
39ApplicazioniCodice mnemonico per la generazione di chiavi deterministicheMarek Palatinus, Pavol Rusnak, Aaron Voisine, Sean BoweStandardProposto
40API/RPCProtocollo del filo di stratoMarek PalatinoStandardNumero BIP assegnato
41API/RPCProtocollo di estrazione degli stratiMarek PalatinoStandardNumero BIP assegnato
42Consenso (forcella morbida)Un’offerta monetaria limitata per BitcoinPieter WuilleStandardFinale
43ApplicazioniScopo Campo per portafogli deterministiciMarek Palatinus, Pavol RusnakInformativoFinale
44ApplicazioniGerarchia multi-account per portafogli deterministiciMarek Palatinus, Pavol RusnakStandardProposto
45ApplicazioniStruttura per portafogli multifirma P2SH deterministiciManuel Araoz, Ryan X. Charles, Matias Alejo GarciaStandardProposto
47ApplicazioniCodici di pagamento riutilizzabili per portafogli deterministici gerarchiciGiusto RanvierInformativoBrutta copia
49ApplicazioniSchema di derivazione per conti basati su P2WPKH annidati in P2SHDaniel WeiglInformativoFinale
50Marzo 2013 Chain Fork post mortemGavin AndresenInformativoFinale
60Servizi alla pariMessaggio “versione” a lunghezza fissa (campo Relè-Transazioni)Amir TaakStandardBrutta copia
61Servizi alla pariRifiuta messaggio P2PGavin AndresenStandardFinale
62Consenso (forcella morbida)Affrontare la malleabilitàPieter WuilleStandardRitirato
63ApplicazioniIndirizzi invisibiliPietro ToddStandardNumero BIP assegnato
64Servizi alla parimessaggio getutxoMike HearnStandardObsoleto
65Consenso (forcella morbida)OP_CHECKLOCKTIMEVERIFYPietro ToddStandardFinale
66Consenso (forcella morbida)Firme DER rigorosePieter WuilleStandardFinale
67ApplicazioniIndirizzi multi-firma deterministici Pay-to-script-hash tramite l’ordinamento delle chiavi pubblicheThomas Kerin, Jean-Pierre Rupp, Ruben de VriesStandardProposto
68Consenso (forcella morbida)Tempo di blocco relativo utilizzando numeri di sequenza imposti dal consensoMark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajonaStandardFinale
69ApplicazioniIndicizzazione lessicografica degli input e degli output delle transazioniAtlante di KristovInformativoProposto
70ApplicazioniProtocollo di pagamentoGavin Andresen, Mike HearnStandardFinale
71ApplicazioniTipi MIME del protocollo di pagamentoGavin AndresenStandardFinale
72Applicazionibitcoin: estensioni uri per Payment ProtocolGavin AndresenStandardFinale
73ApplicazioniUtilizza l’intestazione “Accetta” per la negoziazione del tipo di risposta con gli URL delle richieste di pagamentoStefano CoppiaStandardFinale
74ApplicazioniConsenti valore zero OP_RETURN nel protocollo di pagamentoToby PadillaStandardRespinto
75ApplicazioniScambio di indirizzi fuori banda utilizzando la crittografia del protocollo di pagamentoJustin Newton, Matt David, Aaron Voisine, James MacWhyteStandardFinale
78ApplicazioniUna semplice proposta di PayjoinNicola DorierStandardBrutta copia
79ApplicazioniBustapay :: un pratico protocollo coinjoinRyan HavarInformativoSostituito
80Gerarchia per i portafogli multisig deterministici del pool di votazioni non coloratiJustus Ranvier, Jimmy SongInformativoDifferito
81Gerarchia per i portafogli multisig deterministici del pool di votazioni colorateJustus Ranvier, Jimmy SongInformativoDifferito
83ApplicazioniAlberi chiave deterministici gerarchici dinamiciEric LombrozoStandardRespinto
84ApplicazioniSchema di derivazione per conti basati su P2WPKHPaolo RusnakInformativoBrutta copia
85ApplicazioniEntropia deterministica dai portachiavi BIP32Ethan KosakovskyInformativoBrutta copia
90Schieramenti sepoltiSuha DaftuarInformativoFinale
91Consenso (forcella morbida)Soglia ridotta Segwit MASFJames HilliardStandardFinale
98Consenso (forcella morbida)Alberi Merkle velociMark Friedenbach, Kalle Alm, BtcDrakStandardBrutta copia
99Motivazione e implementazione delle modifiche alle regole di consenso ([soft/hard]fork)Jorge TimónInformativoRespinto
100Consenso (hard fork)Dimensione massima del blocco dinamico per voto del minatoreJeff Garzik, Tom Harding, Dagur Valberg JohannssonStandardRespinto
101Consenso (hard fork)Aumenta la dimensione massima del bloccoGavin AndresenStandardRitirato
102Consenso (hard fork)La dimensione del blocco aumenta a 2 MBJeff GarzikStandardRespinto
103Consenso (hard fork)Dimensione del blocco a seguito della crescita tecnologicaPieter WuilleStandardRitirato
104Consenso (hard fork)‘Block75’ – Dimensione massima del blocco come la difficoltàt.khanStandardRespinto
105Consenso (hard fork)Algoritmo di retargeting della dimensione del blocco basato sul consensoBtcDrakStandardRespinto
106Consenso (hard fork)Limite massimo della dimensione del blocco Bitcoin a controllo dinamicoUpal ChakrabortyStandardRespinto
107Consenso (hard fork)Limite dinamico sulla dimensione del bloccoWashington Y. SanchezStandardRespinto
109Consenso (hard fork)Limite di dimensione di due milioni di byte con limiti sigop e sighashGavin AndresenStandardRespinto
111Servizi alla pariBit di servizio NODE_BLOOMMatt Corallo, Peter ToddStandardProposto
112Consenso (forcella morbida)VERIFICA SEQUENZABtcDrak, Mark Friedenbach, Eric LombrozoStandardFinale
113Consenso (forcella morbida)Tempo mediano trascorso come punto finale per i calcoli del tempo di bloccoThomas Kerin, Mark FriedenbachStandardFinale
114Consenso (forcella morbida)Albero della sintassi astratta merkelizzataJohnson LauStandardRespinto
115Consenso (forcella morbida)Protezione generica anti-riproduzione tramite ScriptLuke DashjrStandardRespinto
116Consenso (forcella morbida)MERKLEBRANCH VERIFICAMark Friedenbach, Kalle Alm, BtcDrakStandardBrutta copia
117Consenso (forcella morbida)Semantica dell’esecuzione della chiamata in codaMark Friedenbach, Kalle Alm, BtcDrakStandardBrutta copia
118Consenso (forcella morbida)SIGHASH_NOINPUTCristiano DeckerStandardBrutta copia
119Consenso (forcella morbida)CONTROLLA MODELLO VERIFICAJeremy RubinStandardBrutta copia
120ApplicazioniProva del pagamentoKalle RosenbaumStandardRitirato
121ApplicazioniSchema URI della prova di pagamentoKalle RosenbaumStandardRitirato
122ApplicazioniSchema URI per riferimenti/esplorazione BlockchainMarco PontelloStandardBrutta copia
123Classificazione BIPEric LombrozoProcessiAttivo
124ApplicazioniModelli di script deterministici gerarchiciEric Lombrozo, William SwansonInformativoRespinto
125ApplicazioniAttivazione della segnalazione di sostituzione completa con tariffaDavid A. Harding, Peter ToddStandardProposto
126Migliori pratiche per transazioni di script di input eterogeneeAtlante di KristovInformativoBrutta copia
127ApplicazioniTransazioni a prova di riserva sempliciSteven RooseStandardBrutta copia
130Servizi alla parimessaggio sendheaderSuha DaftuarStandardProposto
131Consenso (hard fork)Specifica “Transazione di coalescenza” (input con caratteri jolly)Chris SacerdoteStandardRespinto
132Processo di accettazione del BIP basato sul comitatoAndy ChaseProcessiRitirato
133Servizi alla parimessaggio di filtroAlex MorcosStandardBrutta copia
134Consenso (hard fork)Transazioni flessibiliTom ZanderStandardRespinto
135Votazione dei bit della versione generalizzataSancio PanzaInformativoRespinto
136ApplicazioniRiferimenti di posizione Tx codificati Bech32Велеслав, Jonas Schnelli, Daniel PapeInformativoBrutta copia
137ApplicazioniFirme di messaggi utilizzando chiavi privateCristoforo GilliardStandardFinale
140Consenso (forcella morbida)TXID normalizzatoCristiano DeckerStandardRespinto
141Consenso (forcella morbida)Testimone segregato (livello di consenso)Eric Lombrozo, Johnson Lau, Pieter WuilleStandardFinale
142ApplicazioniFormato indirizzo per testimonianza segregataJohnson LauStandardRitirato
143Consenso (forcella morbida)Verifica della firma della transazione per il programma di verifica della versione 0Johnson Lau, Pieter WuilleStandardFinale
144Servizi alla pariTestimone segregato (servizi alla pari)Eric Lombrozo, Pieter WuilleStandardFinale
145API/RPCgetblocktemplate Aggiornamenti per la testimonianza separataLuke DashjrStandardFinale
146Consenso (forcella morbida)Gestire la malleabilità della codifica delle firmeJohnson Lau, Pieter WuilleStandardRitirato
147Consenso (forcella morbida)Gestire la malleabilità degli elementi fittiziJohnson LauStandardFinale
148Consenso (forcella morbida)Attivazione obbligatoria della distribuzione segwitFritto ShaolinStandardFinale
149Consenso (forcella morbida)Testimone segregato (secondo schieramento)Fritto ShaolinStandardRitirato
150Servizi alla pariAutenticazione tra pariJonas SchnelliStandardBrutta copia
151Servizi alla pariCrittografia della comunicazione peer-to-peerJonas SchnelliStandardRitirato
152Servizi alla pariRelè a blocco compattoMatt CoralloStandardFinale
154Servizi alla pariLimitazione della velocità tramite sfide specificate dai pariKarl-Johan AlmStandardRitirato
155Servizi alla parimessaggio addrv2Wladimir J. van der LaanStandardBrutta copia
156Servizi alla pariDandelion – Routing per il miglioramento della privacyBrad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod ViswanathStandardRespinto
157Servizi alla pariFiltraggio blocco lato clientOlaoluwa Osuntokun, Alex Akselrod, Jim PosenStandardBrutta copia
158Servizi alla pariFiltri a blocchi compatti per clienti leggeriOlaoluwa Osuntokun, Alex AkselrodStandardBrutta copia
159Servizi alla pariBit di servizio NODE_NETWORK_LIMITEDJonas SchnelliStandardBrutta copia
171ApplicazioniAPI di informazioni su valuta/tasso di cambioLuke DashjrStandardRespinto
173ApplicazioniFormato indirizzo Base32 per output di controllo nativi v0-16Pieter Wuille, Greg MaxwellInformativoFinale
174ApplicazioniFormato di transazione Bitcoin parzialmente firmatoAndrew ChowStandardFinale
175ApplicazioniProtocollo Pay to ContractOmar Shibli, Nicholas GregoryInformativoRespinto
176Denominazione dei bitJimmy CanzoneInformativoBrutta copia
178ApplicazioniVersione WIF estesaKarl-Johan AlmStandardBrutta copia
179Nome per gli identificatori del destinatario del pagamentoEmil Engler, Marco Falke, Luke DashjrInformativoBrutta copia
180Servizi alla pariBlock size/peso a prova di frodeLuke DashjrStandardRespinto
197ApplicazioniContratto di garanzia vincolato a tempo con hashMatthew Black, Tony CaiStandardBrutta copia
199ApplicazioniTransazioni di contratti con blocco temporale hashSean Bowe, Daira HopwoodStandardBrutta copia
300Consenso (forcella morbida)Impegni hashrate (livello di consenso)Paul Sztorc, CryptAxeStandardBrutta copia
301Consenso (forcella morbida)Estrazione alla cieca (livello Consenso)Paul Sztorc, CryptAxeStandardBrutta copia
310ApplicazioniEstensioni del protocollo StratumPavel Moravec, Jan ČapekInformativoBrutta copia
320nBit di versione per uso generaleBtcDrakStandardBrutta copia
322ApplicazioniFormato messaggio generico firmatoKarl-Johan AlmStandardBrutta copia
325ApplicazioniSigilloKarl-Johan Alm, Anthony TownsStandardProposto
330Servizi alla pariRiconciliazione annunci di transazioneGleb Naumenko, Pieter WuilleStandardBrutta copia
339Servizi alla pariInoltro di transazione basato su WTXIDSuha DaftuarStandardBrutta copia
340Firme Schnorr per secp256k1Pieter Wuille, Jonas Nick, Tim RuffingStandardBrutta copia
341Consenso (forcella morbida)Taproot: regole di spesa SegWit versione 1Pieter Wuille, Jonas Nick, Anthony TownsStandardBrutta copia
342Consenso (forcella morbida)Convalida degli script TaprootPieter Wuille, Jonas Nick, Anthony TownsStandardBrutta copia
350ApplicazioniFormato Bech32m per indirizzi di controllo v1+Pieter WuilleStandardBrutta copia
© Riproduzione riservata
Category: Bitcoin (BTC)Cryptocurrency

Ultimi Posts

  • App disponibili per la protezione dei bambini
  • Microsoft Windows come risolvere i problemi al microfono
  • Cosa sono i 3 livelli di sicurezza dello SPID ?
  • Modello di Relata di notifica e dichiarazione ex art. 137 co.7 c.p.c.
  • Antivirus, anche gratis.
  • Gruppi di Crackers più attivi nel 2022
  • Terminologia e acronimi del mondo delle criptovalute
  • Links utili per cercare lavoro
  • Come blindare WhatsApp e proteggere minimamente il proprio account
  • Disattivare i fastidiosi aggiornamenti di Windows
Eduardo Palena


Eduardo Palena è un informatico per passione, tecnico hardware, sviluppatore di software, digital forensics, divulgatore dal lontano 1999 sull'importanza della sicurezza informatica e dal 2017 della tecnologia del Bitcoin.
Fondatore di Napolifirewall.com, che è stato uno dei primi portali dedicato esclusivamente alla sicurezza informatica, quando le parole Cyberwar, Cybersecurity si trovavano solo nei libri di fantascienza ed erano utilizzate da pochi appassionati di BBS, Freenet e Telnet.

Categorie

  • Bitcoin (BTC)
  • Come si fa
  • Crittografia
  • Cryptocurrency
  • Cybersecurity
  • Digital Forensics
  • Firewall
  • Legale
  • Per i genitori
  • Tecnologia e ricerca

Archivio

  • 2023
  • 2022
  • 2021
  • 2020
  • 2019
  • 2018
  • 2017
  • 2016
  • 2012
  • 2011
  • 2007
  • 2005
  • 2004
  • 2002
  • 1999

©2023 Eduardo Palena