azuchi

  BIP: 345
  Layer: Consensus (soft fork)
  Title: OP_VAULT
  Author: James O'Beirne <[email protected]>
          Greg Sanders <[email protected]>
          Anthony Towns <[email protected]>
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0345
  Status: Draft
 Type: Standards Track

azuchi

tx = Bitcoin::Tx.parse_from_payload('Tx 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713のHexデータ').htb)

File.open('bitcoin.pdf', mode = 'w') do |f|
  tx.outputs[0...-2].map.with_index do |o, i|
    data = o.script_pubkey.get_multisig_pubkeys.map.with_index do |p, j|
      if i == 0 && j ==0
        p[(p.index("%PDF-"))..-1]
      elsif i == 945
        p[0...-8]
      else

azuchi

require 'ecdsa'

class ProjectivePoint

  attr_reader :x
  attr_reader :y
  attr_reader :z
  attr_reader :field

  def initialize(x, y ,z)

azuchi

#[test]
  fn test_check(){
    let acc = Accumulator::<Rsa2048, &'static str>::empty().add(&["a", "b", "c"]);
    let (acc_d, proof_d) = acc.add_with_proof(&["d"]);
    let (acc_e, proof_e) = acc_d.clone().add_with_proof(&["e"]);
    println!("acc_e: {:?}", &acc_e);
    // 更新後のacc_eに対してacc_dのプルーフでの検証はできない。
    println!("verify membership d from e: {:?}", acc_e.clone().verify_membership(&"d", &proof_d));

    let all = prime_hash_product(&["a", "b", "c", "d", "e"]);

azuchi

This document describes the specification for supporting tokens other than TPC (tapyrus) on Tapyrus.

Introduction

We introduce a new opcodeOP_COLOR(0xbc) to allow Tapyrus to issue/transfer/burn arbitrary tokens. OP_COLOR is based on OP_GROUP, which was proposed in BCH before, and added some improvements.

It enables the following features:

• Issue Token

azuchi

Tapyrus上でTPC（tapyrus）以外のトークンをサポートするための仕様について記述する。

イントロダクション

Tapyrusで任意のトークンの発行・送付・破棄を可能にするため、新しいopcodeOP_COLOR(0xbc)を導入する。 OP_COLORは、以前BCHで導入が検討されていたOP_GROUPをベースとし、いくつかの改良を加えたもので、以下の機能を可能にする。

• トークンの発行
  • 再発行可能なトークンの発行
• 再発行不可能なトークンの発行

azuchi

トランポリンオニオンルーティング

このドキュメントはトランポリンホップの使用を可能にするために、我々が既存のオニオンルーティングに加える追加機能について説明する。

ネットワークが成長するにつれて、ネットワーク全体を最新の状態に保つために、より多くの帯域幅とストレージが必要になる。支払い経路を見つけることは、より多くの計算能力を必要とし、制限のあるデバイスにとってはそれを持続不可能にする。

制限のあるデバイスはネットワークのごく一部のビューを持ち、トランポリンノードを利用して支払いを転送するようにする。この提案は、それでも匿名性を犠牲にしないよう送信者によって作成されたオニオンを使用している（ほとんどの場合、それはより大きな匿名セットを提供するだろう。）。

ネットワーク全体を追跡するノードは、option_trampoline_routingのサポートを広告する必要がある。これらのトランポリンノードには、従来のオニオンルーティングよりも多くの手数料を稼ぐ機会がある。

azuchi

# ECDSAでTaprootを構成した際のPの署名を生成するコード
require 'bitcoin'
require 'paillier'

include Bitcoin::Opcodes

point_field = ECDSA::PrimeField.new(ECDSA::Group::Secp256k1.order)

# アリスが鍵ペアを生成
alice_key = Bitcoin::Key.generate

azuchi

# ECDSAを使ったAdaptor Signature
require 'bitcoin'
require 'paillier'

point_field = ECDSA::PrimeField.new(ECDSA::Group::Secp256k1.order)

# アリスが鍵ペアを生成
alice_key = Bitcoin::Key.generate
alice_pub = alice_key.to_point

azuchi

# 効率的なECDSAの2-of-2のマルチシグ
require 'bitcoin'
require 'paillier'

# アリスが鍵ペアを生成
alice_key = Bitcoin::Key.generate
alice_pub = alice_key.to_point

# ボブが鍵ペアを生成
bob_key = Bitcoin::Key.generate